Рекомендации DynamoDB для извлечения большого подмножества данных

Скажем, у меня есть одна таблица с 50 000 элементов, и PK для каждой записи — это уникальный номер. Половина этих элементов имеет свойство «опубликовано», установленное на «1», а другое — на «0».

Большую часть времени я буду извлекать отдельные элементы с помощью хеш-ключа, но иногда я хочу иметь возможность получить ВСЕ элементы, для которых опубликовано = 1 или 0 (в идеале — пакеты с разбивкой на страницы).

У меня мог бы быть GSI с PK в атрибуте «опубликовано», но тогда у меня было бы 25 000 записей на значение, что, как я понимаю, было бы плохо, потому что PK должны быть более уникальными, чем это (пожалуйста, дайте мне знать, если я понял это неправильно).

У меня могут быть отдельные таблицы для опубликованных/неопубликованных, но в моем обычном случае использования отдельных элементов мне не нужно заранее знать, был ли элемент опубликован или нет (также Amazon говорит, что хорошо спроектированные приложения обычно имеют только одну таблицу).

Любые советы или предложения будут высоко оценены.


person rangfu    schedule 04.09.2018    source источник
comment
Что бы вы сделали с 25 тысячами предметов, когда вы их извлекаете? Это слишком много. Это потребовало бы чрезвычайно дорогой емкости чтения. Он не должен быть уникальным. Такие GSI называются разреженными индексами. Вместо 0 просто напишите null и он не будет проиндексирован. docs.aws.amazon.com/ amazondynamodb/latest/developerguide/   -  person Can Sahin    schedule 04.09.2018
comment
@CanSahin 1. Я надеялся, что смогу разбить их на страницы (получить их партиями) - обновил вопрос, чтобы включить это. 2. Хорошая идея, спасибо - если я смогу использовать разреженный индекс для получения неопубликованных элементов (обратное получение опубликованных элементов), я смогу это сделать.   -  person rangfu    schedule 04.09.2018


Ответы (2)


DynamoDB не следует использовать для массовых обновлений или массового чтения. Он предназначен для транзакционного чтения или записи. Если вы имеете дело с массовыми обновлениями, RDS будет хорошим выбором для транзакционных данных.

Если вы хотите использовать только ограниченный набор данных, вы можете прочитать набор в определенный момент времени, но запрашиваемый вами номер не будет учитываться все время. Все, что доступно в это время, будет доставлено вам вместе с маркером, известным как lastEvaluatedKey.

Кроме того, в качестве альтернативы вы можете использовать Published в качестве ключа диапазона, это поможет читать по разделу, но массовое чтение/запись в Dynamodb займет много времени и не будет хорошей архитектурой.

Надеюсь, поможет.

person Kannaiyan    schedule 04.09.2018

Несколько вещей:

  1. 25 000 — это не так уж много элементов для одного раздела. Но если ваша таблица разрастется до десятков миллионов элементов, у вас возникнут проблемы.

  2. Не бойтесь сканирования — если вы рассчитываете получить половину элементов в таблице, сканирование действительно очень эффективно!

  3. Если вы знаете, что будет опубликована (или неопубликована) только небольшая часть элемента, то разреженный GSI будет очень эффективным, но если распределение примерно наполовину, то это не имеет особого смысла: просто сканируйте стол!

person Mike Dinescu    schedule 05.09.2018