Кто из многих из вас сталкивается с проблемами, связанными с ограничением 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
Альмир М.