Comments 6
Для тех, кто решит использовать Clickhouse, небольшой момент. Да, одним местом прочитал документацию, но…
Clickhouse не любит множественные одиночные записи — это сильно поднимает нагрузку на сервер. Поэтому лучше записывать все в отдельный log (используя даже оперативную память, если не страшно потерять данные или отдельную таблицу в базе данных или более специализированных решениях), а затем с этого лога вынимать первые 5-10 тысяч записей, группировать их самостоятельно (если возможно), и только затем делать multiple insert. Это будет намного быстрее и эффективнее.
Clickhouse не любит множественные одиночные записи — это сильно поднимает нагрузку на сервер. Поэтому лучше записывать все в отдельный log (используя даже оперативную память, если не страшно потерять данные или отдельную таблицу в базе данных или более специализированных решениях), а затем с этого лога вынимать первые 5-10 тысяч записей, группировать их самостоятельно (если возможно), и только затем делать multiple insert. Это будет намного быстрее и эффективнее.
"Clickhouse не любит множественные одиночные записи" все колоночные СУБД не любят их, не только CH. Это особенность архитектуры. Решение Вы описали, однако ИМХО не ссмое надежное. Как более стабильный вариант — прослойка в виде РСУБД, развернутой на иных машинах от MPP-кластера, и далее вставка батчами по 5-50-500к строк
Странный выбор, учитывая что в последнем запросе кх просто упал. То есть у вас неполный функционал, зато быстро. Джойны, словари обошли стороной.
Мы год назад тестировали clickhouse vs postgresql + cstore vs MSSQL с CCI для сложных OLAP запросов на железе выше среднего (1 машинка с 128 ядер, 512 ram, nvme). И тогда вывод был такой:
1. Cstore не умеет эффективно параллелить на больше, чем 8 потоков + он не в ядре -> отсутствие нормального кеширования -> избыточная и неоправданная нагрузка на диск. Так что, совсем не то.
2. Clickhouse реально сделан при понимании всей боли от работы с традиционными субд -> множество функций типа ArgMax именно из разряда «как же хотелось такое же в других СУБД». Очень крутой паралеллизм на простых запросах. Но, увы, стоит дать что-то принципиально сложнее простого group by, и привет однопоточный план -> для реальных задач очень просто нарваться на запрос, который будет шуршать неделю.
3. Тёплый ламповый MSSQL, на удивление, хорош на таблицах с кластерным колоночным индексом (даже планы заметно лучше и параллельнее для одинакового запроса, одинаковой схемы, но при колоночном хранении данных). Да, пролицензировать лицензией за ядро космос (а лицензия за сервер это ограничение на 20 ядер), и да, кластера, как в CH, не поднимешь. Вообщем, для себя сделал вывод, что если исполняются два условия, — данные помещаются на одной железке (а сейчас железки на 8 сокетов, 12ТБ памяти и дисковой подсистемой с перфомансом в 25ГБ/сек это реальность) и стоимость лицензии не пугает, то это лучшее решение на рынке под ряд бигдатных задач.
Ну и, ещё несколько вариантов даже не тестировали. Среди них:
1. Hadoop, spark — команда хорошо владела SQL, и переучиваться на map reduce в явном виде, — сильная потеря темпа. Об решениях SQL over spark/hadoop для сложных запросов ничего хорошего не слышал.
2. Vertica, teradata, — отличный способ крепко и наверняка сесть на иглу консалтинга (ведь как такового рынка состоявшихся специалистов по этим технологиям нет, а найти молодого способного с горящими глазами и мечтой изучить Вертику задача нетривиальная). Нет, спасибо.
1. Cstore не умеет эффективно параллелить на больше, чем 8 потоков + он не в ядре -> отсутствие нормального кеширования -> избыточная и неоправданная нагрузка на диск. Так что, совсем не то.
2. Clickhouse реально сделан при понимании всей боли от работы с традиционными субд -> множество функций типа ArgMax именно из разряда «как же хотелось такое же в других СУБД». Очень крутой паралеллизм на простых запросах. Но, увы, стоит дать что-то принципиально сложнее простого group by, и привет однопоточный план -> для реальных задач очень просто нарваться на запрос, который будет шуршать неделю.
3. Тёплый ламповый MSSQL, на удивление, хорош на таблицах с кластерным колоночным индексом (даже планы заметно лучше и параллельнее для одинакового запроса, одинаковой схемы, но при колоночном хранении данных). Да, пролицензировать лицензией за ядро космос (а лицензия за сервер это ограничение на 20 ядер), и да, кластера, как в CH, не поднимешь. Вообщем, для себя сделал вывод, что если исполняются два условия, — данные помещаются на одной железке (а сейчас железки на 8 сокетов, 12ТБ памяти и дисковой подсистемой с перфомансом в 25ГБ/сек это реальность) и стоимость лицензии не пугает, то это лучшее решение на рынке под ряд бигдатных задач.
Ну и, ещё несколько вариантов даже не тестировали. Среди них:
1. Hadoop, spark — команда хорошо владела SQL, и переучиваться на map reduce в явном виде, — сильная потеря темпа. Об решениях SQL over spark/hadoop для сложных запросов ничего хорошего не слышал.
2. Vertica, teradata, — отличный способ крепко и наверняка сесть на иглу консалтинга (ведь как такового рынка состоявшихся специалистов по этим технологиям нет, а найти молодого способного с горящими глазами и мечтой изучить Вертику задача нетривиальная). Нет, спасибо.
найти молодого способного с горящими глазами и мечтой изучить Вертику задача нетривиальнаяВы либо искать не умеете, либо Вам ее и не надо. Скорее второе ибо у вас ведь «бигдата» на 1 сервер влезает:)
По сути — как раз в Вертику порог входа низкий. «Глупые вопросы» можно задавать в tlg: @vertica_ru. Супердорогие профессионалы обязательно ответят. Бесплатно. Community Edition до 1 Тб — бесплатно. Развернуть можно хоть на 3-х маминых ноутбуках.
И наконец стоимость, описанной выше железки на 8 сокетов с 12 Тб памяти и MS лицензий на это — это очень норм, по российским меркам, кластер Вертики на mid-range серверах HP/DELL.
Но если Вы на полном серьезе сравниваете MPP-решения, РСУБД на стероидах и Hadoop, то это разговор не для 1 кружки пива) Хорошей пятницы!
Sign up to leave a comment.
Как в Солнечной галактике Clickhouse выбирали