日志正文
|
||
1. 关于cassandra的读性能分析的一篇文章: Mike Perham continues his series now explaining: “reads and […] why they are slow”. So what happens with a Cassandra read?
Mark mentions a couple of corner cases related to this behavior that is more complicated.
Mike and Jonathan provide a very detailed explanation of the read performance: Mike: To scan the SSTable, Cassandra uses a row-level column index and bloom filter to find the necessary blocks on disk, deserializes them and determines the actual data to return. There’s a lot of disk IO here which ultimately makes the read latency higher than a similar DBMS. Jonathan: The reason uncached reads are slower in Cassandra is not because the SSTable is inherently io-intensive (it’s actually better than b-tree based storage on a 1:1 basis) but because in the average case you’ll have to merge row fragments from 2-4 SSTables to complete the request, since SSTables are not update-in-place. It is also important to note that Cassandra employs row caching that addresses reads latency.
2. 关于cassandra的写性能分析的一篇文章: An interesting explanation of how Cassandra write ops are happening:
There are also a couple of asynchronous operations:
参考文档: http://nosql.mypopescu.com/post/474623402/cassandra-reads-performance-explained http://nosql.mypopescu.com/post/454521259/cassandra-write-operation-performance-explained
最后修改于 2010-03-31 23:09
阅读(?)评论(0)
上一篇: 网上流传的房地产崩盘时间表
下一篇:该日志被锁定
|
||
评论 想第一时间抢沙发么?