数据存储插入性能测试笔记
2011-06-22 03:37
369 查看
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两句,虽然慢的吓人,但风格比较适合原型包括算法类的,慢能放大瓶颈反而对找问题有帮助 -_-。
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两句,虽然慢的吓人,但风格比较适合原型包括算法类的,慢能放大瓶颈反而对找问题有帮助 -_-。
相关文章推荐
- 大数据应用之HBase数据插入性能优化之多线程并行插入测试案例
- 大数据应用之HBase数据插入性能优化之多线程并行插入测试案例
- 大数据应用之HBase数据插入性能优化之多线程并行插入测试案例
- 高性能Javascript笔记 数据的存储与访问性能优化
- [Php-Mysql]多条数据的循环插入和一次性插入的性能测试
- 数据库插入大量数据性能测试——批处理+事务VS普通插入
- Sql语句与存储过程查询数据的性能测试实现代码
- 【SQL】SQL数据库性能测试,插入数据
- Entity Framework与ADO.NET批量插入数据性能测试
- Python向Sqlite批量插入数据,测试硬盘性能
- 使用JDBC插入大量数据的性能测试
- mysql利用存储过程插入测试数据
- mysql存储过程插入固定数量测试数据
- 高性能Javascript笔记 数据的存储与访问性能优化
- 通过loadrunner 11常规通用的C语言API类型的Vuser 方式,测试验证MySQL数据库插入、查询、修改、删除数据性能脚本实例
- Oracle和MySQL数据插入性能测试
- 大量数据情况下单线程插入和多线程(高并发)insert数据库的性能测试
- Sql语句与存储过程查询数据的性能测试实现代码
- 大量数据情况下单线程插入和多线程insert数据库的性能测试
- JDBC批量插入数据的性能测试