选择数据库技术答案

【问题标题】：Picking a database technology选择数据库技术
【发布时间】：2011-01-08 02:08:50
【问题描述】：

我们正着手构建一个在线平台（API、服务器、数据、Wahoo！）。对于上下文，假设我们需要构建类似 twitter 的东西，但是 cmets（tweets）是围绕现场事件组织的。有关实时事件本身的信息必须尽可能快且一致地交付给客户端，而有关事件的 cmets 可能需要等待更长的时间才能交付。现场活动结束后，我们将阅读大量内容。

可扩展性非常重要。我们想从租用 VPS 切片开始，并从那里扩展。我是云的忠实粉丝，并希望尽可能长时间地呆在那里。我们可能会使用红宝石。

我确信我想尝试使用文档存储而不是 RDBMS。我喜欢无模式存储的想法以及通过关注键值来更容易扩展的承诺。

问题是我不知道哪种技术最适合我们的平台。我查看了 Couch、Mongo、Tokyo Cabinet、Cassandra 和带有斑点文档的 RDBMS。为这项特定工作选择合适的工具有什么帮助吗？

【问题讨论】：

标签： ruby mongodb couchdb cassandra tokyo-cabinet

【解决方案1】：

查看BJ Clark 的 NO SQL 替代比较。

可扩展性非常重要。

那么你需要考虑他博客的摘录：

东京内阁 - 无法缩放
Redis - 无法扩展
伏地魔计划 - 天平
MongoDB - 受限（已实现分片）
Cassandra - 鳞片
Amazon S3 - 扩展
沙发 - ~~无法扩展~~（Clustering & 复制）
MySQL - 无法扩展

并考虑HyperTable。这也是 No-SQL 替代方案的有力竞争者。它是 Google BigTable 概念的开源实现。我相信它可以很好地扩展，因为它被中国搜索引擎百度和娱乐门户网站 Rediff 广泛使用。

你是说：

有关现场活动的信息本身必须交付给客户尽可能快速且始终如一地，而关于该事件的 cmets 可以可能要再等一会儿发表。之后我们会读得很重直播活动结束。

这有点像 Twitter 的方法。您的编程语言选择也非常重要，因为 Twitter 最初使用 Ruby 进行后端消息传递，但 they were saying 这不是一个正确的选择，他们已将整个消息传递系统移至 Scala 语言。

他们仍在使用 Ruby 作为前端。如果您想使用非常适合可扩展环境的高度可靠、容错系统，那么您应该考虑Scala 或Erlang。

【讨论】：

为什么第 7 点。沙发 - 不能缩放？看看cloudant.com和couchio.com
是的，我也对 Couch 感到困惑。对于整体扩展的复制方法似乎存在一些严重的分歧。 Couch 的家伙将可扩展性列为他们的主要功能之一，而世界其他地方似乎对它们吹嘘不已。
CouchDB 的性能在每个版本中都提高了一个数量级。当前的主干性能与 8 月撰写该文章时完全不同。您首选的扩展策略将取决于您的情况。您可能需要复制或分片，而 CouchDB 具有内置的点对点复制，效果很好，您可以使用 couchdb-lounge 进行分片。

【解决方案2】：

Ramesh 有一个很好的总结。我要补充一点，Cassandra 具有比普通 Dynamo 克隆（如 Voldemort 或 Dynomite）更丰富的数据模型：具有命名、排序列的行，而不仅仅是键/值。 Twitter、Mahalo、Ooyala、SimpleGeo、WebEx 和其他 (http://n2.nabble.com/Cassandra-users-survey-td4040068.html) 正在使用 Cassandra，其中至少有一些在 EC2 或机架空间云服务器上运行 Cassandra 集群。

【讨论】：

【解决方案3】：

如果您想水平扩展（将数据分布在多个节点上），您必须考虑 CAP 定理。

http://www.julianbrowne.com/article/viewer/brewers-cap-theorem

这不是一件容易的事，但你必须选择，总会有某种权衡。

【讨论】：

谢谢...那是我读过的关于 CAP 定理的最佳文章。