NetFlix测试Cassandra:-每秒百万次写

测试云产品的工具也需要云，Netflix最近使用Amazon的云计算对云存储NoSQLCassandra进行了一次性能测试：
The Netflix Tech Blog: Benchmarking Cassandra Scalability on AWS - Over a million writes per second

Netflix已经使用Apache Cassandra NoSQL作为生产环境数据存储已经六个月了，他们测试部门决定对其进行一次全面的性能测试。通过这次测试帮助开发队伍更加有效地使用Amazon的Aws。

这次测试是基于Amazon的云计算平台AWS进行的，他们把Cassandra部署在Amazon的EC2服务器中，一共创建了288个实例，分散在美国东部三个地方，每个地方96个实例，另外使用60实例用户客户端测试，运行每秒1.1百万的压力程序，三个不同数据中心之间以每秒3.3百万写操作进行数据复制。整个测试在两个小时内完成，花费几百元。

测试时是从48 96 144到288实例逐步增加的，测试显示吞吐量也是线性增加，测试软件使用Cassandra 0.8.6，完全是生产环境配置，EC2创建288个用了15分钟，共66分钟，剩余时间启动Linux和Tomcat JVM已经在其上运行自动测试程序，启动Cassandra JVM等等。

配置是使用EC2的m1.x1规格服务器，四个中速CPU 15G内存，4个400G硬盘，也有使用m2.4xl规格八CPU 68G和两个800G硬盘，网络环境都是每秒1G带宽，操作系统是CentOS 5.6和XFS，Cassandra的commit日志和数据文件保存在磁盘文件系统。60测试客户端是使用m2.4xl服务器。

