• Feeds

  • 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。

    如想及时阅读Tim Yang的文章,可通过页面右上方扫码订阅最新更新。

    « | »

    Comments

    12 Comments

    1. 咩 多谢分享……

    2. 嗯嗯嗯,潮起潮落,什么时候可以见到 Pg 的跳出?

    3. @zq: Pg要是有原生的MASTER-SLAVE的方案的话应该会有很多人用的,但是现在都是第三方的,性能跟单独跑PG差的很远。

    4. […] 以下是来自Tim[后端技术]的分析。 […]

    5. zheng

      Twitter DB数量很巨大的情况下,不知道采取什么方式进行DB的统一接入了,应用层的DB proxy、还是系统层的类lvs屏蔽呢,貌似增减机器或db故障的概率不低呀

    6. Leng

      有没有对 停用原因 的更深入分析呢~?

    7. chenwf

      我们近期正在考虑采用NoSQL还是水平切割,看到twitter放弃Cassandra,很纠结啊,谁能探听twitter的原因呢?
      不过看到这篇文章,我决定不采用NoSQL了。

    8. […] 以下是来自Tim[后端技术]的分析。 […]

    9. Cassandra最大的毛病就在数据压缩时导致系统性能极端低下,而且数据压缩是Cassandra必须的!

    10. 呃,回复一个,不幸的是,Digg因为Cassandra的技术问题,主推人走人,贱卖50万美元。保守有时候就是成熟。

    11. 这么多年过去了。。。cassandra应该也变成熟多了。INS倒是迁移了过去

    Leave a Comment

    Your email address will not be published. Required fields are marked *