没有分区键属性的documentDb中的文档会发生什么情况? [英] What happens to documents in documentDb that have no partition key property?

查看:47
本文介绍了没有分区键属性的documentDb中的文档会发生什么情况?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

看看如何使用分区键设置DocumentDb,如果我有一个多租户应用程序,其中大多数文档都有一个tenantId,那么用/tenantId/分区键创建集合似乎是合理的.

Looking at how to set up DocumentDb with a partition key, if I have a multi-tenant application, where most documents have a tenantId, it seems reasonable to create the collection with a partition key of /tenantId/.

不具有tenantId属性的文档会发生什么?会只是添加它们而无需添加它们,还是Cosmos DB会使用某种系统(硬编码)tenantId创建这些对象/文档,然后将它们存储在一起?

What happens to documents that don't have a tenantId property? Will they just get added without one, or will Cosmos DB create those objects/documents with some kind of system (hard-coded) tenantId, so they are stored together?

推荐答案

为这些文档自动分配了分区键的未定义"值(类似于JavaScript的未定义).如同任何其他值一样对待它,并且所有缺少键的文档都存储在同一分区中.如果您有大量此类文件,那么扩展方面将遇到麻烦,因为丢失键中的所有写入都将分配给同一分区.

These documents are automatically assigned the "undefined" value for partition key (similar to JavaScript's undefined). This is treated like any other value, and all documents with missing keys are stored within the same partition. If you have a large number of these, then you would have trouble scaling as all writes within missing keys would get assigned to the same partition.

通常最好避免这种情况,或者稍后通过删除/重新插入来解决此问题(如果缺少分区键是由于某种异步特性,即在创建时不知道分区键).

It's generally a good idea to avoid this, or fix this later by deleting/reinserting (if this lack of partition key is due to some asynchronous nature of not knowing the partition key at creation time).

这篇关于没有分区键属性的documentDb中的文档会发生什么情况?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
相关文章
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