【编者按】盘点AWS生态圈，Netflix无疑是其最有价值用户之一――在公布了大量基于AWS开源工具及调优的同时，还发表了多个AWS环境下高价值的基准测试。近日，Netflix在更贴近现在生产环境下重测了Cassandra性能。
免费订阅“CSDN大数据”微信公众号，实时了解最新的大数据进展！
CSDN大数据，专注大数据资讯、技术和经验的分享和讨论，提供Hadoop、Spark、Imapala、Storm、HBase、MongoDB、Solr、机器学习、智能算法等相关大数据观点，大数据技术，大数据平台，大数据实践，大数据产业资讯等服务。
以下为译文：
在2011年11月发表的文章“ NetFlix测试Cassandra――每秒百万次写入”中我们展示了Cassandra （C*）如何在集群节点增加时实现性能线性增长。随着新型EC2实例类型的产生，我们决定重做一次性能测试，与之前帖子不同，这次的重心不是C*可扩展性，而是量化这些新实例的性能指标。下面是此次测试的详细信息及结果。
此次测试的C*集群运行于Datastax 3.2.5企业版，C*版本为1.2.15.1，共有285个节点。实例类型为i2.xlarge器，运行于Heap为12GB的JVM 1.7.40_b43之上。使用的OS为Ubuntu 12.04 LTS。数据与日志使用相同的EXT3格式挂载文件。
尽管上次测试使用了较高规格的m1.xlarge服务器，此次测试的吞吐量结果依然与上次持平，而且选择（支持SSD）i2.xlarge规格服务器更加贴近现实用例，能更好的展示其吞吐量与延迟。
完整的schema如下：
create keyspace Keyspace1
with placement_strategy = ‘NetworkTopologyStrategy’
and strategy_options = {us-east : 3
and durable_writes = true;
use Keyspace1;
create column family Standard1
with column_type = ‘Standard’
and comparator = ‘AsciiType’
and default_validation_class = ‘BytesType’
and key_validation_class = ‘BytesType’
and read_repair_chance = 0.1
and dclocal_read_repair_chance = 0.0
and populate_io_cache_on_flush = false
and gc_grace = 864000
and min_compaction_threshold = 999999
and max_compaction_threshold = 999999
and replicate_on_write = true
and compaction_strategy = ‘org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy’
and caching = ‘KEYS_ONLY’
and column_metadata = [
{column_name : 'C4',
validation_class : BytesType},
{column_name : 'C3',
validation_class : BytesType},
{column_name : 'C2',
validation_class : BytesType},
{column_name : 'C0',
validation_class : BytesType},
{column_name : 'C1',
validation_class : BytesType}]
and compression_options = {‘sstable_compression’ : ”};
请注意到这里的min_compaction_threshold和max_compaction_threshold值很高，尽管在实际产品中不可能使用完全一致的数据，但也能实际反映我们所想掌握的数据。
客户端
客户端应用程序使用Cassandra Stress，有60个客户端节点，实例类型为r3.xlarge，为之前m2.4xlarge规格实例数量的一半，价格也是之前的一半，但依然能够推动所需负载（使用线程低于40%）并达到与之前相同的吞吐量。客户端运行在基于Ubuntu 12.04 LTS系统的JVM 1.7.40_b43之上。
网络拓扑
Netflix的Cassandra集群有3个副本，部署在3个不同的可用区域（Availability Zones，即AZ）。这样，如果其中一个AZ断电，余下的2个副本依然可以继续工作。
之前帖子里所有的客户端都部署同一个AZ中，这次的改变遵从实际产品都部署在三个不同AZ的真实应用场景。客户端请求一般交于相同AZ的C*节点，我们称之为zone-aware连接，这一特征被构建到Netflix C* Java客户端Astyanax中。Astyanax客户端通过查询记录信息向相应实例服务端发送读写请求。尽管C*协调器能够实现所有请求，但当实例不在副本集中的情况发生时，则需要一个额外的网络跃点，即token-aware请求。
此次测试使用Cassandra Stress，因此不需要token-aware请求。而通过一些简单的grep和awk-fu，我们可以得知此次测试属于zone-aware连接范畴，是网络拓扑结构里比较典型的实际产品案例。
延迟及吞吐量测量
我们已经文档化了使用Priam完成令牌任务、备份和存储的方法。Priam内部版本添加了一些额外功能，我们使用Priam协助收集C* JMX自动测量结果并发送到分析平台Atlas, 此功能将在未来几周添加至Priam 开源版本中。
以下是用于测量延迟与吞吐量的JMX属性：
延迟
吞吐量
测试
我执行了以下4组测试:
100%写入
与原帖测试不同，此次测试展示了持久性大于每秒100万次写入的用例。现实中只写入的应用程序很少，这种类型的应用要么是遥测系统要么是物联网应用，其相关测试数据被输入BI系统进行分析。
CL One
与原帖测试相似，此次测试运行在CL One上。其平均延迟略高于5毫秒，第95百分位为10毫秒
每个客户节点都运行如下Cassandra Stress命令：
cassandra-stress -d [list of C* IPs] -t 120 -r -p 7102 -n 1000000000 -k -f [path to log] -o INSERT
CL LOCAL_QUORUM
为了保证用例读入的高一致性，这次我们测试了运行于LOCAL_QUORUM CL上吞吐量大于每秒百万次写入的用例。每秒100万次写入吞吐量平均延迟低于6毫秒，第95百分位为17毫秒
每个客户节点都运行如下Cassandra Stress命令：
cassandra-stress -d [list of C* IPs] -t 120 -r -p 7102 -e LOCAL_QUORUM -n 1000000000 -k -f [path to log] -o INSERT
综合测试――10%写入90%读入
每秒100万次写入只是一个醒目的标题，大多数应用程序都是读写混合的。在对Netflix主要应用程序调研之后，我决定做一个10%写入90%读入的综合测试，这一混合测试占用总线程的10%用于写入90%用于读取。这虽然不是实际应用程序的真实复现，但也能很好的测量数据拥塞时集群吞吐量及延迟
CL One
使用CL One配备时，C*实现了最高的吞吐量及可用性，开发人员需要接受其结果的一致性，并模仿这一范例设计他们的应用程序。
每个客户节点都运行如下Cassandra Stress命令：
cassandra-stress -d $cCassList -t 30 -r -p 7102 -e LOCAL_QUORUM -n 1000000000 -k -f /data/stressor/stressor.log -o INSERT<br>cassandra-stress -d $cCassList -t 270 -r -p 7102 -e LOCAL_QUORUM -n 1000000000 -k -f /data/stressor/stressor.log -o READ
CL LOCAL_QUORUM
大多数用C*开发的应用程序都将默认为CL Quorum读写，这为其相关开发人员进入分布式数据库系统提供了机会，也避免了解决应用程序最终一致性的难题。
每个客户节点都运行如下Cassandra Stress命令：
cassandra-stress -d $cCassList -t 30 -r -p 7102 -e LOCAL_QUORUM -n 1000000000 -k -f [path to log] -o INSERT<br>cassandra-stress -d $cCassList -t 270 -r -p 7102 -e LOCAL_QUORUM -n 1000000000 -k -f [path to log] -o READ
费用
这次测试的总开销包括EC2实例费用和inter-zone网络流量费用，我使用Boundary监控C*网络使用情况。
上图显示了可用服务区域间30Gbps的传输速度。
这里是执行每秒100万次写入测试的费用：
|
Instance Type / Item |
Cost per Minute |
Count |
Total Price per Minute |
|
|
i2.xlarge |
$0.0142 |
285 |
$4.047 |
|
|
r3.xlarge |
$0.0058 |
60 |
$0.348 |
|
|
Inter-zone traffic |
$0.01 per GB |
3.75 GBps * 60 = 225GB per minute |
$2.25 |
|
|
Total Cost per minute |
$6.645 |
|||
|
Total Cost per half Hour |
$199.35 |
|||
|
Total Cost per Hour |
$398.7 |
结语
大多数企业可能不需要处理这么多数据，这项测试很好的展示了新型AWS i2和r3实例类型的花费、延迟及吞吐量。每一个应用程序都是不一样的，你的情况也会不尽相同。
这次测试耗费了我一周的空闲时间，并不是一个详尽的性能研究，我也没有对C*系统或JVM作深入调研，你有可能会比我做的更好。如果你有兴趣研究大规模分布式数据库及性能提升，欢迎加入Netflix CDE组。
原文链接：Revisiting 1 Million Writes per second（翻译/应玲 责编/仲浩）
上一篇 深圳综合交通设计研究院张
程序员人生，我编程，我富裕，记住wfuyu网，php教程，php学习，php手册，CMS模版制作
声明：本站大部分内容是作者原创，少部分收集于互联网供大家一起学习，原版权很多不明，如有侵权请联系本站，谢谢！
粤ICP备14040726号-1 2015-2020 程序员人生 版权所有
