Кто из многих из вас сталкивается с проблемами, связанными с ограничением DynamoDB количества GSI (глобальных вторичных индексов)?

Давай сделаем шаг назад. Возможно, вы пришли в мир NoSQL относительно недавно, и то, что мы раньше считали само собой разумеющимся, теперь требует тщательного анализа. Это больше не о том, как данные хранятся, а скорее о том, как вы ищите эти данные. AWS DynamoDB имеет ограничение в 5 глобальных поисковых индексов на таблицу.

Предположим, у вас есть таблица профиля клиента в DynamoDB со следующими атрибутами:

  • customerId (hashkey)
  • имя
  • фамилия
  • второе имя
  • город
  • округ
  • почтовый индекс
  • название улицы
  • номер улицы

Предположим, вы настроили следующие пять GSI:

  • имя
  • фамилия
  • город
  • округ
  • почтовый индекс

Предположим, что эта настройка сработала для вас, а затем вы получите требование иметь возможность поиска по названию улицы. В качестве аргумента предположим, что в вашем продукте будет эта классная новая функция, которая позволит вам искать других людей, живущих на той же улице. У вас больше нет доступных GSI. Чем вы занимаетесь?

Вы можете применить три решения.

(1) Вам нужно переосмыслить, как вы настраиваете свою таблицу и свои индексы, о чем я резюмировал выше. Вместо того, чтобы иметь индекс для ОБЕИХ firstName и lastName, вы можете иметь индекс только для lastName. Это сработает для вас, если вы обычно ищете по lastName и firstName вместе, чтобы найти конкретного клиента. Таким образом, вы можете выполнить запрос с выражениями фильтра к этой таблице firstName-index, где lastName теперь является ключом раздела. Выражение фильтра будет в атрибуте firstName.

(2) Выполняйте потоковую передачу данных в RedShift и выполняйте поиск в RedShift:

Вы можете транслировать свою таблицу в Redshift, а на стороне RedShift вы должны определить реляционную структуру. Когда данные находятся в RedShift, вы можете выполнять SQL-запросы. Единственным недостатком этого является задержка, возникающая при потоковой передаче данных из DynamoDB в RedShift.

(3) Создайте дополнительную таблицу для хранения пар имя / значение, но здесь есть одна загвоздка:

Вы можете создать вторичную или дочернюю таблицу для хранения большого количества информации, по которой вы будете искать, и эта таблица в основном будет иметь parentId из основной таблицы и общие атрибуты пары Name, Value. Таким образом, для каждой записи в главной таблице профиля клиента у вас будет X элементов (строк) во вторичной таблице, потому что все остальные значения хранятся в этой вторичной таблице по вертикали. Это означает, что для каждой записи в основную таблицу профиля клиента вы должны делать на X записей во вторичную таблицу. DynamoDB должен справиться с этим, и поиск должен быть эффективным, но СТОИМОСТЬ увеличится из-за увеличения количества операций чтения / записи. Пока вы можете позволить себе эти дополнительные расходы, а это увеличивает ценность бизнеса, вы на правильном пути.

Надеюсь, это даст вам некоторые идеи. Вы можете следить за мной здесь, на Medium.com или в моем основном блоге http://almirsCorner.com

Альмир М.