“在更多的备选方案，选择更加困难。”- 阿贝” D'Allanival
2010年，当全世界被云系统的能力和为其服务的新数据库迷住时，雅虎的一组研究人员决定进行调查NoSQL的。他们开发了YCSB框架来评估新工具的性能，并找到使用它们的最佳案例。结果发表在论文《用YCSB对云服务系统进行基准测试》上。
雅虎球员的表现非常出色，但像任何纸张，它不能包括一切：
●这项研究没有提供我们分析所需的所有信息。卡珊德拉、HBase、雅虎的PNUTS和一个简单的shardedMySQL的实施进行了分析，一些我们经常一起工作的数据库并未涉及到。
●虽然
●雅虎采用的高性能的硬件，而这将是大多数企业看到这些数据库的平均硬件如何执行更为有用。
作为研发工程师Altoros系统公司,一个大数据作为专家，我们被雅虎的努力所鼓舞，决定加入我们自己的努力。本文是基于在不同系统工作负载下测量的性能，对NoSQL数据库进行的独立于供应商的分析。
是什么让这个独特的研究？
非关系数据库通常被称为NoSQL，它结合了存储和使用大数据的能力，具有灵活性和可伸缩性云计算系统，所有这些使得它们非常流行。NoSQL数据管理系统本质上是无模式的(没有过分的复杂性和灵活的数据模型)，并且最终是一致的(符合BASE而不是ACID)。它们有一个简单的API，提供大量数据并提供高吞吐量。
2012年NoSQL产品数量达到120多款，并且还在不断增长。这种多样性使得为特定情况选择最佳工具变得困难。数据库供应商通常使用定制的硬件和软件设置来衡量其产品的生产力，以展示其解决方案的优势。我们想做独立和公正的研究，以补充雅虎员工所做的工作。
使用Amazon虚拟机来确保可验证的结果和研究透明度(这也有助于最小化由于硬件差异造成的错误)，我们分析和评估了以下NoSQL解决方案:
●卡桑德拉，列家族商店MongoDB，一个面向文档的数据库
●HBase的（面向列的，太）
●
Riak，键值存储
我们还测试了MySQL集群和切分MySQL，以它们作为基准。
经过一番的结果已经呈现给公众，一些观察家说MongoDB的不应该相比其他NoSQL数据库，因为它更针对内存直接合作。我们当然明白这一点，但本次调查的目的是确定不同的NoSQL产品的最佳使用案例。因此，数据库在相同的条件下测试，而不管其具体的。
工具，库和方法
对于基准测试，我们使用雅虎云服务基准测试，它由以下几部分组成：
●与工作负载生成器的框架
●一组工作负荷方案
我们已经在某些类型的工作负载的测量数据库的性能。的工作负荷被分配给两个主要的选择不同的分布定义为：
•它要执行的操作
•读或写哪个记录
对数据存储的操作是随机选择的，可以是以下类型:
•插：插入一个新记录。更新：通过替换一个字段的值更新记录。读:读取一个记录，随机选择一个字段，或读取所有字段。扫描:按顺序扫描记录，从随机选择的记录键开始。要扫描的记录数量也从1到100之间随机选择。
•
•
•
每个工作负载定位于100,000,000记录的表;每个记录在大小1,000字节和含有10个字段。识别每个记录的主键，这是一个字符串，如“user234123”。每个字段被命名为field0，FIELD1，等等。每个字段中的值是一个ASCII字符的随机串，100字节的每个。
数据库性能是由数据库计算基本操作的速度定义的。基本操作是由工作负载执行器执行的操作，它驱动多个客户机线程。每个线程通过调用数据库接口层来加载数据库(加载阶段)和执行工作负载(事务阶段)，依次执行一系列操作。线程控制它们生成请求的速度，以便我们可以直接控制针对数据库提供的负载。此外，线程测量操作的延迟和已实现的吞吐量，并将这些测量结果报告给统计模块。
评估系统在不同工作负载下的性能:
工作量A:频繁更新
工作量B:主要阅读
工作量C：只读
工作量d：阅读最新
工作量E：扫描范围短
工作量F：读 - 修改 - 写
工作负载G：写重
每个工作量定义为:
1）的操纵记录的数量（读或写）
2）每每个记录的列数
3)记录的总大小或每列的大小
4）的线程数用于加载系统
这项研究还规定了每种类型的工作负载的配置设置。我们使用以下默认设置：
1)一亿记录被操纵
2）记录的总大小等于1Kb的
3)每条记录有10个100字节的字段
4)与系统的多线程通信(100个线程)
测试环境
为了提供可验证的结果，进行了基准测试Amazon弹性计算云实例。雅虎云服务基准测试客户端部署在一个大型亚马逊实例：
•7.5GB内存
•4个EC2计算单元（两个虚拟芯具有两个EC2计算单元的每个）
•实例存储850GB
•64位平台
•高I / O性能
•EBS-Optimized (500 mbps)
•API名称:m1.large
在NoSQL数据库中的每一个部署在亚马逊特大场合的同一地理区域的四节点集群：
•内存15GB
•8个EC2计算单元(4个虚拟核，各有两个EC2计算单元)
•实例存储1690GB
•64位平台
•高I / O性能
•EBS优化的（千兆）
•API名称:m1.xlarge
亚马逊经常被指责为它的高I / O等待时间和相对较慢EBS性能。为了减轻这些缺点，EBS盘已经装配在RAID0阵列剥离之后，他们能够提供高达两倍更高的性能。
结果
当我们开始对NoSQL数据库进行研究时，我们希望得到公正的结果，以显示哪种解决方案最适合每个特定任务。这就是为什么我们决定在不同类型的负载下测试每个数据库的性能，并让用户决定哪种产品更适合他们的需求。
我们从测量负载阶段开始，在此阶段，将1亿条记录(每个记录包含10个字段，每个字段包含100个随机生成的字节)导入到一个四节点集群。
HBase演示了迄今为止最好的编写速度。在启用了预创建的区域和延迟日志刷新后，它达到了40K ops/秒。Cassandra在加载阶段也表现出了很好的性能，大约15K ops/秒。首先使用append方法将数据保存到提交日志中，这是一个快速操作。然后，它被写入一个称为Memtable的每列族内存存储。一旦Memtable被填满，数据就被作为SSTable保存到磁盘上。顺便说一下，在“仅在内存中”模式下，MySQL集群可以显示更好的结果。
*工作负载A:大量更新模式。工作负载A是一个大量更新的场景，它模拟数据库工作，在此过程中记录电子商务解决方案用户的典型操作。工作负载设置：
1）读/更新比：50/50
2) Zipfian请求分发
在更新过程中，HBase和Cassandra远远领先于主组，平均响应延迟时间不超过2毫秒。HBase甚至更快。HBase客户端被配置为关闭了自动刷新。一旦缓冲区满了，更新就会聚集在客户端缓冲区中，挂起的写操作就会异步刷新。的更新处理服务器，则启用了延迟日志刷新，刷新期间的沃尔编辑保存在内存中。
Cassandra将这个突变写到提交日志中以备事务之用，然后更新一个内存中的记忆表。与HBase延迟日志刷新相比，这是一个较慢但更安全的方案。
*工作量：读。在读取，每列族压缩提供的HBase和Cassandra的有更快的数据访问。HBase的配置有原生LZO和卡桑德拉与谷歌的斯纳皮压缩编解码器。虽然计算运行时间越长，压缩减少从磁盘读取的字节数。
*工作负载B:重读模式。工作负载B由95%的读和5%的写组成。内容标记可以作为匹配此工作负载的示例任务;添加标记是一种更新，但大多数操作都意味着读取标记。“主要读取”工作负载的设置:
1)读取/更新比率:95/5
2) Zipfian请求分发
Sharded MySQL的读取性能最好。MongoDB——由“内存映射文件”类型的缓存加速——与这个结果很接近。MongoDB中的所有磁盘I/O都使用了内存映射文件。Cassandra的键和行缓存支持快速访问频繁请求的数据。由于在0.8版本中增加了堆外行缓存特性，它在使用更少的行内存的同时显示了出色的读取性能。键缓存在内存中按列系列保存键的位置，并为存储行的SSTable定义偏移量。有了键缓存，就不需要在SSTable索引文件中查找行位置。由于有了行缓存，我们不必从SSTable数据文件中读取行。换句话说，每个键缓存命中保存了一个磁盘查找，每个行缓存命中保存了两个磁盘查找。在HBase中，随机读取的性能比较慢。 However, Cassandra and HBase can provide faster data access with per-column-family compression.
*工作量B:更新。由于延迟的日志刷新，HBase在大量写操作下显示了非常高的吞吐量和极小的延迟。打开延迟日志刷新后，编辑将首先提交到memstore。然后将聚合的编辑异步刷新到HLog。在客户端，HBase写缓冲区将自动刷新选项设置为true来缓存写操作，这也极大地提高了性能。为安全目的，HBase的其预写日志达到内存HDFS副本的特定号码后确认每个写。HBase的与存储器写等待时间提交是大致等于数据传输的通过网络的等待时间。卡桑德拉表现出极大的写吞吐量，因为它第一次写入提交日志 - 使用append方法，这是一个非常快速的操作 - 然后以所谓的memTable每列家族记忆存储。
*工作负载C:只读。工作负载设置：
1)读取/更新比率:100/0
2) Zipfian请求分发
这个只读负载模拟数据缓存系统。该数据被储存在系统之外，而应用程序只阅读它。由于B树索引，分片的MySQL成为了本次比赛的冠军。
*工作负载E:短范围扫描。工作负载设置：
1)读取/更新/插入比率:95/0/5
2）最新请求分配
3）最大扫描长度：100个记录
4)扫描长度分布均匀
HBase的范围扫描性能优于Cassandra。HBase扫描是HRegionScanner执行的一种分级快速合并排序操作。它合并从HStoreScanners接收到的结果(每个家族一个)，而HStoreFileScanners依次合并从HStoreFileScanners接收到的结果(家族中的每个文件一个)。如果打开了缓存，服务器将只提供指定记录的数量，而不是返回到HRegionServer来处理每个记录。
Cassandra的一个随机分区扫描性能相比0.6版本，在该功能最初引入相当大的改善。
Cassandra的SSTable是一个排序字符串表，可以将其描述为按键排序的键-值字符串对文件和按特定顺序写入的键-值对文件。为了在范围扫描中获得最大的性能，我们必须使用一个保持顺序的分词器。扫描保持顺序的行范围非常快。它类似于在连续索引中移动游标。但是，数据库不能在集群中均匀地分布单个键和相应的行，因此使用随机分区器来确保数据的均匀分布。这是Cassandra中默认的分区策略。随机分区确保了良好的负载平衡，并通过保留顺序的分区器为范围扫描提供了一些额外的速度。
在MongoDB中2.5，表扫描由触发{：{“$ GTE”：“_id” startKey}}的查询表明，最大吞吐量20个操作/与≈1秒的延迟秒。