Number 类型的 DynamoDB 属性中可以存储多少位整数数据? [英] How many bits of integer data can be stored in a DynamoDB attribute of type Number?

问题描述

DynamoDB 的 Number 类型支持 38 位小数精度.这不足以存储需要 39 位数字的 128 位整数.最大值为 340,282,366,920,938,463,463,374,607,431,768,211,455(无符号 128 位整数)或 170,141,183,460,469,231,731,687,303,715,884,105,727(有符号 128-位整数)这些都是 39 位数字.

DynamoDB's Number type supports 38 digits of decimal precision. This is not big enough to store a 128-bit integer which would require 39 digits. The max value is 340,282,366,920,938,463,463,374,607,431,768,211,455 for unsigned 128-bit ints or 170,141,183,460,469,231,731,687,303,715,884,105,727 for signed 128-bit ints. These are both 39-digit numbers.

如果我不能存储 128 位，那么我在 Number 中存储多少位整数数据可以?

If I can't store 128 bits, then how many bits of integer data can I store in a Number?

推荐答案

Number 类型的 DynamoDB 属性可以存储 126 位整数(或 127 位无符号整数，有严重警告).

DynamoDB attribute of type Number can store 126-bit integers (or 127-bit unsigned integers, with serious caveats).

根据亚马逊的 文档:

数字的精度最高可达 38 位.超过这个会导致异常.

Numbers can have up to 38 digits precision. Exceeding this results in an exception.

这意味着(通过在 AWS 控制台中测试验证)DynamoDB 可以存储在 Number 属性中的最大正整数和最小负整数分别是:

This means (verified by testing in the AWS console) that the largest positive integer and smallest negative integers, respectively, that DynamoDB can store in a Number attribute are:

99,999,999,999,999,999,999,999,999,999,999,999,999(又名 10^38-1)-99,999,999,999,999,999,999,999,999,999,999,999,999(又名-10^38+1)

99,999,999,999,999,999,999,999,999,999,999,999,999 (aka 10^38-1) -99,999,999,999,999,999,999,999,999,999,999,999,999 (aka -10^38+1)

这些数字需要 126 位的存储空间，使用以下公式:

These numbers require 126 bits of storage, using this formula:

bits = floor (ln(number) / ln (2))
     = floor (87.498 / 0.693)
     = floor (126.259)
     = 126

因此，您可以在 DynamoDB 中安全地存储 126 位带符号整数.

So you can safely store a 126-bit signed int in a DynamoDB.

如果你想危险地生活，你也可以存储一个 127 位的 unsigned int，但有一些警告:

If you want to live dangerously, you can store a 127-bit unsigned int too, but there are some caveats:

• 您需要避免(或至少要非常小心)使用这样的数字作为排序键，因为最高有效位为 1 的值将排序为负数.
• 在 DynamoDB 中存储或查询无符号整数时，您的应用需要将它们转换为有符号整数，并且在从 DynamoDB 读取数据后还需要将它们转换回无符号整数.

如果是我，如果没有非常非常好的理由，我不会再冒这些风险.

If it were me, I wouldn't take these risks for one extra bit without a very, very good reason.

一个合乎逻辑的问题是 126(或考虑到上述警告的 127)是否足以存储 UUID.答案是:视情况而定.如果您可以控制 UUID 的生成，那么您始终可以从 UUID 中删除一两个并存储它.如果您从 4版本"中刮胡子；位(请参阅格式 此处)，那么您可能根本不会丢失任何熵，如果您总是生成具有相同版本的 UUID.

One logical question is whether 126 (or 127 given the caveats above) is good enough to store a UUID. The answer is: it depends. If you are in control of the UUID generation, then you can always shave a bit or two from the UUID and store it. If you shave from the 4 "version" bits (see format here) then you may not be losing any entropy at all if you are always generating UUIDs with the same version.

但是，如果其他人正在生成这些 UUID 并且期望无损存储，那么您可能无法使用 Number 来存储 UUID.但是，如果您将客户端限制在 4-8 个白名单 UUID 版本.现在最大的版本是 0-15 范围内的 5 个，出于隐私原因，不鼓励使用一些旧版本，因此此限制可能是合理的，具体取决于您的客户以及他们是否遵守 RFC 4122.

However, if someone else is generating those UUIDs AND is expecting lossless storage, then you may not be able to use a Number to store the UUID. But you may be able to store it if you restrict clients to a whitelist of 4-8 UUID versions. The largest version now is 5 out of a 0-15 range, and some of the older versions are discouraged for privacy reasons, so this limitation may be reasonable depending on your clients and whether they adhere to the version bits as defined in RFC 4122.

顺便说一句，我很惊讶这个位限制问题还没有在线......至少不是在一个容易谷歌的地方.所以贡献这个问答对，以便未来的搜索者可以找到它.

这篇关于Number 类型的 DynamoDB 属性中可以存储多少位整数数据?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！