程式設計 /z/programming
4
Benchmarking larger-than-memory workloads : DataStax (www.datastax.com)
4 則討論 haocheng 張貼於

kaif 積分 3 編輯於

一些comment：

  1. 結果顯示在有上億筆資料的時候，Cassandra在效能和擴展性上，完全領先其他NoSQL呀。

  2. 可能很多設計的trade off影響這幾個NoSQL最後的效能表現，其中一個可能是CAP的trade off：cassandra和couchbase放棄consistency，在sacle/效能上結果就表現的比較好；mongoDB和Hbase是CP system，為了consistency可能要犧牲效能。

  3. 在DB技術選擇上， 一般應用mysql記憶體給多一點就很好用啦， 大一點的場合或許一組mongoDB就能在各方面取得不錯的平衡， 但在超大scale的場合，可能要hybrid cassandra+rdbms+redis。

回應

IngramChen 積分 4

選 Cassandra 其實也沒有放棄 consistency，它是屬於 tunnable consistency。如果讀寫都設 quorum，3個 replica 以上的話，平時資料都是 consistent 的，即使有一台掛了。只有 3 台中壞了 2 台以上才會出大麻煩 (這時就看你要犧牲誰啦，C、A 選一個)。要三台一次掛二台機率很低，出這種問題通常是人為設錯了什麼。

選 Cassandra 放棄最多的其實是 Ad hoc query 和 Atomic。沒有 Ad hoc query 很苦啊，開發速度掉 3 倍 以上。平常的服務一個 SQL 能搞定的，用 Cassandra 可能要寫半天到一天才能寫完，暈倒。至於 Atomic 就看應用服務能容忍到什麼程度了，大部份的服務要求沒這麼高，我覺得影響不大。

所以我個人的結論是，Cassandra 不能當做服務的 primary database，而是當遇到 rdbms 處理不來時，才會將那一塊換成用 Cassandra 來處理。

回應

kaif 積分 2

agree.

這篇沒提到cassandra的consistency level，不過我猜會是妳講得quorum(default)。

我原來講得consistency想表達的是cassandra在quorum以下的level的狀況，也就是寫入後可能讀到舊的資料。當cassandra在quorum level時，看起來舊可以視為strong consistency，剩下就是durability的問題了（也就是妳說得，是異常狀況才會出問題）。

回應

haocheng 積分 0

CS 果然很快！

回應