Многопрофильность, список отфильтрованных записей и горячие разделы с Dynamodb
Я пытаюсь создать приложение с простыми требованиями:
- Есть несколько сотен или тысяч арендаторов, 90% нагрузки приходится на несколько
- они публикуют записи, которые никогда не обновляются через некоторое время (будучи своего рода журналами)
- Мне нужно получить список самых последних 1к записей для арендатора (но хранить их все в БД) редко
- или запись с его уникальным UUID, который будет составлять много миллионов записей для всех размером около 0,5-2 КБ, также редко запрашивается.
Я выбрал DynamoDb, так как это очень базовые требования, хорошая интеграция без сервера и лямбды, у меня низкая нагрузка, и это представляется возможным реализовать.
Проблема возникает с равномерным распределением RCU/WCU, как я ее сейчас читаю. Возможная структура будет следующей:
ID (основной ключ раздела) арендатор (ключ раздела GSI) время (ключ сортировки GSI)
Но, как я понимаю, емкость WCU распределяется равномерно по разделам, поэтому, когда у меня есть 100 WCU для GSI, 1000 арендаторов когда-либо размещали что-либо в целом, 10 наиболее активных арендаторов каждый, каждый из которых берет ~ 10 WCU, было бы далеко не достаточно, поскольку 100 разделить на 1000. Таким образом, 1 арендатор получит 0,1 WCU, либо он активен, либо давно покинул мой ресурс.
Тогда возникает вопрос с фильтрацией по ID: если бы у меня был индекс по ID с WCU / RCU 100, 1kk записей в БД, то все они получили бы все 100 RCU/WCU? Я узнал об увеличении ключей, думаю, это применимо к UUID.
Разве я не выбрал неправильную БД для этой задачи?