Страницы

суббота, 8 февраля 2014 г.

Hbase 3 планирование первичного ключа..

            В предыдущих статьях долго обсасывалась мысль, что ключевым фактором в успехеработы с Hbase является планирование первичного ключа. Hbase из коробки позволяет горизонтально масштабироваться, если вы не допустите одну роковую ошибку - монотонно возрастающий ключ...


Стро говоря вам не нужно беспокоится об этом типе проблемы, если у вас не больше 100 запросов  в секунду к Hbase.  Но если больше, то стоит задуматься, а скорее всего ваше приложение в конце концов будет делать гораздо больше запросов, поэтому думайте об этом с самого начал. Для того что бы объяснить почему это критическая проблема для приложения с высокой активностью записи посмотрим что происходит, когда регион А полностью заполнен, и теперь хочет сделать шардирование(split).

















     Это нормальная ситуация регион заполнился и разделил себя на несколько - работаем дальше. Допустим у вас row key какой-нибудь  Email или название Url - то есть псевдослучайный ключ. Шардирование пока будет работать хорошо.
















          А теперь давайте проэмулируем ситуацию, когда  вы используете например timestamp или какое-нибидь другое  монотонно возрастающее значение ключа.















        То есть шардинг произойдет, но  так как ключи монотонно возрастающие, то новые значения начнут просто загружать  новый регион и проблема перегрузки останется. Потому что как мы помним значения ключа отсортированы. 




Комментариев нет: