目标应用程序是一个中型网站，每小时可支持数百到数千名用户，并且可以选择扩大规模。数据模型相当简单，缓存潜力相当高（读取与编辑操作的比率约为 10:1）。
在基于 SQL 的关系型数据存储与 NoSQL 选项（例如 HBase 和 Cassandra）之间进行选择时应该考虑哪些因素？
【问题讨论】：
标签： database-design architecture scalability nosql
对我来说，你没有什么特别的问题要解决。如果需要 ACIDity，请使用数据库；如果你不这样做，那也没关系。最后，只需构建您的应用程序。让我引用NoSQL: If Only It Was That Easy：
真正要指出的是，如果您因为无法选择数据库而无法做出超级棒的东西，那么您做错了。如果你知道mysql，就用它。在您真正需要时进行优化。像 k/v 商店一样使用它，像 rdbms 一样使用它，但是看在上帝的份上，构建你的杀手级应用！这对大多数应用程序都无关紧要。 Facebook 仍然大量使用 MySQL。 Wikipedia 大量使用 MySQL。 FriendFeed 经常使用 MySQL。 NoSQL 是一个很棒的工具，但它肯定不会成为你的竞争优势，它不会让你的应用变得热门，而且最重要的是，你的用户不会在意这些。
【讨论】：
your users won’t give a shit about any of this
Digg 在这个问题上有一些interesting articles。从本质上讲，您正在将处理的负担转移到写入而不是读取上，这在高度可扩展的应用程序中可能是可取的。特别是 Cassandra 也是高度可用的。
简单地说，Cassandra 是一个 带有 BigTable 的分布式数据库 在 Dynamo 上运行的数据模型，例如 基础设施。它是面向列的 并允许存储 相对结构化的数据。它有一个 完全去中心化的模型；每个节点 是相同的，没有单一的 故障点。也是极 容错；数据被复制到 多个节点和跨数据 中心。卡桑德拉也很 松紧带;读写吞吐量 随着新机器的增加而线性增加 已添加。
【讨论】：
我喜欢 Ian Eure 的经验法则：“如果您在数据库之上部署 memcache，那么您就是在发明自己的临时、难以维护的 NoSQL 系统。”
http://www.rackspacecloud.com/blog/2010/02/25/should-you-switch-to-nosql-too/
【讨论】：
当您说数据模型相当简单时，这可以说明 NoSQL 选项。
当您有大量属性可供选择、繁重的事务负载或复杂的表结构时，这将适用于传统 SQL 表。
我建议找出用一两个 NoSQL 数据库实现数据模型的难度。当这相当困难时，您还可以制作一个经典的表模式来进行比较。
当您在使用 NoSQL 时遇到困难时，这可能代表 SQL 选项。但也可能是，NoSQL 可以更好地处理繁重的负载——但也可能是一个好的 SQL 数据库可以充分扩展......
缓冲也可以通过一个简单的代理服务器来完成......
如果遇到困难，也可以考虑混合使用 NoSQL 和 SQL。
【讨论】：