Ibm cloud Cloudant分区设计建议

我正在将一个没有分区的Cloudant数据库迁移到Cloudant的新分区系统，以降低我的ibm cloud帐户的成本。上下文可以概括如下：

• 我正在处理具有类别名称的电子邮件对象
• 我每天可能会收到100多封新邮件
• 用户界面可以查询从日期A到日期B的电子邮件以及类别C1、C2、。。。C100在任何可能的类别组合中
• 该UI每页仅显示15封电子邮件

问题在于如何对这样一个数据模型进行分区，并尽可能避免全局查询（跨分区），因为全局查询比基于分区的查询成本更高

我原以为我会每天进行分区，但最终我会遇到这样一种情况：查询在4个月内过滤特定类别Cn上的电子邮件，但特定类别每天只接收1封电子邮件，这意味着要在UI上显示一个页面（共15封电子邮件），我应该执行15个不可接受的查询

在分区到来之前，我只是使用Lucene查询引擎进行全局查询，但由于成本的原因，这已经不是问题了

此外，我还考虑将所有电子邮件放在一个分区中，这样我就可以在该分区中使用相同的旧查询，因为它是一个分区，所以我不会使用全局查询价格，而是分区查询价格。这在理论上是可行的，但我想可能有一些限制，因为有关分区的文档建议不要在单个分区中放置“太多数据”

你对这种问题有什么建议吗

---

谢谢。

考虑到您的设计，我觉得没有分区键可以让您完全避免全局查询。根据经验，选择一个分区键，它允许您检索构成逻辑分组的所有数据。例如，设想一个订单系统，其中您有一组具有关联订单的客户——明显的分区键是一个唯一的客户id：然后您有一个与每个客户关联的所有数据的逻辑分组

在Cloudant博客上，有一篇关于分区的优秀文章系列：