Comments 7
Great job (и статья, и материал для нее), спасибо!
В ClickHouse тщательно продумана организация хранения данных в памяти — по колонкам.
Мне кажется, корректнее говорить, что организация хранения тщательно оптимизирована для решения тех задач, для которых СУБД предназначена. А то создается впечатление, что раньше просто не умели подумать и поэтому хранили по строкам. Впрочем, и СУБД с колоночным хранением — не невидаль.
С такими массивами очень удобно работать.
Речь ведь идет об удобстве разработчика, а не конечного пользователя, верно? Здесь можно вспомнить название книжки Купера, но раз уж это статья разработчика и для разработчиков, то ОК. К тому же нынче заметен тренд на создание СУБД заказной разработки и с низкоуровневым доступом.
Просто я удивился, что в названии статьи в блоге Яндекса отсутствует слово «Яндекс» и подумал, что зашкаливающий маркетинг будет внутри. Но нет, нашлись только вот такие следовые количества. В остальном см. первый абзац.
Про колонки и работы с массивами — да, удобство исключительно для разработчика, я ни в коем случае не говорю, что это лучшее решение для пользователей.
Наверное, мы не очень друг друга поняли. Мое маленькое уточнение на тему «удобство разработчика или удобство пользователя» касалось работы с массивами, паддингов в 15 байт и т.д. Оно не касалось колоночной организации хранения.
Или вы и вправду думаете, что колоночная организация хранения — исключительно для удобства разработчика СУБД? Что, например, создатели Amazon Redshift перепиливали PostgreSQL для того, чтобы потом (когда?) было удобнее им самим, а не пользователям AWS? Решили сами заняться рефакторингом Postgres, так сказать? Вот это уж точно будет «психбольница в руках пациентов».
Или тут имелись в виду «колонки» не в том же смысле, в котором ClickHouse является СУБД с колоночным хранением, и это я вас неправильно понял?
Не сочтите, конечно, за обесценивание ваших трудов. Посмотрев «близкие к реальным» данные и запросы Яндекс.Метрики, я понадеялся, что такие данные и запросы составляют меньшинство, что это не то, для чего создавался и предлагается использовать ClickHouse. Конечно, не то чтобы благородные доны совсем не занимались разбором строк, но все же они предпочитают работать с «things, not strings», как по другому поводу выразился тот, кого тут, наверное, нельзя называть. Но тогда и эффективная обработки строк — достаточно второстепенная задача.
Кликхаус очень удобно использовать в качестве логохранилища, и работы со строками там нужны
ОК, согласен. Правда, хранение логов тоже можно организовать по-разному: хранить их более сырыми или менее сырыми. Например, в Firefox в базе places.sqlite в таблице moz_places есть предвычисляемый столбец rev_host, позволяющий облегчить типовые тяжелые запросы.
Но я, конечно, слабо представляю себе характер и масштаб задач Яндекс.Метрики. Кажется, возможные подходы к организации хранения данных в ней были рассмотрены в этой статье.
o6CuFl2Q, а можно попросить вас добавить в бенчмарки что-нибудь на тему джойнов? А то правда производит впечатление какой-то строкогрызки.
Умные алгоритмы обработки строк в ClickHouse