MongoDB和Tokyo Tyrant性能比较.docVIP

MongoDB与Tokyo Tyrant性能比较 MongoDB与Tokyo Tyrant性能比较2010年11月15日星期一下午11：10(1)：基础CRU操作 以前的项目大都把数据存放在关系型数据库中，关系型数据库的优势在于使用普及，资料丰富，且有大量辅助类库来简化开发。当然它们的问题比较明显的，一是在数据量上升的情况下伸缩性比较差，且进行结构调整的代价比较高。因此现在有个所谓NoSQL的运动也逐渐普遍起来了，它便是借助一些非关系型存储方式来开发项目(个人认为其实将它解释为Not Only SQL更为合适)。因此在新项目里，我也想尝试一下使用之前一直只是听说的存储方式。 在和同事的交流过程中，我了解到他们的项目正在尝试使用Tokyo Tyrant(后称TT)进行存储，并且据说效果不错，因此我一开始也打算尝试使用TT进行主要存储，为此也花了一定时间为其编写.NET平台下的驱动程序。不过在驱动程序的开发过程中，我逐渐意识到TT的功能有着严重的限制，似乎并不适合作为接下来项目的主要存储方式。因此，我又将眼光转向了之前关注过的MongoDB上。MongoDB也是NoSQL的代表之一，是一个面向文档的，架构灵活(Schema-less)的存储方式，在仔细阅读相关资料之后，我发现它的功能与TT相比可谓天上地下，非常适合许搭建各类项目(关于这点以后有机会再谈)。 不过，既然选择NoSQL的原因是性能，那么他们的性能表现究竟如何呢?TT的性能表现在业界非常出名，而MongoDB的使用便相对较少了(当然，官网列举了不少案例，最近著名的开源网站SourceForge也打算使用MongoDB重新设计他们的网站)。为此，我决定亲手比较一下两者的性能表现。 测试环境及数据 由于缺乏合适的环境，因此我不得不在我的MBP上进行这次性能比较，参数如下： OS：Mac OS Xv 10.6.2(Snow Leopard)RAM：4GB/1067MHz/DDR 3CPU：2.53GHz Intel Core 2Duo64-bit Kernel and Extensions：YesTT在64 bit环境下编译，MongoDB使用64 bit版本。在测试执行时，我尽量关闭多余的应用程序，避免其它因素造成影响。同样，由于条件限制，我只得把客户端和服务器跑在同一台机器上。测试代码使用Ruby编写，这是由于两者都有官方提供的驱动程序。此外，由于我对于两者的优化都不太熟悉，因此它们都使用了默认的配置。 关于测试数据，我将存入110万条新闻数据，包含以下字段： ID：标识，32位整数，带索引Title：标题，字符串CategoryID：分类ID，32位整数，带索引CreateTime：日期，保存为32位整数，带索引UserID：用户ID，32位整数，带索引Tags：标签集合，字符串数组，带索引Source：来源，字符串SourceUrl：来源URL，字符串Status：状态，32位整数为了相对接近真实的环境的数据分布特征(便于以后进行查询操作比较)，我设计了这样的测试数据(具体可阅读代码)： 2万个分类，分别拥有10个至100条新闻，总共110万条记录。1万个用户，根据分类id取模得到其归属。创建时间从2010年1月1日起递增，每条记录增加1秒。每条记录拥有2到6个Tag，除了其中一个之外，都从一个1.7万个Tag库中获取。每条记录的字符串字段都不长(20-30字符)由于TT只支持字符串的值(但可以建立数字索引，会将字符串当作数字来识别)，因此事实上所有的值都会转化为字符串进行保存。此外，由于存在根据Tag查找新闻的业务，因此对于Tags字段也建立了索引，其中MongoDB直接支持对字符串数组的索引(索引其中每个元素)，而在存入TT时则转化为空格分隔的字符串，并为其建立倒排索引(Token Inverted Index)以便进行全文查找。 在存储方式上，所有数据将放入MongoDB的同一个集合内，而TT则选用Table Database存储结构。在使用TT时，另一种做法是完全使用键值对来保存一条记录的各个字段，不过这样做会大大限制TT的功能，或是会为系统编写带来额外的复杂度，便不考虑Hash/B+Tree/Fixed-length等存储方式了。 插入操作性能比较 具体代码在tt-insert.rb及mdb-insert.rb文件中。两段代码均使用一个连接，使用循环每次插入一条：由于如果每次都建立连接，会在TCP/IP连接的打开关闭上消耗大部分时间，由于实际项目中基本都会使用连接池等机制来复用连接，因此这方面便不多做考虑；再者，由于实际插入时几乎不可能批量操作，因此这里并不使用两者提供的批量插入功能。脚本每插入10万条记录便打印出所耗时间，结果如下： 从结果上看，Mongo