何时使用CouchDB与RDBMS
我在看CouchDB，它在关系数据库上有许多吸引人的特性，包括：
- 直观的REST / HTTP界面
- 容易复制
- 数据存储为文档，而不是标准化的表格
我明白，这不是一个成熟的产品，所以应该谨慎使用，但我想知道它是否实际上是一个可行的替代RDBMS（尽pipe介绍页面另有说明 – http://couchdb.apache.org/docs /intro.html ）。
- 在什么情况下，CouchDB比RDBMS（如MySQL）更好地select数据库，例如在可扩展性，devise+开发时间，可靠性和维护方面。
- 仍然有一些情况下RDBMS仍然是正确的select？
- 这是一种select，还是混合解决scheme更可能成为最佳实践？
我最近参加了伦敦的NoSQL会议，认为现在我有一个更好的主意如何回答原来的问题。 我也写了一篇博文 ，还有其他一些好的 。
关键点：
- 我们已经积累了大概30年的pipe理关系型数据库的知识，所以不应该经过慎重的考虑来取代它们。 非关系型数据存储比关系型数据存储不够成熟，采用固有风险更大
- 存在不同types的非关系数据存储; 一些是关键值存储，一些是文档存储，一些是graphics数据库
- 您可以使用混合方法，例如将RDBMS和graphics数据存储组合用于社交软件站点
- 文档数据存储（例如CouchDB和MongoDB）可能是最接近关系数据库的，并且提供了一个JSON数据结构，其中所有的字段都是分层显示的，避免了必须进行表连接，有些人可能认为这是对传统的对象 – 大多数应用程序当前使用的关系映射
- 非关系型数据库支持复制（包括master-master）; 关系数据库也支持复制，但它可能不像非关系选项那么全面
- 如Twitter，Digg和Facebook等非常大的网站使用Cassandra，它是从底层开始支持集群
- 关系数据库可能适合90％的情况
总之，共识似乎是“谨慎行事”。
直到有人给出更深入的答案，这里有一些CouchDB的利弊
优点：
- 你不需要把你的数据放到那些讨厌的高阶常态表单中
- 您可以随时更改数据的“架构”
- 你的数据将被准确的索引你的查询，所以你会得到在恒定的时间的结果。
缺点：
- 您需要为每个查询创build视图，例如类似查询的特殊查询（例如连接SQL中的dynamicWHERE和SORT）查询不可用。
- 你将要么有冗余的数据，要么你会在“客户端”自己实现连接和sorting逻辑（例如，在多个字段上sorting一个多对多的关系）
优点或缺点：
- 创build你的观点并不像在SQL中那样简单，它更像是解决一个难题。 取决于你的types，如果这是一个专业或合作:)
CouchDB是几个可用的“键/值”商店之一，其他的包括像BDB这样的老牌公司，像Persevere ， MongoDB和CouchDB这样的面向Web的公司，像Memcached （仅限RAM）和东京内阁这样的超级快速公司，以及像Hadoop和谷歌的BigTable（MongoDB也声称在这个空间）。
关键/价值商店和关系数据库都有一定的空间。 传统上，大多数RDB被认为是关键/价值之上的一层。 例如，MySQL曾经使用BDB作为表的可选后端。 简而言之，键/值对于作为SQL基础的字段和关系一无所知。
关键/价值商店通常比较容易扩展，这使得它在爆炸性增长时成为一个有吸引力的select，就像Twitter一样。 当然，这意味着存储值之间的任何关系都必须在代码上进行pipe理，而不是在SQL中声明。 CouchDB的方法是将大的“文档”存储在值部分中，使得它们（大部分）是自包含的，因此您可以在单个查询中获取大部分所需的数据。 许多用例适合这个想法，其他用户则不适用。
我看到的现在的主题是，“Rails不缩放!!” 恐惧，现在很多人都意识到这不是关于你的web框架的; 但关于智能caching，以避免碰到数据库，甚至可能的时候，甚至web应用程序。 memcached是后起之秀。
一如既往，这一切都取决于你的需求。
这是一个很难回答的问题。 所以我会尽量突出CouchDB可能会对您造成的影响。
Couch Users和Dev邮件列表中两个最大的困难来源是：
- 数据的复杂联接。
- 多步骤地图/减less。
沙发观点是自己的很多岛屿。 如果您需要聚合/合并/相交一组视图，那么现在在应用程序层中几乎必须这样做。 有一些技巧可以用查看sorting和复杂的键来帮助连接，但是这些只能用于某些types的数据。 对于不同的应用来说，这可能也可能不适合。 多次说这个问题可以通过不同的结构化数据来减less或消除。
其他人对这个问题的评论演示了一些非常适合于CouchDB的不同types的数据。
还有一点需要注意的是，您可能需要组合/合并/相交的数据很多时候都是在RDBMS数据库中脱机的数据，因此您可能不会因为在CouchDB中执行相同操作而丢失任何数据。
简答：我认为最终CouchDB将能够处理任何你想要抛出的问题。 但是，使用它的舒适度可能会因开发者的不同而有所不同。 我觉得这有点主观。 我碰巧喜欢使用图灵完整的语言来查询我的数据，并在应用程序层中保留更多的逻辑。 你的旅费可能会改变。
山姆你不得不采取与CouchDB和地图或基于文档的数据库的一般接触。 你不能定义一个唯一的约束，但你可以查询数据来检查是否使用该电子邮件，以及是否也使用该login。 这是正确的接近，你必须改变主意。
纠正我，如果我错了。 当您需要validation多个字段的文档的唯一性时，Couchdb对于这种情况是无用的。 例如，不可能执行validation规则，例如“login和电子邮件必须是唯一的”，并将数据保持为“干扰”状态。 您可以在保存文档之前检查，但是有人可以在您之前推送并且数据变得不一致。
如果您正在处理只有浅层数据层次的表格数据，那么RDBMS系统可能是您的最佳select。 这是RDBMS系统的主要用途，文档和工具支持非常好。
对于更多像xml这样的嵌套数据，文档数据库应该能够更快地访问数据。 此外，存储模型更类似于数据，所以检索应该更直接。
