Я пытаюсь решить, использовать ли двоичный файл, число или строку для ключа раздела моей таблицы DynamoDB. Мое приложение представляет собой приложение для управления социальными событиями React.js / Node.js, в котором до половины объема данных, хранящихся в DynamoDB, будет использоваться для хранения связей между Предметами и Атрибутами с другими Предметами и Атрибутами. Например: друзья пользователя, посетители на мероприятии и т. Д.
Поскольку схема слишком тяжелая для ключей и поскольку максимальный размер элемента DynamoDB составляет всего 400 КБ, и по соображениям производительности и стоимости я беспокоюсь о том, чтобы ключи занимали слишком много места. Тем не менее, я хочу использовать UUID для ключей разделов. Есть общеизвестные причины предпочитать UUID (или что-то с аналогичным уровнем энтропии и минимальной вероятностью коллизий) для распределенных приложений без серверов, где несколько узлов выдают новые ключи.
Итак, я думаю, что мой выбор:
- Использовать шестнадцатеричный код UUID (32 байта сохраняются после удаления тире)
- Кодирование UUID с использованием base64 (22 байта)
- Кодирование UUID с использованием z85 (20 байтов)
- Использовать двоичный атрибут для ключа (16 байт)
- Используйте числовой атрибут для ключа (16-18 байт?) - числовой тип может вместить только 127 бит, поэтому мне придется выполнить некоторые приемы, такие как добавление бит версии, но для моего приложения это, вероятно, ХОРОШО. Увидеть
Сколько бит целочисленных данных может быть сохранено в атрибуте DynamoDB типа Number? для получения дополнительной информации.
Очевидно, что есть опыт компромисса с разработчиком. Использование шестнадцатеричной строки - самое ясное, но и самое большое. Закодированные строки меньше, но сложнее иметь дело в журналах, при отладке и т. Д. Двоичные и числовые значения сложнее, чем строки, но наименьшие.
Я уверен, что я не первый человек, который думает об этих компромиссах. Существует ли общеизвестная лучшая практика или эвристика для определения того, как следует хранить ключи UUID в DynamoDB?
Если нет, то я склоняюсь к использованию двоичного типа, потому что это наименьшее хранилище и потому что его нативное представление (в виде строки в кодировке base64) можно использовать везде, где людям нужно просматривать и рассуждать о ключах, включая запросы , ведение журнала и код клиента. Кроме необходимости преобразовать его в Buffer, если я использую DocumentClient, мне не хватает какой-то проблемы с двоичным типом или преимуществом одного из других вариантов в списке выше?
Если это имеет значение, я планирую, чтобы весь доступ к DynamoDB осуществлялся через Lambda API, поэтому, даже если требуется преобразование или сортировка, это нормально, потому что я могу сделать это внутри своего API.
Кстати, этот вопрос является продолжением вопроса 4-летней давности ( UUID-тип данных в DynamoDB ), но 4 года - это слишком долгое время в быстро развивающемся пространстве, поэтому я подумал, что это было стоит спросить еще раз.