Атрибут DynamoDB типа Number может хранить 126-разрядные целые числа (или 127-разрядные целые числа без знака с серьезными оговорками).
Согласно документации Amazon :
Числа могут иметь точность до 38 цифр. Превышение этого приводит к исключению.
Это означает (проверено тестированием в консоли AWS), что наибольшее положительное целое и наименьшее отрицательное целое число, которые DynamoDB может хранить в атрибуте Number, соответственно:
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)
Эти числа требуют 126 бит памяти, используя следующую формулу:
bits = floor (ln(number) / ln (2))
= floor (87.498 / 0.693)
= floor (126.259)
= 126
Таким образом, вы можете безопасно хранить 126-битное целое число со знаком в DynamoDB.
Если вы хотите жить опасно, вы можете также хранить 127-битный unsigned int, но есть некоторые предостережения:
- Вам следует избегать (или, по крайней мере, быть очень осторожным) использования такого числа в качестве ключа сортировки, поскольку значения со старшим значащим битом 1 будут сортироваться как отрицательные числа.
- Вашему приложению потребуется преобразовать неподписанные целые числа в подписанные, сохраняя их или запрашивая их в DynamoDB, а также необходимо преобразовывать их обратно в неподписанные после чтения данных из DynamoDB.
Если бы это был я, я бы не стал рисковать ни на один лишний бит без очень, очень веской причины.
Один логический вопрос заключается в том, достаточно ли 126 (или 127 с учетом приведенных выше предостережений) для хранения UUID. Ответ: это зависит. Если вы контролируете генерацию UUID, то вы всегда можете сбрить немного или два из UUID и сохранить его. Если вы бреетесь из 4 битов версии (см. Формат здесь ), то, возможно, вы вообще не потеряете энтропию, если всегда генерируете UUID с одной и той же версией.
Однако, если кто-то еще генерирует эти UUID и ожидает хранилища без потерь, вы, возможно, не сможете использовать Number для хранения UUID. Но вы можете сохранить его, если вы ограничите клиентов белым списком 4-8 UUID . Самая большая версия в настоящее время составляет 5 из диапазона 0-15, а некоторые более старые версии не рекомендуется по соображениям конфиденциальности, поэтому это ограничение может быть разумным в зависимости от ваших клиентов и от того, придерживаются ли они биты версии, как определено в RFC 4122 .
Кстати, я был удивлен, что этот вопрос с ограничением по битам еще не был онлайн ... по крайней мере, не в легко доступном для Google месте. Так что добавив эту пару вопросов и ответов, чтобы будущие поисковики могли ее найти.