最近给电信做的一个项目需要设计这样一个数据库来保存原始数据，要求的设计流量是1秒500个输入数据，每个数据都包含一个大约4k的数据段和其它的一些信息，我初步设计了一个单实例数据库，但是当数据量超过1000万行以后，插入效率明显下降，请大家帮忙提提建议，如何来实现这样一个数据库，在大数据量情况下确保插入数据的效率。
------解决方案--------------------
这的确是个问题!
你要考虑不光是插入效率的事情，还有查询效率、更新效率、编程方式、用户访问习
惯等多方面的问题。
有如下方案，不知是否可行？
建立数据总表及两个缓冲表，结构完全相同，将数据先插入其中一个缓冲表中，等到
一定时间(插入效率降低之前)，转向插入另一个缓冲表，同时启动一个后台进程将第
一个缓冲表的的数据转入总表，转入总表后删除第一个缓冲表中的数据; 再等到一定
时间(还是插入效率降低之前)，转向插入第一个缓冲表，这时启动一个后台进程将第
二个缓冲表的的数据转入总表，转入总表后删除第二个缓冲表中的数据; 如此循环往
复...
如果后台进程处理的时间超过两个缓冲表的循环周期的话，甚至可以考虑建立三个乃
至四个缓冲表。
当然如果以上方法可行的话也不过是解决了插入效率的问题，其它如查询效率等还是
不能解决，而且查询的方式也要有所不同。
按时间分区也是一种解决方案，磁盘阵列更是从硬件角度来考虑，都是这种海量型数
据库必不可少的解决措施。
------解决方案--------------------
可能是产生了大量日志
故障还原模型改为 '简单 '
------解决方案--------------------
电信的这种需求确实比较变态，他基本上没有一个可以利用的缓冲时间，而且每日的数据量又特别大，有个朋友以前做过电信的项目，他有个方法，说出来供你参考一下：
大体上类似cuckoo1(布谷鸟)的建议，只不过所建的缓冲表更多一些。
按照一天24小时建立24个缓冲表，不同时间的数据放在不同的缓冲表中，每小时导入一次缓冲表的数据并在导入完成后清除（这个必须有个数据完整的验证处理）。
查询的时候一般不可能直接去那个超大的表里去找。还会有N个以月为单位的子表。
而且一般需要分析数据的时候不会看这么明细的记录，会有一些针对各种查询定期产生的聚合表。
以上纯属个人建议，仅供参考。
------解决方案--------------------
顺便罗嗦一下，这种需求最好不要放在同一个服务器上，插入缓冲的和最后的总表最好位于不同的服务器，否则效率仍旧无法提升。按照以上的方法，1小时内不一定能够处理完这一个小时所产生数据，这个时候下个表的处理将被延迟，如果在同一服务器上，由于负载过重，这种延迟肯定会越来越严重，直至无法按时导入完整的数据（不过这种可能性比较小~_~）。总之，如果有条件的话，就分开在不同的服务器上，这样数据插入的服务器（实时更新的服务器）的速度就可以得到保障。
------解决方案--------------------
SAN/NAS存储
------解决方案--------------------
"超过1000万行以后，插入效率明显下降 "
索引在作怪