为什么Twitter不使用Cassandra存储Tweets（译）
当前讨论的中心是Cassandra作为NoSQL的主要产品已经被剥去了华丽的衣裳。首先是Twitter已经放弃了Cassandra，并且据说作为Cassandra诞生的地方，Facebook也已经放弃了Cassandra。NoSQL已经失败了这种论调已经充斥在了各大社区上，Cassandra已经失败了么？发展遇到阻碍是有的，但是没有失败。
（注：本文包含一个NSFW的流程图，有些人对坏话非常敏感，如果你是这样的人，请不要继续读下去了危险！这里没有裸体图，也没有其他任何东西，只有一些言辞激烈的言语。但是这些都是我一直以来最感兴趣的流程图，所以他值得！）
Twitter真的放弃Cassandra了么？根据Twitter流出的这个帖子：Cassandra at Twitter Today解释，他们使用Cassandra用于存储地理信息和分析。但是，Twitter将不会使用Cassandra存储Tweets。为什么？Twitter解释说：“这是一次战略上的变化。我们将继续维护我们原本基于Mysql的存储。我们相信，现在还没有到大规模迁移数据到一个新技术的时候。”
Twitter现在忙于各种其他的紧急事件，而没有时间去把他们原本存储在Mysql的数据迁移到Cassandra。
现在是最佳的时机向大家分享一个流程图的时候，这个流程图是我若干年前得到的。这也许很像Twitter做出决定之前的思考过程。
Flow Chart for Project Decision Making
我每次读这个都会笑。这是事实，每个公司都会遇到如何放置资源的决定。你需要构建，购买，重新构建，扩展，挂起你的应用。一个工程师可能会觉得重新开始试正确的。但是最好的商业决定可能完全不同。
Joel Spolsky曾经发表过声明说，你永远都不要从头开始重写你的代码。还记得Netscape么？还有那么多曾经在互联网上，但是已经消失了的公司。因为他们做了这个最关键的抉择性错误，他们从头开始重写代码。
Twitter不想重蹈覆辙。这就意味着Cassandra和NoSQL的失败么？不！我认为这只是一个高明的项目计划。这实际上已经为不同的情况提供了多种平台。
Twitter已经运行的足够好了么？Brad McCarty在Twitter implements more features; ignores its broken platform中举出了很好的例子：Twitter在迁移之前应该首先架设好自己的基础设备。但是现在的问题是，Twitter有设备，但是没有核心的Tweets的引擎。直到现在，Twitter的运行状况还非常良好。因此，根据这种情况，保持Tweets的引擎继续工作，尽管他非常丑陋，然后开始把一些新的琐碎的功能迁移上去，是不是更合理呢？
这些都是无法避免的。Cassandra曾经一直都活在Facebook和早期尝试者的呵护之下。直到最近Cassandra离开家进入到这个复杂的世界，这里的用户有着各种各样非常广泛的需求。这将促使Cassandra的成熟，Cassandra需要设计需要增加的新功能，需要为已经存在的功能重新建立架构，需要告诉人们Cassandra究竟擅长做什么。这些直到现在才成为了问题。并且，对于开发者来说，选择切换到一个新的技术平台上来则意味着，他们需要学习，再学习，然后克服种种障碍。这个过程是困难的。所以我们需要考虑到关于Cassandra的问题和周围的一些产品。这就是切换到新技术上的问题，我们就像是这个空间里的一个小白鼠。
Facebook真的放弃Cassandra了么？没有！Facebook仍然有150台Cassandra云节点用于搜索，这个支撑着5亿的用户，150TB的数据，而且这些数字每天都在增长。现在，看一看Cassandra普及在其他项目或者小组的速度会是非常有趣的。什么时候会出现一门实现了Cassandra的技术？他是否会继续发展？我们都不知道，但是我们可以知道的是Facebook在未来仍然将继续使用Cassandra。
