LINUX.ORG.RU

HBase / Cassandra - как физически данные лежат на диске?

 


0

2

Сам вопрос можно найти наверное в последнем абзаце этого сумбурного поста.

Как в системах, моделирующих BigTable данные лежат на диске? Что с чем лежит ближе?

Например имеем табличку:

                 a:a       a:b      zz:a    zz:b
"com.cnn.news"   zuzuzu    sobaka   foo     -
"ru.mail"        -         -        -       murmur
"ru.mail.foto"   -         -        -       bububu

Тут у нас 2 column family: a, zz. Прочерк - данных нет.

Ну и допустим каждая ячейка имеет случайное число версий, которые тоже как-то надо хранить.

Сканировать все строки какого-то столбца в BigTable — это так же быстро, как в column-oriented DB? Или одна column family может рассматриваться как таблица, похожая на InnoDB где ряд колонок пакуется в одну запись и строки лежат целиком друг за другом?

В гугловой бумаге https://static.googleusercontent.com/media/research.google.com/en//archive/bi... написано, что одна column family держит свои данные отдельно от других column family. Значит ли это, что я могу создать column family из 1 колонки и получить таким образом column-oriented СУБД поведение с точки зрени хранения? У меня эта колонка будет лежать на диске отдельно, храня данные всех своих ячеек последовательно друг за другом и обеспечивая быстрый скан по этой колонке?

Но там ещё есть версии (timestamp) на каждую ячейку. Где это timestamp хранится и как? При сохранении колонки, сохраняются последовательно все её версии? Т.е. если мы сканируем колонку, то если в какой-то из них было 1000 значений, то мы «запнёмся» об это, т.е. пока не проскипаем 999 версий, не получим нашу?

Короче, я так понял BigTable-подобные решения (типа HBase) строят на чём-то типа LevelDB — это тупо key=value LSM хранилка. Неважно, что она LSM, важно что key=value. Правильно я понимаю, что BigTable в самом низком уровне имеет просто key=value систему? Так вот, мой вопрос и касается того, какие именно ключи будут лежать в системе для моей вышеприведённой таблички. Если можно ткните в конкретный сырец, который реализует интерфейс между «row» -> «column» -> timestamp и ключом. Я предположу, что ключ для key=value вычисляется так:

(псевдо PHP-код)

$key = $row_key + $column_family + ":" + $column_key + $timestamp;

Если ты про https://www.linux.org.ru/forum/development/13445721?filter=show, то cassandra совершенно не подходит для реализации очередей. Это больше write-only распределенная база-данных, где ни модификации, ни удаления данных нежелательны, а потому очереди пролетают.

Да, и зачем тебе cassandra сдалась? Это настолько мало случаев, где она действительно может быть полезна

dave ★★★★★ ()
Ответ на: комментарий от dave

Нет, я не про это. Тут я просто пытаюсь понять как BigTable на дисках лежит. Про SSTable знаю, но это не отвечает на вопрос как их таблички конвертятся в ключи для SSTable.

hlamotron ()

Правильно я понимаю, что BigTable в самом низком уровне имеет просто key=value систему?

Да: https://hbase.apache.org/book.html#keyvalue

Порядок на диске такой же, как и описан по ссылке выше: https://github.com/apache/hbase/blob/master/hbase-common/src/main/java/org/ap... (Ctrl+F → oswrite)

Если захочется разобраться самому, энтрипоинтом может послужить упомянутая выше книга и HFilePrettyPrinter.java (https://hbase.apache.org/book.html#hfile_tool).

edigaryev ★★★★★ ()
Ответ на: комментарий от edigaryev

Круто, спасибо. Всё это я спрашиваю, чтобы получить представление для чего BigTable-like модель подходит лучше. Все эти column families дают ощущение, что при желании можно сделать почти column-oriented DB. Скажем, создать column family с одной колонкой и оно будет лежать на диске последовательно. В то же время вообще вся BigTable напоминает document-oriented, где можно добавлять колонки не анонсируя их заранее. Что-то типа MongoDB, где есть поля в документах.

Попутно ещё пытаюсь понять, зачем начали плодиться эти BigTable-подобные системы. Ну гуглу было надо под свои задачи, но другим-то это зачем? Чё, индексируют весь интернет с сохранением версий страниц? Нафига всем эта модель данных?

hlamotron ()
Ответ на: комментарий от hlamotron

Всё это я спрашиваю, чтобы получить представление для чего BigTable-like модель подходит лучше.

Если у тебя нет необходимости хранить миллиарды записей, то тот же HBase в плане модели ничего нового не дает, а лишь отбирает: один индекс только по rowkey искаробки (хочешь еще один — придется генерировать его MapReduce задачей), нету JOIN'ов, нету типов и схемы, нету триггеров.

В Cassandra есть типы и схема, но нету быстрых prefix Scan'ов искаробки, потому-что это скорее реализация Dynamo, чем BigTable.

И там и там есть возможность использования timestamp'ов в своих грязных целях, но как ни крути, все эти особенности «BigTable-like модели» не понадобились бы вприницпе даже в обычной RDBMS.

Короче говоря, на мой взгляд суть не в модели, а в «web-scale» данного решения: ты можешь развернуть Hadoop + HBase кластер из десяти тачек, закидывать туда каждый день по 1 млрд. строк вида com.google.www:tls:fingerprint=<SHA256> (не самый удачный rowkey дизигн, да-да) и при этом отвечать пользователям на запросы типа «покажите мне все отпечатки поддоменов гугла» за пару сотен миллисекунд. А докинув потом еще десяток тачек помимо доступного объема повысишь еще и общую производительность всей БД.

edigaryev ★★★★★ ()
Ответ на: комментарий от edigaryev

Спасибо.

А правильно я понимаю, что column family даже с 1 колонкой будет проигрывать по производительности чисто column-oriented БД при сканировании строк, (типа там Vertica или Yandex Clickhouse, даже если мы отбросим вопросы сжатия).

Я так понял, если я создам CF с одной колонкой «col» и насохраняю в этот столбец 100 значений = 777, то на диск пойдут ключи вида:

"row1:cf:col=777"
"row2:cf:col=777"
"row3:cf:col=777"
...

Тогда как для чисто column-oriented DB (где есть схема) на диске будет лежать

777
777
777
...

?

hlamotron ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.