Как реализовать масштабируемую, неупорядоченную коллекцию в DynamoDB?

Question

Я занимаюсь реализацией масштабируемой неупорядоченной коллекции объектов поверх Amazon DynamoDB. До сих пор следующие варианты были рассмотрены:

1. Используйте DynamoDB типов данных документов (карты, список) и использовать путь к документу для доступа автономных пунктов. У этого есть один очевидный недостаток, поскольку коллекция ограничена 400 Кбайт данных, что означает, возможно, 1..10K объектов в зависимости от их размера. Менее очевидным недостатком является то, что стоимость вставки нового объекта в такую ​​коллекцию будет огромной: Amazon указывает, что емкость записи будет вычитаться на основе общего размера элемента, а не только недавно добавленного объекта, поэтому 400 единиц мощности для вставляя объект 1 КБ при приближении к пределу размера. Итак, учитывая это исключено?

2. Использование составной первичной хеширования + диапазон, где основной хеш остается неизменным для всех объектов в коллекции, а клавиша диапазона - это что-то случайное или атомный счетчик. Очевидным недостатком является то, что наличие идентичного хеш-ключа приводит к плохому распределению ключей - мощность мала, когда есть коллекции с большим количеством объектов. Это означает неправильное разбиение на разделы и наличие проблемы масштабирования при всех чтениях/записи в одной коллекции, привязанных к одному осколку, становясь предметом 3000 чтения/1000 операций записи в секунду для раздела DynamoDB.

3. Использование глобального вторичного индекса со вторичным ключом хэша + диапазона, где хеш-ключ остается неизменным для всех объектов, принадлежащих к одной и той же коллекции, а ключ диапазона - это что-то случайное или атомный счетчик. Как и выше, разбиение становится неудовлетворительным для GSI, и оно станет узким местом со слишком большим количеством идентичных хэшей, которые быстро истощают всю обеспеченную пропускную способность индекса. Я не нашел, как GSI реализуется точно, поэтому не уверен, насколько сильно он страдает от низкой мощности.

Вопрос в том, смогу ли я жить с (2) или (3) и страдают от неидеального распределения ключей, или есть другой способ реализации коллекции, которая была упущена, или, возможно, я должен вообще рассмотреть глядя в другой движок базы данных nosql.

Answer 1

Это ответ «стрельба из бедра», то, что вы делаете, может зависеть от того, сколько и какого типа чтения и записи вы делаете.

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

Документы по операциям запроса и сканирования (http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/QueryAndScan.html) говорят, что для запроса «вы должны указать имя и значение атрибута хэш-ключа как условие равенства». Поэтому, если вы хотите избежать сканирования, это может по-прежнему заставлять вашу руку и возвращать вас в эту ситуацию с горячим ключом.

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

Если вы используете AWS, эластичная/redis может быть другим способом попробовать? Первый проход мог бы кодировать намного быстрее/чище, чем ситуация (1), о которой вы говорили.