В предыдущих статьях долго обсасывалась мысль, что ключевым фактором в успехеработы с Hbase является планирование первичного ключа. Hbase из коробки позволяет горизонтально масштабироваться, если вы не допустите одну роковую ошибку - монотонно возрастающий ключ...
Стро говоря вам не нужно беспокоится об этом типе проблемы, если у вас не больше 100 запросов в секунду к Hbase. Но если больше, то стоит задуматься, а скорее всего ваше приложение в конце концов будет делать гораздо больше запросов, поэтому думайте об этом с самого начал. Для того что бы объяснить почему это критическая проблема для приложения с высокой активностью записи посмотрим что происходит, когда регион А полностью заполнен, и теперь хочет сделать шардирование(split).
Это нормальная ситуация регион заполнился и разделил себя на несколько - работаем дальше. Допустим у вас row key какой-нибудь Email или название Url - то есть псевдослучайный ключ. Шардирование пока будет работать хорошо.
А теперь давайте проэмулируем ситуацию, когда вы используете например timestamp или какое-нибидь другое монотонно возрастающее значение ключа.
То есть шардинг произойдет, но так как ключи монотонно возрастающие, то новые значения начнут просто загружать новый регион и проблема перегрузки останется. Потому что как мы помним значения ключа отсортированы.
Комментариев нет:
Отправить комментарий