所有测试实例创建都是使用EC2的ASG(auto-scale group ()创建，创建三个ASG，EC2创建他们并且维护管理，一旦ASG发现一台崩溃，就立即使用备份服务器，而NetFlix的工具是负责这时的Cassandra集群在新服务器上的启动。下面是ASG配置缩图：

[该贴被admin于2011-11-19 10:35修改过]
[该贴被admin于2011-11-19 10:36修改过]

NetFlix自动化工具已经实现了基于S3的备份和文档化，能够进行不当机的Cassandra升级，也能够有效地在Cassandra运行时增加一个集群机器，每个新的服务器节点启动和数据有效切分。如果一个节点当机，将有一个不同的新IP地址节点替代，但是其他一切和原来相同，这个自动化工具为"Priam"。

NetFlix准备在今年晚些时候将Priam开源，他们已经在Github开源了Apache Zookeeper 接口称为Curator的开源项目，也计划释放一个Java客户端库称为Astyanax (都是希腊神话中和Cassandra有关的神).

下图是这次测试线性增长图，几乎没有瓶颈：

[该贴被admin于2011-11-17 11:14修改过]

下一步寻找瓶颈将在每个服务器内部活动状态中寻找，下图：

图中每台服务器写速度和预期相符；Mean Server Lantency是每台服务器在不断扩展中保持低延迟；response time表示客户端大概是11ms响应时间，其中1.2ms是网络延迟剩余的是客户端库加载和线程处理延迟； write latency表示每台Cassandra服务器有小的毫秒分，平均每台服务器都在一毫秒延迟，CPU load对于大型集群有些高，这也许归结于测试随机操作上，也许在网络Gossip连接等方面耗CPU等； Disk writes 是由于日志commit写操作引起和大顺序表SSTable写操作引起的. Disk reads是用于后台对 Cassandra的SSTable进行压缩操作引起的； Network traffic是因为Cassandra内部节点间复制消息。

[该贴被admin于2011-11-17 11:15修改过]

由于使用Amazon云计算平台是通过时间计费的，时间就是金钱。下图：

[该贴被admin于2011-11-17 11:15修改过]

客户端请求是设置一致性 "ONE"级别：意味着每个服务器节点已经确认这个数据，对于写数据后一致性读是使用"LOCAL QUORUM".

在这种情形下，客户端必须等待三个节点中两个确认数据修改，所以写响应时间有所增加，测试发现在AWS的欧洲比美国东部网络延迟要低，也许是规模小或新的硬件，网络因素不是这次测试主要影响因素。

压力测试命令行
java -jar stress.jar -d "144 node ids" -e ONE -n 27000000 -l 3 -i 1 -t 200 -p 7102 -o INSERT -c 10 -r

客户端每行写10列，行Key是随机从27 million ID中选择, 每个列有一个Key和十个字节数据，整个每次写在磁盘大小是400 bytes.

第三方客户端首先和第一批144节点交互，然后30个和第二批144节点. 对于Insert 他们写了三个复制，按照keyspace规范：


Cassandra Keyspace Configuration
Keyspace: Keyspace1:
Replication Strategy: org.apache.cassandra.locator.NetworkTopologyStrategy
Durable Writes: true
Options: [us-east:3]
Column Families:
ColumnFamily: Standard1
Key Validation Class: org.apache.cassandra.db.marshal.BytesType
Default column value validator: org.apache.cassandra.db.marshal.BytesType
Columns sorted by: org.apache.cassandra.db.marshal.BytesType
Row cache size / save period in seconds: 0.0/0
Key cache size / save period in seconds: 200000.0/14400
Memtable thresholds: 1.7671875/1440/128 (millions of ops/minutes/MB)
GC grace seconds: 864000
Compaction min/max thresholds: 4/32
Read repair chance: 0.0
Replicate on write: true

为了解Cassandra的数据流Data Flows, Latency 和持久性 Durability，
专门写了Cassandra 的不同配置. 正常地Cassandra 客户端并不知道哪个节点应该存储他们发送的数据，他们是随机抽取一个节点，发送数据备份给相应的节点(通过行Key的一致性Hash算法获得). 一个节点对于最快的写也需要确认，这对于使用Cassandra替代memcached方案是有用的，这样能够避免因为一台崩溃的memcached服务器导致的cold cache。

但是速度和可用性比一致性更重要，memcached额外的开销是网络传递开销，写之后的立即读将得到的是脏数据，因为它是一种最终一致性，弱一致性。

为了在Cassandra上能够得到写的即时一致性也就是高一致性，netflix使用了quorum write策略. 三个节点中两个必须在客户端得到响应之前确认它的写操作是否可靠durable.

如果一个quorum写之后进行的读也是使用quorum, 读取总是最新修改数据，高一致性。这是因为三个总是有两个重叠，因为没有主节点，其中任何一个节点当机，Cassandra总是可读写。

Cassandra commit日志是每隔10秒flush到磁盘上，这意味在这10秒之前的数据是在内存中，这是分别保存在三个不同数据中心的内存中，所有三个数据中心内存全部丢失的概率相当小，这就有相当好的可靠性durability和高可用性以及低延迟.
每个Cassandra服务器的接受写的延迟只是几毫秒，它是=采取将数据放入队列的方式，然后通过队列commit到磁盘日志文件中。

Cassandra实现的是gossip协议，让每个节点都知道彼此状态, 如果写入的一个节点当机，成员节点会知道它不会返回数据了，这就是"hinted handoff". 当gossip告诉协同者那个节点又恢复了, 它会再次传送刚才丢失的数据。

Netflix当前正在设置部署一个全局Cassandra集群支持英国和爱尔兰的业务扩展，. 在这种情况下需要一种全局数据视野，一种特别的Cassandra系列节点将被配置提供所有写入数据的异步更新备份。

因为没有主复制，如果两个区域之间连接中断各自继续工作，在这种情况下，我们使用一个local quorum 来读写，进行远程数据发送，但是不等待其响应，这样延迟对于远程区域延迟并不明显，这就带来本地区域和远程区域的最终一致性，同时带来了高可用性。

http://www.slideshare.net/adrianco/migrating-netflix-from-oracle-to-global-cassandra

该PPT讲述了Netflix从Oracle迁移到Cassandra，以及从S3+memcached迁移到Cassandra过程.

Cassandra在Twitter的URL抓取中应用：
Twitter's Real-Time URL Fetcher

据称：Cassandra目前最大应用是超过400台300TB的数据。
有关Cassandra的Gossip协议资料：使用Gossip进行当机检测监视和消息系统Using Gossip Protocols For Failure Detection, Monitoring, Messaging And Other Good Things

另外：Netflix资料，美国最大的在线视频服务公司，Netflix高峰时期占据全美下载流量的32.7%:
http://mashable.com/2011/10/27/netflix-takes-up-32-7-of-internet-bandwidth-study/

NetFlix在刚刚结束的QCon 2011大会上的PPT: Netflix in the Global Cloud
[该贴被banq于2011-11-22 10:25修改过]
[该贴被banq于2011-11-22 11:16修改过]