國內哪些互聯網公司使用了 Cassandra 資料庫？

01-19

國內生產環境使用Cassandra比較多的大公司有360，從公開的資料看，應該有至少1500台伺服器的集群。360選用cassandra的原因如下：團隊人員少，需求緊，選擇開源項目；無單點，無中心，適合在線業務；代碼易懂，團隊成員有代碼基礎；社區比較活躍。

另外一些中小型公司和創業公司也有在使用。

這裡要解釋幾個對cassandra的誤解：

1、Facebook棄用？

Facebook當初想用cassandra實現其消息系統，但後來發現不合適，原因不是cassandra不靠譜，而是Cassandra的最終一致性模型不適合Message System，HBase具有更簡單的一致性模型。Cassandra強調AP ，Hbase強調CP。目前Facebook的inbox search系統在使用，8億用戶，200T數據；其移動應用開發平台也使用cassandra。

2、Twitter棄用？

本質是mysql和nosql之爭。cassandra能進入twitter的視野，恰恰說明cassandra是nosql的代表性產品之一。為什麼twitter在tweets系統中不使用cassandra？"這是一次戰略上的變化。我們將繼續維護我們原本基於Mysql的存儲。我們相信，現在還沒有到大規模遷移數據到一個新技術的時候。」目前twitter也有使用cassandra——Using Cassandra in production for geolocation and analytics。

3、Cassandra不火？

國內對mongodb和hbase推崇備至，究其原因是因為mongodb這個公司進入了中國市場並建立了中文組，而hbase在阿里的大範圍使用和推廣下培養了一大批用戶和公開材料。Cassandra最近兩年在大數據公司Datastax的大力培育下獲得長足發展，功能和性能均大幅提升，Datastax的估值也達數億美元。從apache cassandra首頁來看，大概有超過1500個公司在使用cassandra。其中除了facebook和twitter外還一些有代表性的公司列舉如下：

Instagram：inbox、newsfeed、 audit、fraud detection，12 EC2 node，1.2T，2w+ wps，1.5w+ rps；

eBay：200+TB，400+M寫，100+M讀，應用場景：商品詳情頁上的Social Signals，如Like,Want,Own,Favorites等；用戶和商品的hunch taste graph；時間序列如移動通知，反作弊，soa，監控，日誌服務等；

Netflix：包含288+96+60個實例的大規模集群，每秒110萬的寫操作，3個AWS EC2 美國東部region的zone自動複製副本，總計330萬寫操作/秒；

Apple：75000+ nodes， 10s of PBs，Millions ops/s, largest cluster 1000+ nodes。

從技術實現上來講，cassandra同時具備AWS Dynamo和Google Bigtable的設計理念，同時引入了P2P技術，具備大規模可分區行存儲能力，強調AP，實現了最終一致性，具備多數據中心複製支持，具備市場上最具有競爭力的可擴展性，無中心節點，一致性和時延可調，無單點故障，每個節點只有一個進程等等大數據存儲管理的先進特點，並支持spark、storm、hadoop的集成。但同時，Cassandra實現複雜性高，沒有相應的中文社區，文檔太少，國內應用和實踐太少，Datastax也未進入中國市場，因此在中國的推廣會比較困難。

值得一提的是，Cassandra的LSM結構特別適合SSD設備，有效抑制了SSD的寫入放大，有力的保證了其超強大的寫性能，這點和LevelDB的設計基本一樣；同時對CPU的使用也能發揮到極致，對於多核超線程設備和NUMA架構下能發揮更大的優勢；另外，Cassandra的row cache、key cache、LeveledCompactionStrategy壓緊策略、讀時碎片化結果重新寫入機制等改善措施也極大了提升了其讀性能。這些特點都非常符合現代伺服器的發展趨勢。筆者曾經在騰訊的TS8-2型伺服器(CPU物理2個，邏輯24個，6核，支持超線程Intel(R) Xeon(R) CPU E5-2620 0 @ 2.00GHz/32G/300G*12 IntelSSD)上搭建了18台伺服器的集群為知識社區類產品提供後端存儲服務，性能上是非常有競爭力的，而且Cassandra非常適合做在線架構和構建在線存儲服務，雖然也支持集成hadoop，但要求在一個在線系統上大規模跑離線數據不是一個明智的做法，要看具體的應用場景。而BAT規模的就那幾家，大部分的中小型業務和創業項目，夠用了。

相信只要Datastax公司能保持住市場競爭優勢，在大數據時代，Cassandra必然還是有一席之地的。

最後，想說一點的是：技術人永遠保持自己基於事實的獨立判斷。不要人云亦云，多看上下文，多親自調查保持發言權；世事也絕不是非黑即白，看場景，分時勢，適合的即是最好。

##### 2015年9月更新

在2015年9月22-24日的Cassandra 2015峰會上，KVM作者宣布了C++版本的Cassandra——ScyllaDB，完全兼容Apache Cassandra，單節點吞吐量性能是Java版本的10倍，號稱是最快的列存儲NoSQL。不得不說，美軍鑽得很深，把現代伺服器的優勢發揮得淋漓盡致。

At Cassandra Summit opening today, Avi Kivity and Dor Laor (who had previously written KVM and OSv) announced ScyllaDB — an open-source C++ rewrite of Cassandra, the popular NoSQL database. ScyllaDB claims to achieve a whopping 10 times more throughput per node than the original Java code, with sub-millisecond 99%ile latency. They even measured 1 million transactions per second on a single node. The performance of the new code is attributed to writing it in Seastar — a C++ framework for writing complex asynchronous applications with optimal performance on modern hardware.

原始鏈接找不到了，但在digg的事之前，cassandra是從某次涉及java的gc，引起多個節點失效的事件開始，繼而整個集群緩慢，從那以後詬病逐漸多了起來，後來digg就出事了

