относительно базы данных amazon dynamodb

Например, рассмотрим составную основную таблицу хеша и таблицу ключей диапазона, где хеш-ключ представляет идентификатор устройства и где идентификатор устройства «D17» особенно сильно запрашивается. Чтобы увеличить пропускную способность чтения и записи для этой «горячей» хэш-клавиши, выберите случайное число, выбранное из фиксированного набора (например, от 1 до 200), и объедините его с идентификатором устройства (так что вы получите D17.1, D17.2 через D17.200). Из-за рандомизации записи для идентификатора устройства «D17» распределяются равномерно по нескольким значениям хэш-хэшей, что обеспечивает лучший параллелизм и большую общую пропускную способность.

     

Эта стратегия значительно улучшает пропускную способность записи, но чтение для конкретного элемента становится более сложным, так как вы не знаете, какой из 200 ключей содержит элемент. Вы можете улучшить эту стратегию, чтобы получить лучшие характеристики чтения: вместо того, чтобы выбрать абсолютно случайное число, выберите число, которое вы можете вычислить из чего-то, что является неотъемлемой частью предмета. Например, если элемент представляет лицо, у которого есть устройство, вычислить суффикс хеш-ключа с их именем или идентификатором пользователя. Этот расчет должен вычислять число от 1 до 200, которое распределяется довольно равномерно с учетом любого набора имен (или идентификаторов пользователя). Обычно достаточно простого вычисления (например, произведение значений ASCII для букв с именем человека по модулю 200 + 1). Теперь записи распределяются равномерно по хэш-ключам (и, следовательно, к разделам). И вы можете легко выполнить операцию get, потому что вы можете определить хэш-ключ, который вам нужен, когда вы хотите получить определенное значение «владелец устройства». Операции запроса все равно должны выполняться против всех ключей D17.x, и вашему приложению требуется некоторая логика на стороне клиента, чтобы объединить все результаты запроса для каждого хэш-ключа (в этом случае 200). Но схема избегает наличия одного «горячего» хэш-ключа, который принимает всю рабочую нагрузку.

может ли кто-нибудь объяснить, что они говорят в приведенном выше примере?

заранее спасибо

Аль-Амин

0
добавлено
Просмотры: 1

1 ответы

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

1
добавлено
Вы должны пометить галочку на этом ответе, если вы довольны (спасибо)
добавлено автор Martin Lyne, источник
Большое спасибо за ваш ответ.
добавлено автор Al Amin, источник