我正在使用分区的CosmosDb，但是每次我想通过其ID获取资源时，我都不知道分区键的值。现在，将id用作分区键对我来说不是一个解决方案，因为它会花费很长时间并且占用太多空间（我听说分区键的最大数量为10GB，但我有更多的方法。）
我的想法是操纵2个字节的GUID，以便将分区键值映射到每个guid。这样，我不必使用跨分区查询，而是可以轻松地从GUID获取分区键值。在GUID中是否有我无法更改的保留字节？是否有针对此问题的最佳实践？
答案 0 :(得分：2)
GUID中有一个基于时间的组件，您可以更改该组件，如果您了解其后果，则不会导致冲突。您可以在这里阅读一些想法：
https://blog.stephencleary.com/2010/11/few-words-on-guids.html
相关章节为：
基于时间的GUID（版本1）基于时间的GUID是变体2，版本1 RFC 4122 GUID，也称为“顺序GUID”，因为它们可以是 生成的值彼此非常接近。他们包括三个 除了“版本”和“版本”以外的其他字段：60位UTC时间戳， 14位时钟序列和48位节点标识符。
节点标识符通常是计算机的MAC地址 生成基于时间的GUID（保证是唯一的， 因为MAC地址使用注册系统）。但是，也可能 是一个47位随机值（设置了广播位）。在这种情况下， 与真实的MAC地址没有冲突的危险，因为 物理MAC地址的广播位始终为0。存在危险 与其他随机节点标识符的冲突；特别， 1379万个随机节点有50％的碰撞机会 进入网络。
注意：当前不是使用随机值代替MAC地址 由Microsoft的Win32 API支持。这意味着任何GUID 使用UuidCreateSequential完成的生成将公开MAC 地址。
“时钟序列”字段被初始化为随机值，并且 自从 最后生成的GUID（例如，如果计算机使用 时间服务器，或者如果它丢失了日期并认为是1980年）。这允许 16,384个时钟复位，没有任何碰撞危险。如果GUID 生成速度如此之快，以致系统时钟没有移动 从上一个GUID的时间戳记开始向前移动，然后生成GUID 算法通常会停止运行，直到系统时钟增加 时间戳。
顺序GUID实际上不是顺序的。在正常情况下 由同一台计算机生成的GUID将逐步 增加时间戳字段（其余字段保留） 不变）。但是，时间戳字段不在 GUID的最低有效位位置，因此如果对GUID进行了处理 作为128位数字，实际上并不会增加。
请务必注意，相继碰撞的可能性 GUID非常小。时钟序列和时间戳几乎 当然唯一地标识一个时间点，以及节点标识符 几乎可以确定唯一的来源。
可以通过Win32函数创建顺序的GUID UuidCreateSequential或通过使用Windows SDK中的uuidgen.exe 传递-x参数。
您也可以在此处查看相关规范：