关注@rbranson
————里克•布兰森 Instagram基础设施软件工程师 
Instagram是一个免费的照片分享应用，可拍照、使用过滤器并分享到社交网络上，如Facebook，Twitter等等。它令超过2亿的用户捕获和定制他们的照片和视频并与世界分享。
用CASSANDRA削减成本最初我们的部署是用于存储与安全相关的审计信息和维护网站完整性。要分解这一概念，意味着要打击垃圾邮件，发现滥用用户，还有其他类似的东西。这正是Cassandra的优势。 最 初,这些功能是在Redis实施的；数据规模增长过快，保持在内存中将影响效率。写入率真的非常高而读取率非常低，而在此问题上Cassandra确实大 放异彩，所以我们无需过多考虑便在相关方面转用Cassandra。我们开始使用一个3节点的集群，而此用例已发展成一个12节点集群。这是我们的主应用 程序后端的主要发展方向。
里克•布兰森 Instagram基础设施软件工程师 欺诈检测，新闻推送和收件箱对上面提到的第一个后端用例，我们撤掉了Redis的主/从复制设 置，就是因为太昂贵了。我们从把所有东西都放在内存因而产生非常大的实例，到把所有东西都放在磁盘里；当你真的不需要经常读取，放在磁盘完全不影响工作。 Cassandra的实施把我们的成本降到低至之前所支付的约四分之一。不仅如此，它还让我们自由到只要把数据扔上集群就可以了，因为它的可扩展性更强， 我们可以随时根据需要添加节点。当你从非分片安装变成分片安装，这可能会比较痛苦；但这点在Cassandra基本上是免费的，你不必经历分片数据的痛苦 过程。 最近，我们决定迁移另一个更重要的用例。我们花时间让团队中的每个人都熟悉Cassandra，阅读文档，学习如何有效地操作它。我 们选择用Cassandra作为我们所说的“收件箱”或我们的应用程序中的新闻订阅部分。基本上，这是与特定的用户帐户相关联的所有活动的推送，你可以看 到人们是否喜欢你的照片、是否关注你，你的朋友是否加入了Instagram，是否收到评论，等等。我们之所以决定转向Cassandra，是因为此前在 Redis我们遭遇到同样的内存限制问题。 对于“收件箱”用例，推送内容已经分片；它是一个32节点集群带有16个主盘和16个故障转移副 盘，当然，我们必须检查所有的共享内容。我们发现这些机器上的空间不足，但它们却没有消耗大量的CPU（Redis的CPU使用是非常高效的)，然而很明 显当你耗尽内存…你就耗尽内存了。 最终，对这个用例Cassandra集群更具成本效应也很容易操作，无需内存级别性能。耐用性也是Regis无法高效提供的一个重要因素。我在2013年Cassandra峰会的演讲上有提及这一点。 在INSTAGRAM部署我 们对Cassandra的可靠性和可用性有非常好的体验。工作量大不相同：我们在SSD上运行Cassandra1.2版本，还能得到带很多赠品的最新版 本，包括Vnodes, Leveled Compaction等等。这是一个非常成功的项目，我们只花了几天时间就把一切都转换了。 我们 的集群的一些细节：这是一个12节点集群的EC2 hi1.4xlarge实例；我们在这个集群存储了约1.2 TB的数据。在高峰时期，我们向此集群每秒写入约20000次每秒读取约15000次。我们对Cassandra能够担此重任留下非常深刻的印象。我们也 减少了占用空间，所以这对我们来说是一个很好的体验。我们从第一次实施学到了很多，并且能够把这些知识应用到最近的实施中去。现在每当有人使用 Instagram，他们就是在访问这个12节点的Cassandra集群来读取数据，这真是非常让人兴奋。 深入研究文档我 建议深入Cassandra系统并阅读所有文档，尤其是在DataStax网站上的东西。我发现文档最好的地方是它有很多额外的内部信息，知道这些东西真 的很重要。无论你使用哪种数据库或数据存储，你真的需要深入学习他们的文档从而以它正确的方式来使用它。人们往往不做功课就过快地或错误地采取某种解决方 案，从而陷入非常被动的局面。具体来说，数据存储，它真的非常有必要成为你最稳定可靠的东西。 大家可以随时在IRC频道找到我。 原文： Facebook’s Instagram: Making the Switch to Cassandra from Redis, a 75% ‘Insta’ Savings |
