Использование salted-таблиц в Phoenix
Обзор
HBase распределяет свои данные по регионам, которые располагаются на серверах регионов. Регионы определяются диапазонами ключей строк. В некоторых случаях регионы с данными, принадлежащими небольшому диапазону пространства ключей, могут испытывать высокую нагрузку (как на запись, так и на чтение), в то время как другие регионы могут оставаться относительно ненагруженными. Обычно это происходит, когда ключи строк представляют собой некоторую монотонную последовательность (целочисленные идентификаторы, метки времени). Это называется hotspotting. Он приводит к снижению производительности и ненужным разделениям регионов.
Во избежание таких ситуаций в Apache Phoenix используется механизм под названием salting. При использовании salting к ключам строк добавляется префикс, который называется соль — один байт в случае Apache Phoenix. Это делается для того, чтобы соседние ключи имели более высокий шанс попасть в разные регионы. Это приводит к более равномерному распределению данных и более высокому параллелизму записи. Производительность чтения также может вырасти, но необязательно (см. Особенности).
Использование
Чтобы создать salted-таблицу, нужно задать количество префиксов ключей строк (salt buckets) для использования в таблице, например:
CREATE TABLE people (
name VARCHAR(50) NOT NULL PRIMARY KEY,
age SMALLINT,
town VARCHAR(50),
state VARCHAR(50),
country VARCHAR(50))
SALT_BUCKETS = 10;Эта команда создает пустую таблицу с десятью salt bucket. Теперь можно загружать данные в таблицу. Чтобы иметь возможность выполнять примеры, приведенные в этой статье, нужно импортировать данные из файла с тестовыми данными people.csv, как описано в статье Оператор JOIN в Phoenix. Используйте таблицу, созданную в примере выше.
Чтобы увидеть, как salting влияет на ключи строк, выполните следующий запрос:
SELECT * FROM people
WHERE people.name > 'X';Этот запрос должен вывести на экран всех людей, чьи фамилии начинаются на Y или Z.
Результат:
+-----------------+-----+-------------+-----------------+---------+ | NAME | AGE | TOWN | STATE | COUNTRY | +-----------------+-----+-------------+-----------------+---------+ | Young Della | 21 | Chetumal | Quintana Roo | MEX | | Yates Bill | 48 | Juarez | Chihuahua | MEX | | Yates Francis | 28 | Juarez | Chihuahua | MEX | | Yates Justin | 47 | New Orleans | LA | USA | | Yates Danny | 47 | Merida | Yucatan | MEX | | Yates Douglas | 35 | Phoenix | AZ | USA | | Zimmerman Madge | 46 | Nogales | AZ | USA | | Young Mattie | 39 | San Jose | CA | USA | | Yates George | 39 | Chihuahua | Chihuahua | MEX | | Yates Lucile | 25 | Chihuahua | Chihuahua | MEX | | Zimmerman Gene | 35 | Tijuana | California Baja | MEX | | Yates Johnny | 20 | Phoenix | AZ | USA | | Young Catherine | 60 | Juarez | Chihuahua | MEX | | Young Josephine | 29 | Redding | OR | USA | +-----------------+-----+-------------+-----------------+---------+ 14 rows selected (0.019 seconds)
Как видно, фамилии перечислены не в алфавитном порядке, хотя HBase должен сортировать ключи строк. Это произошло потому, что фамилии имеют префиксы, не отображаемые в выводе, и сортировка происходит по этим префиксам. Вы можете добиться вывода фамилий в алфавитном порядке, выполнив явным образом сортировку значений в столбце. Пример:
SELECT * FROM people
WHERE people.name > 'X'
ORDER BY people.name;Результат:
+-----------------+-----+-------------+-----------------+---------+ | NAME | AGE | TOWN | STATE | COUNTRY | +-----------------+-----+-------------+-----------------+---------+ | Yates Bill | 48 | Juarez | Chihuahua | MEX | | Yates Danny | 47 | Merida | Yucatan | MEX | | Yates Douglas | 35 | Phoenix | AZ | USA | | Yates Francis | 28 | Juarez | Chihuahua | MEX | | Yates George | 39 | Chihuahua | Chihuahua | MEX | | Yates Johnny | 20 | Phoenix | AZ | USA | | Yates Justin | 47 | New Orleans | LA | USA | | Yates Lucile | 25 | Chihuahua | Chihuahua | MEX | | Young Catherine | 60 | Juarez | Chihuahua | MEX | | Young Della | 21 | Chetumal | Quintana Roo | MEX | | Young Josephine | 29 | Redding | OR | USA | | Young Mattie | 39 | San Jose | CA | USA | | Zimmerman Gene | 35 | Tijuana | California Baja | MEX | | Zimmerman Madge | 46 | Nogales | AZ | USA | +-----------------+-----+-------------+-----------------+---------+ 14 rows selected (0.024 seconds)
В этом случае, когда выражение ORDER BY используется для столбца ключей строк, соль игнорируется.
Для просмотра списка salted-таблиц выполните следующий запрос:
SELECT table_name, salt_buckets
FROM SYSTEM.CATALOG
WHERE salt_buckets IS NOT NULL;Пример результата:
+---------------+--------------+ | TABLE_NAME | SALT_BUCKETS | +---------------+--------------+ | PEOPLE | 10 | | PEOPLE_SALTED | 10 | | LOG | 32 | +---------------+--------------+
Особенности
-
Количество salt bucket (диапазон возможных значений соли) следует выбирать в зависимости от размера кластера и ожидаемого объема записи. Имеет смысл начать с количества из расчета одно значение соли на один сервер регионов. Далее можно экспериментировать для получения оптимального значения.
-
Обычно salting улучшает производительность записи, но потенциально может привести к ухудшению производительности чтения, если запросы на чтение зависят от исходного порядка ключей строк. Phoenix будет автоматически выполнять сканирование по всем значениям соли, что может быть менее эффективно, чем сканирование конкретного региона.
-
Salting привносит сложность. Полезно понимать распределение данных в кластере и паттерны осуществления доступа к ним для определения целесообразности использования salting.
-
Возможно, придется внести изменения в тексты запросов для учета salting. Например, может потребоваться использовать оператор
LIKEсовместно с wildcard для маскировки соли в ключе. -
Salting может привести к нелокальности данных. Если необходим постоянный доступ к данным, связанным близкими оригинальными значениями ключей, salting вынужденно приведет к сканированию нескольких регионов.