数据存储插入性能测试笔记

SQL Server怎么也启动不了了(忘了我原来对它做了啥了),懒得折腾或者装别的数据库了,引用下网上查到别人的。

http://www.sqlite.org/cvstrac/wiki?p=SpeedComparison

需要说明的是SQLite老版本第一个1000插入的测试似乎比这个快得多,见这里: http://www.sqlite.org/speed.html

http://www.mongodb.org/pages/viewpage.action?pageId=1475411

http://sqlserverperformance.wordpress.com/2010/02/07/some-initial-insert-test-benchmarks-on-sql-server-2008-r2/

我的结果,老机PD820,7200RPM SATA硬盘,插入是1620条的情况下:每条都sync到磁盘上的话,1.6秒;如果不sync,是0.2秒,大概每秒8000多。当前还不包括查询和其它操作,没有做完;不过做完了也没法和SQL类的比了。

这是python版的结果,生成数据就得用0.015秒,算上其它逻辑的开销,将来C版nosync应该能再提高50%到200%,sync是没戏了(瓶颈在IO)。说白了就是达到和别人相似的性能应该没什么脑力障碍,也无需参考别人的算法。

不过现在已经比别人快或者和别人差不多快是不作数的。SQL Server这样要干一大堆额外工作的就不要说了,SQLite、Mongo之流也都有更多动作降低速度。等我这个实现完整了也避免不了,毕竟这东西在底层基本是同质化的。

关于SQL Server,上面那个测试里提到如何提速写日志的时间,这个想根本解决只有靠硬件。因为日志的保障数据不出问题的原理就是,每次必须写到硬盘上,接下来才做真正的更新操作。SQLite也有事务,但它这块简单得多。

其实现在数据库的测试对一般人完全没有参考价值。就我的实践来看,对于数据库的局部设计和实现,绝不可能有什么突破性的东西,最多是些许的提高。恰恰是慢的数据库更应该引起兴趣:它提供了什么特性,让它不得不付出代价?

如果nosync的话,很显然还得至少保证下数据不会因为掉电、死机、崩溃之类的意外事故损坏数据。另外可以提供批量操作的接口让使用者选择是不是马上写回硬盘。这就有点事务的意味了,不过谨记不要真的实现完整数据库功能。

注意:批量操作并非说就是根据用户申请临时nosync就够,很显然的,比如bulkinsert一类的功能,明显应该把数据记录在内存里拼接在一起,一次性写入一大坨。想必SQLite在一个Transcation里每秒3、4万的插入就是这么来的。

另外,印象里BerkeleyDB在某些测试中有特别可怕的插入性能,10倍左右于SQLite的操作数,这个有空得确认和研究一下(估计是上面方法加吃内存吃出来的)。不过这个初步考虑不是应该优先去做的事情,因为使用场景并不多。

顺便夸奖python两句,虽然慢的吓人,但风格比较适合原型包括算法类的,慢能放大瓶颈反而对找问题有帮助 -_-。

posted on 2011-06-22 03:37  怪怪  阅读(667)  评论(0编辑  收藏  举报

导航