我们正在着手构建在线平台（API，服务器，数据，Wahoo！）。对于上下文，假设我们需要构建类似twitter的内容，但是需要在现场活动周围组织注释（tweets）。有关直播活动本身的信息必须尽可能快速和一致地提供给客户，同时有关该事件的评论可能会等待更长的时间才能发送。现场比赛结束后，我们将会阅读更多。选择数据库技术
可伸缩性非常重要。我们想开始租用VPS切片，并从那里进行缩放。我是云端的粉丝，希望尽可能长时间呆在那里。我们可能会使用红宝石。
我确信我想尝试一个文档存储而不是RDBMS。我喜欢无模式存储的概念，以及侧重于关键值的更容易扩展性的承诺。
问题是我不知道哪种技术最适合我们的平台。我曾看过沙发，蒙戈，东京内阁，卡桑德拉和一个带有斑点文档的RDBMS。任何帮助为这项特定工作选择合适的工具？
结帐通过BJ Clark比较NO SQL替代方案。
可伸缩性非常重要。
然后，你需要考虑从他的博客摘录：
并考虑HyperTable。这也是No-SQL替代方案中的一个重要竞争者。它是Google BigTable概念的开源实现。 我相信它的规模很好，因为它被中国搜索引擎百度和娱乐门户Rediff广泛使用。
你在说：
有关现场活动 本身必须传送到客户端为 快速，持续地信息， 而关于该事件的注释可以 可能等待的时间长一点是 交付。在现场比赛结束后，我们将会在 之后重读。
这就像Twitter的方法。您的编程语言选择也非常重要，因为Twitter最初与Ruby一起用于后端消息传递，但它不是一个正确的选择，它们已将整个消息传递系统移动到Scala语言。
他们仍在使用Ruby作为其前端。如果您想要使用非常适合可扩展环境的高可靠性容错系统，那么您应该考虑使用Scala或Erlang。
Ramesh有一个很好的总结。我想补充一点，Cassandra比vanilla Dynamo克隆（如Voldemort或Dynomite）拥有更丰富的数据模型：具有命名，排序列而非键/值的行。 Cassandra被Twitter，Mahalo，Ooyala，SimpleGeo，WebEx和其他人使用（http://n2.nabble.com/Cassandra-users-survey-td4040068.html），其中至少有一些在EC2或机架式云服务器上运行Cassandra群集。
如果要横向扩展（将数据分布到多个节点上），则必须考虑CAP定理。
http://www.julianbrowne.com/article/viewer/brewers-cap-theorem
这是不容易的东西，但你必须选择，总有某种交易掉。
谢谢......这是我读过的关于CAP定理的最好文章。 – 2010-01-25 16:25:18
+1为优秀面试 – 2010-01-22 07:56:39
为什么要点7.沙发 - 没有规模？ 看看http://cloudant.com/和http://couchio.com/ – filippo 2010-01-22 13:48:27
是的，我也对沙发感到困惑。整体扩展的复制方法似乎存在一些严重的分歧。沙发家伙列出了可扩展性作为他们的主要特征之一，而世界其他地方似乎吹嘘他们。 – 2010-01-22 14:28:09