不久前TheServerSide与Samantha Kosko有过一段有趣的对话。她是10gen公司该领域的营销人员之一，也是MongoDB的幕后工作者，因此对于数据持久化世界，她不是完全公正的，但至少可以说她关于在Craigslist网站发生的大数据问题的见解是很有趣的。

　　Craigslist网站每天都处理大量的贴子，但是当负载越来越大时，他们每天的传入流量已经不能满足处理一个关系型容器了。然而，管理他们的贴子归档是另一个故事。“从历史上看，Craigslist网站是一个坚实的MySQL仓库，但是，当他们逐渐成长巨大，他们的数据仓库的架构设计和灵活性已经无法正常、好好地工作了，”Samantha说。

　　持久性的问题

　　Craigslist网站，在使用MySQL来处理每小时进入Craigslist的输入数据和成千上万的帖子时，从未有过任何真正的问题。问题是数据仓库。我想，出于隐私保护的原因，像Craigslist这样的公司，在一定的时间内必须清除所有的数据，但似乎正好相反。显然，有一些地方法律说，他们必须归档他们所收到的每一块数据。当你是世界上最大的在线分类广告和招聘网站时，归档所有的数据很快变成一个前所未有的大数据问题。

　　那么，Craigslist网站所遇到大数据问题是什么呢？

　　Craigslist网站遇到的一个主要问题是每当他们需要改变保留前端数据方式的时候，他们对后台归档数据就造成破坏。现在能做的一件事是，改变数据库处理非常容易管理的数据的模式，这些数据60天之内的。但是前端的一个模式改变将意味着，所有维护归档数据的数据库也要做同样的变化，这意味着要更新MySQL服务器集群十亿左右的记录。这不仅危险，而且非常耗时。

　　处理性能问题

　　然后出现了多米诺骨牌效应的性能问题，因为归档文件被修改时，那就没有归档了，这意味着实时系统正在超越其预期的能力。这是一个两败俱伤的局面，由于一个配置的改变导致后端倒下，从而用户访问网站体验异常的延迟并且没有响应。

　　Samantha说：“他们看了几个不同的NoSQL解决方案，其中一个是MongoDB，这是他们从2011年初选择的”。“他们决定把内容管理切换到MongoDB上。这花了大约三个月，并转移15亿帖子。”

　　MySQL和MongoDB解决方案

　　有关Craigslist网站有趣的事情虽然是事实，但他们并没有完全疯狂执著于他们的NoSQL解决方案。MySQL仍然是前端主力，并且它也本应该是。以用户为中心的数据不应该是无模式的，并且相应地，再从用户那里得到的数据继续填充MySQL服务器集群。

　　“它是如何工作的是，MySQL仍然是所有的在线性能和Craigslist网站帖子的有效数据库。但是，一旦一个帖子死掉，那么MongoDB就会读取到MySQL并且把那个帖子写入类似于JSON的文件中，这个文件是MongonDB存储信息的方法。这样做，Craigslist网站能够提供一个无模式的设计，它允许多年的文件进行灵活的归档，而不必担心失败或未来的灵活性和设计。”

　　它真是一个有趣的使用案例，不仅因为它显示了NoSQL解决方案是如何被应用在现实世界中的，而且它也展示了NoSQL存储的一个有趣用途。像MongonDB这样的数据存储，经常用于读访问时，并且速度优先。写入的NoSQL库时往往可以比较慢，甚至一致性（C）的优先级比高可用性（A）和分区（P）低，因为我们在研究了CAP定理时都学到了。但在这种情况下看，读取性能是一个微不足道的问题。毕竟，谁会非常着急要在Craigslist网站访问一个8年前死掉的关于租赁的帖子？

　　最后，Craigslist网站以关系型和无模式相结合的NoSQL解决方案的方式，证明了人们是如何在行业中创新和创造性地处理不断涌入的内容和信息问题。