azure - DocumentDB 和仅插入架构

Question

我们正在寻找仅插入数据架构是否适合我们的项目。

这个想法是将实际版本存储在 S3 集合中，而存档(非实际)版本应放置在更便宜的 S1 集合中。

对于这种方法，我有以下担忧:

• 由于事务仅在分区级别范围内，这意味着如果在创建新版本时有触发器或存储过程来归档旧版本，我们无法确定 ACID 事务是否是 ACID 事务。这是一个正确的假设吗？有办法解决这个问题吗？

• 当您创建集合(实际上是一个分区)时，您可以在单分区集合和多分区集合之间进行选择。但一些微软视频告诉我，集合实际上是分区。当我假设选择多分区集合时，实际上与注册多个单分区集合相同，我是否正确？两者有什么区别？我可以在生产中在两种模式之间切换吗？

• DocumentDB 中的数据库用户数量和权限是否有限制？

Answer 1

您的问题涵盖了很多内容，因此我将尽力回答您所问的大部分问题，但其他人也应该发表自己的见解。

将“分区集合”视为一组集合，其中系统根据您选择的分区键自动决定哪些数据放入哪个分区。需要多少个分区/集合的逻辑不再由您掌控，编写您自己的分区代码的所有琐事也不再由您掌控，包括在扩展和缩减时重新平衡的非常棘手的琐事。此逻辑旨在允许您调整大小和吞吐量，同时保持读取延迟 <10ms p99 和写入延迟 <15ms p99。如果您现在正在构建一个新系统，并且希望随着时间的推移而扩展，我强烈建议您使用分区集合。

传统 S1、S2、S3 集合/分区的一个小争论是您可以以较低的成本开始。 S1 的价格低至每月 25 美元。当前分区集合的合理最低价格约为 600 美元，但我最近听说 Azure 正在将其降低(也许已经)到 150 美元(之前的 1/4)。 S1+S3 至少要花费 125 美元，所以它们大致相同。

现在，您无法在不备份和恢复的情况下在两种模式之间切换，因此这是从 git-go 的分区集合开始的另一个参数。也就是说，我听说如果您要求的话可以实现自动迁移，并且我怀疑它最终会是自助服务。

您是正确的，存储过程隔离(ACID 事务)仅适用于单个分区。在旧的 S# 模型和新的分区集合模型下都是如此，因此两者之间没有区别。我建议您仅使用存储过程进行写入(创建、更新插入、删除)，因为在存储过程之外进行读取会更有效，以允许辅助数据库做出贡献，并且您通常不需要 ACID 事务来进行读取。我们使用租户ID 作为分区键，并且从来没有跨租户写入事务，因此这对我们来说不是问题。根据您选择的分区键，这对您来说可能都不是问题。

DocumentDB 用户/权限系统旨在支持使用 OAUTH 等过期 key 进行直接客户端连接。只要您将 key 缓存在最终客户端中，我就被告知它可以很好地扩展，但如果您在每个请求上发出一个新 key ，那么众所周知，这会使其陷入困境。如果这符合您的用例，那就太好了。然而，它对于 Multi-Tenancy 之类的东西并不理想， Multi-Tenancy 可能在中间层实现得更好。