一、硬盘读写速率
　　最快的内部传输速率（缓存至介质存储），仅80MB/s（15000转SCSI）。7200转的SATA硬盘，平均应介于20-40MB/s之间。
三块Raid0，可理解为至少 60MB/s，相对于 7.6M/s 已经够用。

二、硬盘写占用分析
　　首先，操作系统占用，以读为主，写主要是页面文件及各类Log文件。由于内存够大，可忽略至20%。
　　其次，数据库占用，现假定数据库对内存使用效率较高，不会出现数据库抖动。于是，数据库写主要发生在写Log的场合（从这个意义上讲实际上与写文件速率相当）。

　　当然，实际上系统远比以上的简化分析复杂。

三、着重考虑数据库写
　　不论是插入、更改还是删除，数据变化在内存中进行，而文件方面，数据库则是将变化首先写入Log文件，当Log文件满足某条件时才真正批量更新库文件数据块。对于OLAP应用，往往将Log文件设定为合适大小，令数据块的更新频度降低（如半小时才发生一次）。从而可以知道Log文件的写是最主要因素。

　　主要以插入进行讨论。

　　进一步分析写Log文件前发生了什么。
　　插入语句的解析。插入变量，比直接用语句，可减少解析工作。
　　假定一个表，无主键及其他索引，只是简单地不断插入，则与写文件雷同，不同的在于数据库系统还需维护数据字典信息，因而还会有其他操作。初期并无异常。但现实中，对一个无索引的大表进行查询是不可想象的，一般都要求至少有主键。
　　假定一个表，有主键（唯一索引），那么插入前会发生唯一性判断，基本属于内存操作。并且更新索引。初期也无异常。
　　假定一个表，有主键（唯一索引）外还有其他索引，那么除以上动作外还会更新其他索引。

　　综上所述，表数据量将成为最大的一个变化因子。只要表数据量足够大，必然附加产生硬盘动作。设想一种极端情况，表足够大，数据库不得不及时更新硬盘数据块，同时索引也足够大，也必须更新硬盘数据块。此前还会写Log文件，那么，硬盘占用量就会大增，性能也会急剧下降。何况查询时也可能需读硬盘。

　　目前业界的数据库，MySQL是百万级单数据库最快，而SQL-Server/Sysbase只在单库千万级上表现良好，如果表记录数量巨大，单表超过数亿条，除硬件条件的充分论证与准备外，建议采用Oracle或DB2，并充分利用数据库所提供的各种优化措施进行全面优化，如表分区，分区索引，表与索引分离在不同表空间上，ＳＱＬ编程遵从ＤＢＡ建议等措施。

　　预计目前想要达到15000条/s，平均每条在1k数量级，初期没有问题。预计在数据表足够大时，性能将直线降低。例如表数据量达到数亿条时。

　　在数年前曾使用Oracle数据库（绕开文件系统使用裸设备建库），单SCSI硬盘，从多文件读取数据插入80亿条短信，初期4000条记录每秒，在运行17小时后，即接近30亿条记录时，性能骤降至1700条随后不久降至400条。事后究其原因，是因为索引与表均已经大到需要读写硬盘而不能完全钉在该主机的内存中，硬盘读写次数增加。

　　建议进行完整的性能测试，在采用了所有优化手段后进行，预计测试时间应可在３天内完成。


---------------
上面的是我一个DBA哥们的结论


另：在电信级解决方案中，使用mysql做此类小数据量高负载写入是有优势的