将 couchdb 连接到生产服务器与使用中间关系数据库答案

【问题标题】：hooking couchdb up to a production server vs. using an intermediary relational db将 couchdb 连接到生产服务器与使用中间关系数据库
【发布时间】：2013-08-12 08:14:06
【问题描述】：

知道this discussion，对此进行了补充。

目前我们组织的工程师之间正在讨论标题问题。

一方面，有人认为将非关系数据库（即 CouchDB）连接到生产服务器绝不是一个好主意。他的架构建议是引入一个中间关系数据库作为两者之间的一种缓冲层（他特别推荐 SQLAlchemy 作为 Postgres->Flask/Django 之类的 ORM）

另一方面，另一位工程师认为，鉴于我们的（相对较低的）页面浏览量，我们可以在 CouchDB 中直接将整个工作投入生产。

我很想详细了解 nonrelational -> relational -> web page 架构与 nonrelational -> web page 架构的优缺点。

【问题讨论】：

如果您的公司和开发人员不准备在生产中支持任何特定的数据库，那么您可能不应该使用它。如果您在内部和在您的时间和技能无法满足需求时使用外部支持选项，那么如果技术支持您的需求，您就已经准备好了。如果您准备好了，CouchDb 已准备好投入生产。

标签： database couchdb relational-database bigdata non-relational-database

【解决方案1】：

将非关系型数据库（即 CouchDB）连接到生产服务器绝不是一个好主意

这对我来说听起来很危险。

我完全不知道在 CouchDB 和您的 Web 服务之间使用关系数据库的任何充分理由。什么是“缓冲区”数据库？ CouchDB 没有给你什么？或者，如果可以只使用关系数据库，为什么还要使用 CouchDB？

我能想到的唯一半合法的论点是您需要它，因为您有一些数据需要的关系建模，并且您必须转换为关系数据库才能正确地做到这一点，并提供一个理智的界面到您的网络服务。不过，在这种情况下，您真的应该只使用独立的关系数据库（或图形数据库，或其他东西，而不是文档存储）。

另一方面，有很多反对意见，包括：涉及的数据重复、必须以某种方式找到并修复的潜在数据冲突、构建和维护额外系统以监控两者的额外复杂性数据库并使它们保持同步，在两种数据建模方式之间转换的挑战，以及对 CouchDB 的许多好的方面的否定（灵活的模式、没有单点故障的数据复制、任意结构化的数据、易于扩展，方便的HTTP接口等）

我目前在一家公司工作，该公司刚刚成功部署了大约 20 个 CouchDB，分布在尽可能多的数据中心，由几千台服务器持续使用，每天为数百万用户提供服务。它绝对可以投入生产，而且我不知道有任何实质性的性能或可靠性问题（只要您知道自己在使用基础设施设置做什么）。

【讨论】：