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。

　　

[MySQL] Twitter停用Cassandra原因分析

相关帖子

【FAQ】接入HMS Core推送服务，服务端下发消息常见错误码原因分析及解决方法

爱学啊的博客-人生苦短，只做好课！

中兴加速新支点国产操作系统生态构建，助力信创产业

软件调优方法有哪些？看看飞腾技术专家怎么说 | 龙蜥技术

iOS中 Tagged Pointer 技术

移动端人脸风格化技术的应用

Java NIO全面详解(看这篇就够了)

Louvain算法在反作弊上的应用

你认为开源的意义是什么？一起来看看龙蜥的故事

连路由器连上无法上网-(连上路由器但无法上网)

上山打老虎 LV4