关于分布式系统超高并发写入数据库的架构设计问题(sqlserver2012)

请教一些架构上的问题，情况是这样的，是一个分布式的系统，有站点系统和中心系统组成，总共有2000个站点，每天平均每个站点大概有1500条数据要传送到中心系统，并写入数据库，每天要写入大概300万条数据到数据库，这些数据要做查询统计，读取数据的并发很小，可以不考虑，要考虑的写入并发非常高，查询统计的数据量非常大
这种情况如何做设计？

一天300万条数据，mysql轻轻松松吧。
这300万数据高峰期1s多少条？
峰值太高的话先写到一个内存队列里，再慢慢入库。
没太大压力吧。

数据库的设计要考虑分区表，ORACLE的概念，不知道SQLSERVER有没有类似的东西。

一天三百万，高峰期每秒写入估计也就200个并发，这并发量不算大的。

最傻的办法：多买几台机器做集群，肯定可以。

费点力气的办法：弄一个NoSql数据库，比如MongoDB或者Redis，300万个写入先写进这个NoSql数据库，然后SqlServer慢慢从这个NoSql数据库里面读出来顺序写入。

还可以倒过来做：用程序去读取这些站点的数据，然后批量插入SqlServer，批量插入效率比逐条插入高不少，也能够控制系统压力。

也可以从根本上解决：做个数据大集中，所有站点都直接用中心站点的数据库，不用同步！搞定。

数据是从每个站点通过集线器采集上来的，不可能直接用中心站点的数据库

最关键的问题是要对所有的数据做查询统计，要怎么样去优化，希望大牛们能给点建议

查询统计优化有两个方面：第一，进行sql优化；第二，对表进行分区分区，可以提交查询效率，如果有条件查询，在查询条件上建立索引（索引不能太多，索引太多影响写入效率）。

总得先入库吧。入库后想怎么优化都行。

300万的数据入库的话，这个数据量不算大，也不算小。原则上来说直接入库来写也不是问题...当然这么说与你的需求是不符的。

通用的做法就是使用一个消息队列，比如ActiveMQ、RocketMQ等等。然后你的1500个站点就把数据写入到消息队列里，然后开发一个多线程任务程序从消息队列里获取数据并写入到相应的统计数据库。这样子可以在多线程任务中人为控制每秒的写入量。

当然除了通用做法，针对MySQL的话如果只考虑写入操作，HandlerSocket也是个不错的选择。

300万一天没什么问题。我试过　Ｐｏｓｔｇｒｅｓ．单表
日产生数据２５０万。查询毫无问题。