В Hadoop нижний слой (файлы в HDFS) умеют только добавление в конец, поэтому на Hadoop хорошо легла идея SSTable, когда memtable периодически идёт на диск в формате SSTable (сортированный список key=value) и идея фонового compaction. Ну и придумали HBase.
Схема данных в HBase - это BigTable. На нижнем уровне данные хранятся как куча key=value.
Про timestamp в ячейке давайте пока забудем.
Key выглядит так: row:CF:column. То есть, имея 2 разных CF мы получим для всех строк 2 отдельных последовательности ключей:
1.
2.
3.
4.
row1:CF1:column = xxx
row2:CF1:column = xxx
row3:CF1:column = xxx
...
и
1.
2.
3.
4.
row1:CF2:column = xxx
row2:CF2:column = xxx
row3:CF2:column = xxx
...
Как-то много дублирования данных!
Я не очень понимаю кому это было надо. Ну то есть конечно круто, когда можно в CF без предупреждения добавить новую колонку. Но это ведь происхоит нечасто. Все хипстеры, гордящиеся своим document-oriented, что они могут легко на лету поменять "схему" (которой нет) меняют её всё равно не так уж часто, а в моменты добавленя новых фич. Это я к чему - будет понятно позже. Читаем далее )
Ну например google решил собирать про сайты какую-то новую метрику - "rt", например время ответа. Была CF "timings". Там была колонка "a". Гугл добавит туда колонку "rt" и будет класть данные туда. Физически на диске колонка "rt" сохранится рядом с прочими колонками из CF "timings" и будет всё так:
1.
2.
3.
4.
RU.MAIL:timings:a=500
RU.MAIL:timings:rt=800
ZZ.DOMAIN:timings:a=500
ZZ.DOMAIN:timings:rt=800
Но бОльшую часть времени "схема" не меняется. Колонки обычно содержат очень дофига записей.
Зачем физически на диске дублировать названия колонок в ключах для каждого значения ? Почему желая сохранить 1 млрд значений для колонки rt я должен 1 млрд раз сохранить байты "timings:rt" на хранение ключа? Почему не запилить некую гибридную схему, которая в таких случаях (с млрд последовательными значениями) приближает физическое хранение данных к тому, что дают чистые column-oriented типа YandexClickhouse, когда 1 млрд значений прото лежат друг за другом?
Я так догадываюсь, всё дело в мега-разряженности BigTable. Если у вас нет мега-разряженности, когда колонок овердохрена, а данные для конкретной строки занимают всегда процентов 5 всех колонок, тогда BigTable не оптимально использует хранилище, не оптимально позволить просканировать столбцы. То есть, реально нужно это только реальному гуглу или яндексу, которые собирают адские тысячи параметров про каждую строку, 99% из которых всегда пустуют.
Так?
