我们正在研究仅插入数据架构是否适合我们的项目。
我们的想法是将实际版本存储在S3集合中，而归档（非实际）版本应该放在更便宜的S1集合中。
对于这种方法，我有以下问题：
由于事务仅限于分区级别，这意味着如果有一个触发器或存储过程来在创建较新版本时归档旧版本，我们无法确定ACID事务，是这是一个正确的假设？有没有办法解决这个问题？
创建集合（实际上是分区）时，可以选择单分区集合和多分区集合。但是一些微软视频告诉我收藏实际上是分区。当我假设选择多分区集合时，我是否正确，这实际上与注册多个单个分区集合相同？两者有什么区别？我可以在生产中的两种模式之间切换吗？
DocumentDB中的数据库用户和权限数量有限制吗？
答案 0 :(得分：4)
你在问题中涵盖了很多方面，所以我会尝试回应你所提出的大部分内容，但是其他人应该以他们自己的见解来回应。
想想＆＃34;分区集合＆＃34;作为一组集合在一起，系统根据您选择的分区键自动决定哪些数据进入哪个分区。需要多少分区/集合的逻辑就像你编写自己的分区代码的所有琐事一样，包括在你上下扩展时非常棘手的重新平衡。此逻辑旨在允许您打开拨号大小和吞吐量，同时保持读取时的<10ms p99延迟和写入时的<15ms p99。如果您正在构建一个您希望随着时间的推移而扩展的新系统，我强烈建议您使用分区集合。
传统S1，S2，S3集合/分区的一个小参数是您可以以较低的成本开始。 S1可以低至每月25美元。分区收藏的当前合理最低价格约为600美元，但我最近听说Azure正在降低（可能已经降低）150美元（之前的1/4）。 S1 + S3会花费至少125美元，因此它们大致相同。
现在，如果不进行备份和恢复，则无法在两种模式之间切换，因此从git-go开始使用分区集合是一个额外的参数。也就是说，我听说如果你问我可以实现自动迁移，我怀疑它最终会自助服务。
您是正确的，存储过程隔离（ACID事务）仅适用于单个分区。在旧的S＃模型和新的分区收集模型下都是如此，因此两者之间没有区别。我建议您只使用存储过程进行写入（创建，升级，删除），因为读取在存储过程之外更有效地完成，以允许辅助程序进行贡献，并且您通常不需要ACID事务进行读取。我们使用tenantID作为分区密钥，我们从不进行跨租户写入事务，因此对我们来说这不是问题。根据您选择的分区键，它可能不是您的问题。
DocumentDB用户/权限系统旨在通过OAUTH等过期密钥启用直接客户端连接。只要你在最终客户端中缓存密钥，我就告诉它它可以很好地扩展，但是如果你在每个请求上发出一个新密钥，那么就已经知道它会陷入困境。如果这符合您的用例，那么很棒。但是，对于多租户这样的事情来说，它并不理想，这可能会更好地在中间层实施。