英文:
Compact alternatives to UUID as a correlationId
问题
我正在为我们的公共和私有API添加关联ID。这是为了能够通过日志跟踪请求的进度。
由于UUID是长字符串，占用了很多空间，我需要一种紧凑的替代UUID作为关联ID。
如果一个关联ID在固定周期后重复（比如2个月），那也没问题，因为那时候不需要跟踪API请求了。
我考虑过使用java.util.Random nextLong()，但它不能保证不重复。
此外，SecureRandom可能会带来一些性能问题，我也不需要关联ID是安全的。
希望能考虑其他选项。
英文:
I am adding correlationIDs to our public and private APIs. This is to be able to trace a request progress through logs.
UUIDs being long strings, take up much space. I need a compact alternative to UUID as a correlation ID.
It will be ok, if a correlationId repeats after a fix period (say 2 months) since the API requests older than that won't be required to be traced.
I have considered using java.util.Random nextLong(). But it does not guarantee that it won't repeat.
Also, SecureRandom can pose some performance issues is what I understand and also, I don't need the correlationIDs to be secure.
It would be good to have other options considered.
答案1
得分: 1
如果您可以接受最长为8个字符的ID，那么可能的ID数量取决于这些ID的字符集。
- 对于十六进制字符（16字符集），ID的数量为4294967296，即2^32。
- 对于A-Z、0-9（36字符集），ID的数量为2821109907456，约为2^41。
- 对于base64或base64url，0-9（63字符集），ID的数量为248155780267521，约为2^47。
您应该决定使用哪个字符集，并思考您的应用程序是否可以检查ID的随机性以及是否可以容忍重复ID的风险（以便您不会在使用SecureRandom随机生成它们时出现问题）。还请注意以下内容：
- 重复ID的风险取决于可能的ID数量。粗略地说，在您的应用程序随机生成所有可能ID的平方根后，重复的风险变得不可忽略（在十六进制ID的情况下，仅在生成了65536个ID后就会发生）。有关更精确的陈述和公式，请参阅“生日问题”。
- 如果您的应用程序分布在多台计算机上，您可以选择为每台计算机分配一个唯一的值，包含在ID中。
- 如果您不关心您的关联ID是否安全，您可以选择通过对顺序ID执行可逆操作来创建唯一的ID，例如可逆混合函数或线性同余生成器。
- 您提到
SecureRandom“可能会导致一些性能问题”。除非您尝试并测量应用程序的性能，否则您无法确定它是否对您的目的过慢。使用SecureRandom生成ID可能会或可能不会对您的目的太慢。
有关更多考虑和建议，请参阅我在“唯一随机标识符”中的内容。
英文:
If you can accept IDs up to 8 characters long, the number of possible IDs depends on the character set of those IDs.
- For hexadecimal characters (16-character set), the number of IDs is 4294967296 or 2^32.
- For A-Z, 0-9 (36-character set), the number of IDs is 2821109907456 or about 2^41.
- For base64 or base64url, 0-9 (63-character set), the number of IDs is 248155780267521 or about 2^47.
You should decide which character set to use, as well as ask yourself whether your application can check IDs for randomness and whether you can tolerate the risk of duplicate IDs (so that you won't have a problem generating them randomly using SecureRandom). Also note the following:
- The risk of duplicates depends on the number of possible IDs. Roughly speaking, after your application generates the square root of all possible IDs at random, the risk of duplicates becomes non-negligible (which in the case of hexadecimal IDs, will occur after just 65536 IDs). See "Birthday problem" for a more precise statement and formulas.
- If your application is distributed across multiple computers, you might choose to assign each computer a unique value to include in the ID.
- If you don't care about whether your correlation IDs are secure, you might choose to create unique IDs by doing a reversible operation on sequential IDs, such as a reversible mixing function or a linear congruential generator.
- You say that
SecureRandom"can pose some performance issues". You won't know if it will unless you try it and measure your application's performance. Generating IDs withSecureRandommay or may not be too slow for your purposes.
For further considerations and advice, see what I write on "Unique Random Identifiers".
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论