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

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

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

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

Аль-Амин

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