國內對cassandra等NOSQL資料庫的使用還是比較謹慎，據我所知比較大的公司有淘寶在用，百度他們有自己的k－v資料庫。

我們公司在用，但不是我決策的，cassandra一些近來的benchmark確實不錯，但有一些問題，我們也在尋找一些提高大區間讀性能的修改方案。

1. 讀的性能太慢

無中心的設計，造成讀數據時通過逆熵做計算，性能損耗很大，甚至會嚴重影響伺服器運作。

2. 數據同步太慢（最終一致性延遲可能非常大）

由於無中心設計，要靠各節點傳遞信息。相互發通知告知狀態，如果副本集有多份，其中又出現節點有宕機的情況，那麼做到數據的一致性，延遲可能非常大，效率也很低的。

3. 用插入和更新代替查詢，缺乏靈活性，所有查詢都要求提前定義好。

與大多數資料庫為讀優化不同，Cassandra的寫性能理論上是高於讀性能的，因此非常適合流式的數據存儲，尤其是寫負載高於讀負載的。與HBase比起來，它的隨機訪問性能要高很多，但不是很擅長區間掃描，因此可以作為HBase的即時查詢緩存，由HBase進行批量的大數據處理，由Cassandra提供隨機查詢的介面

4. 不支持直接接入hadoop，不能實現MapReduce。

現在大數據的代名詞就是hadoop，做為海量數據的框架不支持hadoop及MapReduce，就將被取代。除非Cassandra能夠給出其他的定位，或者海量數據解決方案。DataStax公司，正在用Cassandra重構HDFS的文件系統，不知道是否可以成功。

1. Cassandra最好不要用了，用於異構系統集成還可以，相當於分散式的任務分發。

2. 對於不是特別大型的應用，用memcached配合關係資料庫就很好了。

3. 特別大型的應用，可以考慮redis，mongodb，tt類型的支持「索引」的nosql系統，目前mongodb看似不錯，有了如同mysql的複製機制，不過對於一致性、延遲等問題的解決上，都得花點功夫。

4. 我們自己測試、實踐之後，關鍵業務邏輯還是用了mysql+memcached來互補，緩存熱點數據，用了mongodb做日誌，行為分析等。而沒有一味的使用nosql。

5. 據說：redis還是很靠譜的，新浪微博在用。

補充一下：華為有用過cassandra，但是後來放棄了，mongodb他們也廢用了，選擇了redis，很大一部分原因是運維、部署的障礙，無法進入他們的標準運維體系。

本人目前在360，做對象存儲系統，底層就是cassandra集群，不管任何系統都是需要活躍的社區，cassandra 當前在國內最大的問題就是社區不活躍，即使國外看看官方文檔也就知道很少有人維護，目前我們遇到的最大問題就是海量數據的compaction問題，這類問題，不管是cassandra還是Hbase 都是有坑，一旦數據量過大，就會發現做不動，我們也在嘗試建立多層次的存儲，沒有任何一勞永逸的方式。再者就是考慮到國內的網路環境，除非有像BAT這種有自建的機房，可能適合多數據中心架構，大部分自己搭建，集群規模都不應過大，而應百台規模，多機房多集群部署，再做層調度。cassandra確實適合寫，相比於ceph之類優勢很大。很多同學說一致性的問題，與設置的cassandra consistent level 有關，而且為保證數據最終的一致性, 提供HITS handoff ， readrepair 等機制。至於說讀效率的問題，實在不敢苟同有些同學的觀點，特別是使用新版cassandra ，必須要考慮新model 的設計方式，而前期版本cassandra , 也是c偏kv的列存儲，和Hbase採用類似的存儲引擎怎麼可能在讀上有差別，再者hbase還存在中心節點問題呢。如果你要做離線的批處理另論，在線存儲方便優勢絕對很大。但是歸根結底還是不活躍的社區，新版的cassandra代碼量又更大，資料卻更少，運維遭遇的新問題，社區幫助卻更少。再者將cassandra 與redis /memcached做對比，請先弄清楚他們使用場景差別。任何東西，都是不斷填坑的過程，而且有些問題可能還是只在數據量大到一定級別才會暴露出，不管是cassandra, 還是hbase ,甚至其它，這時就是考慮團隊的運維能力，社區的支持能力，規劃能力，然後重新考慮現有存儲設計。

非常過時的答案，大家不要再頂了

請查看其他相關問題獲取最新信息

原答案：

==========================================

今天就這個問題和朋友交流了下，補充一些國外的信息吧：

Cassandra 最早是Facebook的內部產品，後被基本認定為失敗的產品線。當初開發這個東西的人基本上已經從facebook離開（在他們將Cassandra開源後）。其他使用該產品的公司最終也都放棄了該平台（例如，Digg）

因此，如果你的公司在考慮採用 Cassandra，希望你們三思。

在去年的Cassandra Summit上有國內的人上去介紹cassandra案例：

三一重工

國家氣象局

截個圖為證

沃爾瑪在使用Cassandra，至少是ISD分支的幾個部門在用，大約三年前從DB2移到了Cassandra。

上海熱巢，做媒體大數據和機器學習的。目前需要一個精通 Spark、Cassandra 的工程師，需要2 年以上相關經驗，了解 NoSQL 資料庫和怎麼設計大數據系統的結果

從360公開的資料看，360內部用的還是蠻多的

這個話題下好多答案都已經太老了。！

我們公司，1w+物理機吧，cassandra這個東西只是合適做小規模集群。

nosql的資料庫基本就看Hbase了，用mongoDB和redis最終還是要遷移到這個上去

cassandra還是比較適合寫多於讀的需求

不過這種確實是比較少