用例：当前，我们在世界各地的办公室中都有非常间歇的Internet访问。有时效果很好，但有时一次可能会消失数小时。
现在，我们正在使用的CouchDB在云中具有一个主数据库，并且我们的文档带有office_id。然后，我们对所有这些“办公室”进行过滤同步，以仅发送具有office_id且还不到一个月的文档。
使用CouchDB，您可以编辑这些文档并在这些办公室的离线CouchDB服务器上添加新文档。目前，我们有一个cron，它每隔5分钟左右将复制复制到云中的主数据库中。
问题：尽管CouchDB确实使同步变得非常容易，但我担心CouchDB会出现一些可伸缩性问题。在为时已晚之前，我正在尝试探索不同的数据库途径和方法。
Amazon似乎将其支持MongoDB的DocumentDB产品加倍，所以我很好奇：
我不想陷入缩放使我陷入困境的情况。
答案 0 :(得分：1)
Amazon DocumentDB使用的共享存储根本不是您想要的，并且不能解决您的问题。在您的方案中，MongoDB将是一个非常糟糕的选择，而主-主复制是一个很难解决的问题。 CouchDB（就像您使用的一样）是第一个想到的，但是如果您要寻找替代品，则应该真正搜索该显式功能。还要注意，许多多主服务器设置都假设在主服务器之间进行了分区，但是客户端仍然可以连接到所有或某些主服务器，但情况并非如此，因为客户端只有一个有效的主服务器。
另一种选择是使用队列系统或类似系统自己构建复制，但是这将需要在每个位置建立更多的基础结构（因为问题是Internet连接断开），并且只有在以下情况下“简单”不同的办公室很少或永远不会编辑相同的文档，因为手动进行合并非常麻烦。
您没有解释扩展方面的担忧，但是我没有真正看到MongoDB或任何其他NoSQL数据库具有比CouchDB更大的可扩展性。
编辑：您真正追求的是乐观复制（或惰性复制，最终一致性）
答案 1 :(得分：1)
由于您提到了“ NoSQL等效项”，所以我想解释一下Couchbase如何以两种不同的方式实现这一目标：
1）跨数据中心复制（XDCR）-允许不同大小的群集在它们之间同步数据。可以暂停/恢复复制而不会出现任何问题（可以通过时间戳或文档修订来解决冲突）。复制可以是单向和双向的，您还可以使用过滤表达式（简化的查询系统）https://docs.couchbase.com/server/6.5/xdcr-reference/xdcr-filtering-expressions.html
来过滤哪些文档应在群集之间同步化。2）同步网关-它是一种中间件，最初旨在将您的主数据库与边缘数据库同步。在这种体系结构中，我们假设连接在大多数情况下都将断开。 https://blog.couchbase.com/couchbase-mobile-embedded-java-write-throughput/。您的应用程序可以简单地使用同步网关流，并将更改插入集群副本中。 （尽管我认为XDCR对您来说足够了）
Couchbase很早以前就作为CouchDB的分支而开始的，并且大多数代码已被重写，但是Couchbase中仍然存在一些核心概念。 最后，迁移到Couchbase的一大好处是它是一个分布式且高度可扩展的数据库（在单个集群中从1到> 100个节点），您将能够使用N1QL https://query-tutorial.couchbase.com/tutorial/#1