分類: 為什么 常識詞典 編輯 : 常識 發(fā)布 : 03-29

閱讀 :287

為什么 Cassandra 的寫速度比 My-L 快？13 個答案

答案 1：

Cassandra 的寫速度比 My-L 快的兩大根本原因1、cassandra沒有sql解析層，這是個大塊2、cassandra采用memstable+sstable的模型，最大化的提高數(shù)據(jù)的寫入性能，磁盤操作只有順序寫。nosql產品的數(shù)據(jù)寫入buffer非常大， nosql用數(shù)據(jù)安全換取高性能， 其實沒有絕對的優(yōu)勢，看你的產品具體需求

答案 2：

一般意義上的說哪個快沒有太大意義，如scalarize 所說，限定條件很多，cassandra 還有一個數(shù)據(jù)安全策略，比如共有N個數(shù)據(jù)節(jié)點，指定在寫入操作保證成功的節(jié)點數(shù)量為 任一/一半以上/全部節(jié)點，這個策略涉及網絡I/O，對寫入速度影響較大。

答案 3：

沒有可比性，不同的產品側重點不同。Cassandra沒有復雜的邏輯結構，寫入比較簡單，My-L不同，它是真正RDBMS，邏輯結構復雜，如果把My-L改成這種k/v方式的來處理，速度不見得慢。

答案 4：

其實這個問題就是為什么No-L產品在有些應用上由于RDBMS產品，由于RDBMS產品處理每個請求的時候，要做解釋、優(yōu)化、事務、鎖管理等等一系列操作，損失了很多性能。但是往往一些對性能要求非常高的應用，比如微博、Feed等，是不需要這些操作的，No-L產品就是由于去掉了這些操作性能上有了很大的提高

答案 5：

這個命題要成立，還需要許多限定條件，比如數(shù)據(jù)設計、數(shù)據(jù)量、存儲介質和架構，等等。即使雙方面臨相同的條件，結論也并不一定都一樣，因為雙方的設計場景和目標不同。一般簡單測試都會得出 cassandra 快的結論，最大的原因是 cassandra 不是關系型數(shù)據(jù)庫。

答案 6：

前幾個月perconaserver提供nosql接口了.-andlersocket據(jù)說不錯。

答案 7：

單機的cassandra不一定比mysql快吧。這個問題還是要看具體的應用場景

答案 8：

如果交易系統(tǒng)使用，會死人的。。。

答案 9：

不能這么比較的，架構都不一樣，實現(xiàn)的功能也不完全一樣，換句說：是不同類的東西，解決的問題有重疊部門。No-L應用場景及Cassandra架構分析，鏈接：mysqlops/2011...

答案 10：

不知道是否正確，cassandra 應該是google bigtable的facebook的一種解決方案，他是基于列的。它寫到的是內存中而不是永久磁盤，所以你感覺會快，當他的內存滿的時候就會flus-到磁盤。

答案 11：

wiki.apac-e.org/cassandr... 描述了cassandra的寫入機制。大概來說：Cassabdra先寫入commit log文件，這個動作只是append而沒有隨機尋址，所以很快。默認設置下cassandra每CommitLogSyncPeriodInMS將寫入的內容fsync到硬盤，所以如果機器掛了你就可能損失這段時間內寫入的數(shù)據(jù)。之后Cassandra才把新內容寫入到內存里的memstable，如果內存不夠了就溢出到硬盤上的sstable。在客戶端最開始請求寫入cassandra時，cassandra在證數(shù)據(jù)寫到commit log硬盤上之前就讓客戶端返回了，所以可能在某些情況下顯得很快吧。

答案 12：

說Cassandra 的寫速度比 My-L快,只是一種想當然的誤解...磁盤技術發(fā)展幾十年了,一直是計算機系統(tǒng)的瓶頸. nosql有什么法寶嗎?能比傳統(tǒng)數(shù)據(jù)庫寫的快嗎?顯然沒有,除非優(yōu)化寫入的方式,合并寫的操作,這顯然是另外的范疇了.我們考慮的是伸縮性,不要片面夸大了它的寫入性能.

答案 13：

說沒有mysql解析層的那個說法。。。在cassandra guide book這本書中說cassandra馬上要推出自己的CQL語言。

下一篇:自從-推出Q+，以及附加插件太多，導致軟件本身越來越大，你如何看待？ 下一篇 【方向鍵 ( → )下一篇】

上一篇:在知乎上除了邀請回答，還應該有“邀請關注”嗎？ 上一篇 【方向鍵 ( ← )上一篇】