Twitter停用Cassandra緣由分析

    Twitter在其7.9一篇官方技術博客Cassandra at Twitter Today提到暫停使用Cassandra來代替MySQL存儲feed的計劃，這是Twitter一個重要的架構策略 調整，由於以前Twitter一直是業界Cassandra方向的領頭羊。

For now, we’re not working on using Cassandra as a store for Tweets. This is a change in strategy. Instead we’re going to continue to maintain our existing Mysql-based storage. We believe that this isn’t the time to make large scale migration to a new technology. We will focus our Cassandra work on new projects that we wouldn’t be able to ship without a large-scale data store.

Twitter爲何要停用Cassandra

咱們來分析一下Twitter中止使用Cassandra的緣由
1. Cassandra仍然缺乏大併發海量數據訪問的案例及經驗，Cassandra來源自Facebook，可是在Facebook內部Cassandra 目前只用在inbox search產品上，容量大約有100-200T。且Inbox Search在Facebook的基礎架構中也並不是核心應用。而且還傳出很多rumors說facebook已經放棄Cassandra。

2. 新產品須要必定穩按期，Cassandra代碼或許還存在很多問題，可是Twitter若是投入大量的精力來改進Cassandra和比較優化MySQL 的投入來看有點得不償失。在QCon Beijing上@nk也提到 Cassandra在Twitter的內部測試中曾經暴露出很多嚴重的問題。

Twitter爲何以前選用Cassandra

此問題曾經在QCon Beijing 2010作過介紹，在去年的第一期廣州技術沙龍也有過交流，相似Twitter這樣的網站使用Cassandra的主要緣由有
1. 數據增加規模須要不斷增長新服務器，傳統的切分方案在面臨增刪硬件時候須要手工維護，當數據規模速度增快，業務又不運行停機維護，手工維護的成本增長形成 系統運維不堪重負。
2. 不能簡單增長服務器解決請求量增加的問題，須要數據架構師精細的規劃。
3. 每個新的特性都須要重複評估數據拆分及訪問優化的問題，架構師須要投入大量精力review幾乎相同的業務場景。

Twitter的調整對於MySQL業界來講或許是一大利好，MySQL雖然受近期Oracle收購陰影的影響，可是對於目前大多數擁有海量數據訪 問的網站依然是他們第一選擇。MySQL簡單，可靠，安全，配套工具完善，運維成熟。業界碰到的大部分可擴展性方面的問題在MySQL中其實都有清晰明確 的解決方法。雖然重複sharding的問題很煩，增刪機器相關的運維工做也很繁瑣，可是這些工做量仍是在能夠接受的範圍內。

究竟Twitter此次策略改變是NoSQL運動的一次挫折仍是前進中的一段小插曲？咱們拭目以待。目前另一大Web 2.0巨頭Digg仍然在使用Cassandra。