Instagram：从Redis到Cassandra 成本节省1/4

hyperv

<!--StartFragment -->Rick Branson是Instagram基础架构软件工程师，他在接受DataStax联合创始人Matt Pfeil采访时表示：随着数据量的快速增长，Redis已不再是他们的最佳使用对象，他们正在大量使用Cassandra。
下面是Matt Pfeil对Rick Branson的采访，笔者摘取了与Cassandra有关的核心内容进行编译：Matt：Rick，听说你和伙伴们都在使用Cassandra，那能否跟我们分享你们的使用情况呢？Rick：当然可以，我们已使用7、8个月了。最初，我们使用它主要是来存储涉及安全和网站诚信等方面的审计信息。这样，我们就会涉及到拦截垃圾邮件、滥用用户等其他相关东西。最初，这些任务都是在Redis中进行，但随着数据量快速增长，仅把它保存在内存中已不是高效之举，这是典型的高写入、低读取。而面对这种问题情景，Cassandra则是最拿手的，它可以毫不费劲地解决这方面问题。我们一开始设置3个节点群，但随着用户量的增长，节点群也随之增长到了12个，这基本上就是我们后端主应用程序。最近，我们决定移植另外一个项目，显然，该项目要比先前的要困难很多。团队里的每个人都开始投入到Cassandra上，大家花时间阅读文档、学习如何更高效地运作Cassandra。我们使用Cassandra来调用“收件箱（inboxes）”或应用中的新闻推送。基本上，这都是与用户的所有活动相绑定的，如果有人喜欢你的照片，赞或者评论照片，那么你的Instagram好友会看到相应的信息。我们之所以决定把数据迁到Cassandra上，主要是因为之前在Redis上遇到了内存限制。Cassandra在可靠性和可用性上，都有着非常好的体验。我们只用了几天的功夫就成功地把项目迁移过来了。关于集群上的一些细节：12个节点群的EC2 hi1.4xlarge 实例；在该集群上存储1.2TB数据；在高峰期，以20000次/秒的速度写到特定的集群、15000次/秒的速度读取信息。从这次实践中我们也学到了很多，并且会把学到的运用到其它实现上。Matt：听起来真令人兴奋。刚刚你和我们分享了用户项目上一些非常有趣的事情，正如你提到的，从Redis迁移到Cassandra，是一个基于内存的发行。那这样做的背后动机是什么？Rick：如上面提到的后端主应用程序，我们先移开一个Redis主/从复制设置，但成本太高昂了。我们从内存中取出，遇到大实例，就放在硬盘上，当不经常读取的时候，它会运行的很好。而使用Cassandra可以削减近1/4的成本。不仅如此，它还可以很好地释放我们扔在集群上的数据，由于它更具扩展性，还会根据需要自动添加节点。尤其是当从一个unsharded设置转到sharded设置时，Cassandra可以很好地解决，而且在进行shard数据时，没有任何痛苦。在另一个我们称之为“inbox”的用例中，提要已被分片。它拥有32个节点群集，其中主节点16个、故障转移副本节点16个。我们注意到，我们耗尽了所有机器的内存，而CPU资源并没有完全占用。不难发现即使在内存耗尽时，Redis对CPU的使用仍然相当高效。在这些用例上，使用Cassandra操作集群不仅成本廉价，而且更易操作。持久性则是Redis并不高效的主要原因，关于这一点，在Cassandra Summit 2013峰会上我会继续介绍。关于CassandraApache Cassandra是一套开源分布式NoSQL数据库系统。它最初由Facebook开发，用于储存收件箱等简单格式数据，集Google BigTable数据模型与Amazon Dynamo的完全分布式的架构于一身。Facebook于2008开源了Cassandra。此后，由于Cassandra良好的可扩展性，被Digg、Twitter等知名Web 2.0网站所采纳，成为了一种流行的分布式结构化数据存储方案。