Пропускная способность DynamoDB и время поиска

Question

Я только что обнаружил большую ошибку, которую допустил при создании структуры динамод. Я создал 11 таблиц, в то время как одна из них является таблицей, на которую в основном ссылаются, а другие являются дополнительными. Например, у меня есть таблица, в которой хранятся имена (вместе с другой информацией) с именем «Имена», и другая таблица с именем «NamesMappings», в которой все эти имена добавляются в таблицу «Имена», так что каждый раз, когда пользователь хочет добавить имя в таблицу «Имена» он сначала пытается поместить имя в «NamesMappings», и только в случае успеха (следовательно, это имя не существует) он может добавить имя в таблицу «Имена». Эта процедура помогает, если имя не уникально и не является первичным ключом в таблице «Имена», и с помощью этого метода мне не нужно искать в таблице «Имена», если имя существует, но вместо этого я могу попытаться добавить это в таблицу «NamesMappings», и только в случае успеха я знаю, что это уникальное имя.

Прежде всего, я хотел бы спросить вас, является ли это общим подходом или есть лучший?

Далее я выяснил, что с этим дизайном я скоро достиг 11 таблиц, каждая из которых имеет 5 выделенных ресурсов для чтения и записи, что приводит к общему количеству 55 выделенных ресурсов для чтения и записи в рамках бесплатного уровня. Затем я понял, почему я получаю все эти платежи каждый месяц, потому что по мере того, как количество таблиц становится больше, и я оставляю выделенную емкость по умолчанию (обе емкости чтения / записи равны 5), я получаю все больше и больше выделенной емкости.

Итак, каким должен быть мой вывод из этого понимания? Должен ли я попытаться уменьшить количество таблиц, даже если требуется больше усилий для предварительного сканирования и запросов внутри таблицы? Или я должен разделить таблицу так же, как я, но уменьшить емкость этих таблиц сопоставлений, используемых только для указания, существует ли элемент в другой таблице?

Answer 1

Если я правильно понимаю вашу проблему, вам не хватает всей концепции баз данных NoSQL.

Ваша таблица Names должна иметь ключ Hash (аналогичный первичному ключу), который генерируется равномерноидентификатор (UUID является отличным кандидатом).Это автоматически сделает эту таблицу запрашиваемой по этому уникальному идентификатору.Вы сказали, однако, что вы не знаете удостоверение личности, но вместо этого вы знаете только имя.Это заставляет меня думать, что вы можете создать Глобальный вторичный индекс (GSI) для атрибута Name внутри таблицы Names, чтобы вы также могли делать запросы по Name.До этого момента структура вашей таблицы должна выглядеть следующим образом:

id | name

Обе они независимо запрашиваются, что уже дает вам большую гибкость.

Теперь предположим, что вы хотите добавить атрибут NameMapping (который я не знаю, как он выглядит), вы можете просто добавить его в таблицу Names, избавившись от таблицы NamesMappings, значительно уменьшивколичество WCU и RCU в вашем аккаунте.Структура вашей таблицы теперь должна выглядеть следующим образом:

id | name | mappings

, где mappings - это, скажем, объект JSON.

Поскольку вы можете запрашивать только сверхуАтрибуты уровня в DynamoDB теперь можно выполнять запрос к атрибуту name, для которого настроен GSI.Если запрос ничего не возвращает, то name уникален.Но допустим, что вам все еще нужны некоторые данные внутри объекта mappings, тогда вы можете запросить по name и, в своем коде , вы можете применить операцию map / filter / reduarn к mappingsатрибут и решить, что делать дальше.

Помните, что дублирование просто нормально в мире NoSQL.Это может показаться пугающим, если вы пришли из чисто SQL-среды, но данные должны храниться в базах данных NoSQL таким образом, чтобы вы могли получать всю необходимую информацию за один раз, избегая, таким образом, join "(объединения все еще возможны в базе данных NoSQL, но поскольку между сущностями нет сильных связей, вам нужно выполнить эти объединения вручную на уровне кода).Чтобы дать вам реальный контекст, представьте, что у вас есть таблица Orders, в которой вы отслеживаете заказанные Продукты и Магазин, которому принадлежит Заказ: вы сохраняете как Продукты, так и объекты Магазина (а не их идентификаторы, какэто будет происходить способом SQL) внутри объекта Order, поэтому, если вы захотите запросить данный OrderId в будущем, вам не нужно будет делать дополнительные вызовы (или " присоединяет ") кТаблицы Product / Store для получения информации, так как все уже будет храниться внутри объекта Order.