节日期间可能会有太多火鸡，但我一直在考虑Couchbase可能存在的潜在问题。
目前我们基于时间分页，但我认为与其他用于分页的值（例如原子计数器）可能会发生类似的问题。我会尝试尽力解释，这只会出现在负载均衡的环境中。
例如说我们有4台服务器负载均衡并将数据存储到我们的Couchbase集群。我们根据当前的时间戳对记录进行排序。如果编写数据的4个服务器中的任何一个开始落后于其他服务器，那么在检索客户端时，我们的分页可能会丢失记录。例如，当记录存储到DB时，可以创建SQL DB自动增量和时间戳，这将避免类似的问题。使用像Couchbase这样的NoSql DB，可以在将数据存储到数据库之前定义需要检索的数据。所以我得到的是，如果存储到数据库的延迟，并且您在这种延迟发生时以分页方式进行检索，则会出现丢失数据的真实可能性。由于我们正在分页，因此可能永远无法查看数据。
对人们对此有何其他想法感兴趣。
修改** 回应安德鲁：
例如，facebook或pintrest类型应用程序正在将数据存储到数据库，它们有许多从前端写入数据库的负载平衡服务器。如果由于某种原因写入延迟，则SQL DB没有问题，因为当数据实际存储到DB时会发生时间戳或自动增量。分页时不会丢失数据。要求1-7将为您提供仅存储在DB中的数据，7- *将包含任何延迟的内容，因为尚未为该记录创建自动增量值，因为它实际上并未存储。
在Couchbase中它与众不同，你实际得到你的自动增量值（原子计数器），然后保存它。因此，例如说一条记录将被存储为原子计数器4.由于某些原因，这在存储到DB时会延迟。其他服务器正在抓取5,6,7并正确存储数据。客户端现在要求1到7之间的所有数据，4仍然没有存储。然后下一个寻呼请求是7到*。永远不会被看到4。
有解决方法吗？可以在CB中以不同方式建模，或者这只是在需要分页结果时CB的潜在弱点。正如我所提到的，分页对时间戳敏感。
答案 0 :(得分：2)
迈克尔，
Couchbase是一个关于视图的最终一致的数据库。关于文件是ACID。有耐久性接口可以让您管理它。这意味着您可以放心，您不会丢失数据，并且索引最终会赶上。
根据我使用Couchbase的经验，您需要期望节点永远不会同步。数据库正在做很多事情，比如压缩和复制。您可以做的最重要的事情是将视图放在与数据不同的主轴上。而且您需要确保整个群集中的主数据轴可以承受3-4倍的摄取带宽。另外，请确保主文档键适当散列以分配负载。
听起来您正在讨论一种情况，即系统中存在数据的时间比通过视图系统处理的时间短。如果要快速删除数据，则需要更大的群集或更快的磁盘阵列。在这两个选项中，我会扩展您的群集的大小。我想将Couchbase视为构建RAIS，独立服务器冗余阵列。通过扩展群集，可以减少热点的重合并获得磁盘带宽。我的理想节点有两个本地驱动器，分别用于数据和视图，以及足够的RAM用于我的工作集。
匿名， 安德鲁