发帖    主题    评论    推荐    标签    作者    订阅    查搜    注册   登陆   关注
 
面向对象 设计模式 领域驱动设计 企业架构 框架 开发教程 微服务 大数据 扩展性 并发编程 事件驱动 分布式 CQRS
1 2 下一页 Go 2

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

              
2011-11-17 10:38
赞助商链接

测试云产品的工具也需要云,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修改过]


19
2011-11-17 10:53

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

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

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


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


2011-11-17 11:05

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


图中每台服务器写速度和预期相符;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修改过]


2011-11-17 11:09

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


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


2011-11-17 11:28

客户端请求是设置一致性 "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


2Go 1 2 下一页

赞助商链接

赞助商链接

返回顶部

移动版 关于本站 使用帮助 联系管理员 最佳分辨率1366x768
OpenSource JIVEJDON Powered by JdonFramework Code © 2002-20 jdon.com