技术开发 频道

Instagram:从Redis到Cassandra节省成本

        【IT168 资讯】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峰会上我会继续介绍。

  关于Cassandra

  Apache Cassandra是一套开源分布式NoSQL数据库系统。它最初由Facebook开发,用于储存收件箱等简单格式数据,集Google BigTable数据模型与Amazon Dynamo的完全分布式的架构于一身。Facebook于2008开源了Cassandra。此后,由于Cassandra良好的可扩展性,被Digg、Twitter等知名Web 2.0网站所采纳,成为了一种流行的分布式结构化数据存储方案。(

0
相关文章