问题描述
我正在尝试进行我的第一个 Nosql 设计，但我在为我的用例找到正确的路径方面有点挣扎。
简而言之，用户是一个teanet的成员，这个teanet有一套只有teanet成员才能访问的产品。这些产品必须能够过滤，就像在普通电子商务网站上一样，但在这种情况下，产品是teanet的一部分。用户可以在很长一段时间内拥有很多产品，所以我认为在某些时候单个分区可能是一个问题，如果teanet有更多用户和数千个产品，也可以避免具有大量读取的热分区。
我最大的问题是如何正确获取分区键。
-
当我有一些特定于用户的数据时，PK 应该只是teanet_id 并位于teanet 容器中。例如，如果teanet 有自己的类别和标签，这可能在具有类型属性的teanet 分区中，其值为：类别和标签等？所以对于所有的数据来说，大约有 100-200 个文档可以使用相同的分区键在同一个集合中。
-
对于产品案例，我对深水有点了解。希望有人对如何为老年人制作好的 pk 有一个好主意，其中产品只能通过单个 Teanet 访问，并且必须订购/分页和显示，并且能够对价格、标签和类别进行过滤，并且只显示单个产品及其所有详细信息？
解决方法
鉴于变量的数量，很难对这个主题给出规定的“正确”答案。需要注意的一件事是分区策略还取决于您的租户隔离方法。如果按容器隔离租户，最终可能会采用与使用单个容器设计不同的方法。
值得一提的是，我在此处记录了最近一个项目中设计背后的一些想法以及演示文稿。
https://whally.com/blog/how-it-was-made
您会看到分区键是合成的，租户 ID 为前缀，项目类型为后缀。这运行良好，假设任何分区中的数据不超过 20 GB。对于这种情况，这是正确的，但您需要为自己的情况确定这一点。
对于产品，我的预感是将它们全部放置在每个租户的一个分区中，假设您在那里没有达到 20 GB 的危险。这样一来，您就可以在单分区范围内的产品查询中获得最大的自由。
始终可以选择添加额外的 materialized view 数据以针对特定查询进行优化。因此，您的分区键不一定需要针对每种情况产生最佳查询。