美国著名社交网站Twitter近日在其官方工程技术博客上发布两条重量级消息：Twitter将不再使用Cassandra数据库系统储存数据，Cassandra将被改做用于Twitter实时分析产品的技术研发。
此前业界一直相信Twitter将在未来发展战略中大规模的使用分析学的原理，但此前上述消息仅仅来源于一些言辞模糊的官方声明。但这一次 Twitter的动作明显要实在得多，美国著名科技博客网站ReadWriteWeb的马歇尔·柯克帕特里克(Marshall Kirkpatrick)根据现有的证据预测Twitter的实时分析产品将于近几日之内面世，而Twitter的工程师瑞恩·金(Ryan King)在博客中直接说到：“公司的分析团队、运营团队以及基础建设团队正在使用Cassandra系统合作研发一款供Twitter后台以及客户共同使用的大规模实时数据分析产品。”
Cassandra是一款开源Apache项目，该项目最早由Facebook于2008年进行开源。瑞恩·金表示未来Cassandra仍将做为 Twitter众多新产和服务的核心架构，包括地理定位数据库、对话题趋势的数据挖掘以及上文提到的实时分析产品。他说：“我们现在每天都在利用 Cassandra来处理相关问题，它将注定陪伴我们很长时间，未来我们对于它的使用只会不断增加。”
以下是来自Tim[后端技术]的分析。
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。
{{item.content}}