Netflix公布Cassandra新性能:基于AWS的百万次写入每秒

2014-8-11 17:38| 发布者: joejoe0332| 查看: 3418| 评论: 0|原作者: 应玲|来自: CSDN

摘要: 盘点AWS生态圈，Netflix无疑是其最有价值用户之一——在公布了大量基于AWS开源工具及调优的同时，还发表了多个AWS环境下高价值的基准测试。近日，Netflix在更贴近现在生产环境下重测了Cassandra性能。 ...

　　盘点AWS生态圈，Netflix无疑是其最有价值用户之一——在公布了大量基于AWS开源工具及调优的同时，还发表了多个AWS环境下高价值的基准测试。近日，Netflix在更贴近现在生产环境下重测了Cassandra性能。

以下为译文：

　　在2011年11月发表的文章“ NetFlix测试Cassandra——每秒百万次写入”中我们展示了Cassandra （C*）如何在集群节点增加时实现性能线性增长。随着新型EC2实例类型的产生，我们决定重做一次性能测试，与之前帖子不同，这次的重心不是C*可扩展性，而是量化这些新实例的性能指标。下面是此次测试的详细信息及结果。

节点数量，软件版本及配置信息

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连接范畴，是网络拓扑结构里比较典型的实际产品案例。