есть запрет на Строку )

ребят, привет. Подскажите, в кликхаусе есть возможность делать ограничение на уникальность поля ? можно ли составной индекс (в mergetree) сделать уникальным ?

Привет. Нет, уникальный индекс сделать нельзя. Особенность работы, коротко можно сформулировать так: "при вставке данных, ничего не читаем".

понял, в планах соответственно такого тоже нет и не будет ?

Есть варианты, которые станут возможными после реализации UPDATE.

а апдейт в q3, насколько помню планируется ?

Да.

Привет, ребят , незнаю в тему ли, но хочу спросить. Есть ли смысл оборачивать Clickhouse чем нибудь вроде Hive/Impala/Drill . Цель сделать минимизировать переделки со стороны SQL

Есть ли какой-то опыт или объяснения почему не стоит так делать?

а не проще SQL переписать?

ну просто Clickhouse это именно что наружу полноценный SQL диалект предоставляет

и всякие особенности с Dcit'ами надо учитывать при разработке

ну просто Clickhouse это именно что наружу полноценный SQL диалект предоставляет

Не предоставляет он

На текущий момент, у кликхаус очень слабый диалект и сильно отличается от стандарта

ой, а нас здесь уже 2^8 человек

На текущий момент, у кликхаус очень слабый диалект и сильно отличается от стандарта

и??? вы хотите натянуть ужа на ежа и "привести к стандартному диалекту"? зачем? IMHO затея достойная лучшего применения энергии...

и??? вы хотите натянуть ужа на ежа и "привести к стандартному диалекту"? зачем? IMHO затея достойная лучшего применения энергии...

Я не хочу... ?

А в чем слабость диалекта, собственно?

Специфика базы: работать в основном с одной таблицей с неадекватными джойнами. Специфика самого SQL: часть вещей не по стандарту, очень много отсутствует моментов.

Ну таки имхо как раз в стандарте отсутствует очень много моментов. Тех же CountIf/SumIf мне очень сильно не хватает

Специфика базы: работать в основном с одной таблицей с неадекватными джойнами. Специфика самого SQL: часть вещей не по стандарту, очень много отсутствует моментов.

аналитика - это чаще всего звезда. просто так случилось в мире

зато очень много присутсвует других моментов и положительных плюшек =) давайте признаем уже, ClickHouse очень быстрый, но ОЧЕНЬ специфический молоток и надо с помощью него решать именно те задачи под котоорые он заточен и именно теми способами которые он предоставляет из коробки

аналитика - это чаще всего звезда. просто так случилось в мире

Я в курсе, только чтобы звезду сделать, вам здесь ответят, лейте кх в одну таблицу, а для звезды справочники подключайте на стороне

зато очень много присутсвует других моментов и положительных плюшек =) давайте признаем уже, ClickHouse очень быстрый, но ОЧЕНЬ специфический молоток и надо с помощью него решать именно те задачи под котоорые он заточен и именно теми способами которые он предоставляет из коробки

Пока плюс один, халява

Я в курсе, только чтобы звезду сделать, вам здесь ответят, лейте кх в одну таблицу, а для звезды справочники подключайте на стороне

да, потому что справочники работают эффективнее джойнов у товарищей. мне не сложно.

На данных до 1 тб я бы лично рекомендовал вертику бесплатную, шустрости не меньше, но полноценный SQL

У меня к справочникам ровно одна претензия - синтаксис довольно монструозный получается

ну вот смотрите, в Вертике есть projections в каком стандарте они описаны?

На данных до 1 тб я бы лично рекомендовал вертику бесплатную, шустрости не меньше, но полноценный SQL

до 1 Тб можно и на mysql + 1 сервер посидеть.

=)) ага, а потом ценник 70k баксов за второй терабайт и блять нормальных реселлеров в россии тупо нет... плавали знаем

до 1 Тб можно и на mysql + 1 сервер посидеть.

Можно и Машку за ляшку

Можно и Машку за ляшку

спасибо, пойду переслушаю

ну вот смотрите, в Вертике есть projections в каком стандарте они описаны?

Причем здесь стандарт и проекции?

Причем здесь стандарт и проекции?

ну я правильно понял что вы как бы говорите "ай ай вот в вертике все по стандарту, полноценный SQL" а я вот говорю что Вертика хороша, бесспорно, но в ней тоже ДОФИГА специфических вещей которыми тоже как в ClickHouse надо учиться пользоваться ;)

понимаете =) ClcikHouse сейчас это как nginx для аналитики, nginx вначале тоже умел с гулькин нос, реверс прокси с keep alive и хорошую раздачу статики а теперь на нем чуть ли не полноценные приложения начали писать =) и заметье, никто не бузил по поводу "ой у них конфиг не Апачевый, а какой то свой"

mysql тоже нужно учиться пользоваться

:)

Скорее нужно учить им не пользоваться :(

Скорее нужно учить им не пользоваться :(

фейсбук сидит на mysql и у них всё хорошо. это всего лишь один из инструментов.

угу. 100 миллиардов мух не могут ошибаться...

Скорее нужно учить им не пользоваться :(

да ладно, в web OLTP нагрузках с кучей мелких транзакций - MySQL себя прекрасно показал для своего времени =) и заставил тот же Pg подтянуться до нормального уровня (хотя и через костыли типа pgbouncer ;)

много кто сидит

кстати такое вот направление движения для CH рассматривали

отдельно - storage

поверх него - SQL?

угу. 100 миллиардов мух не могут ошибаться...

да, я думаю ведущие специалисты по СУБД мира конечно могут ошибаться, но не десять лет подряд

скажем, как у того же mysql - ISAM и Inno

да, я думаю ведущие специалисты по СУБД мира конечно могут ошибаться, но не десять лет подряд

с тех пор уже больше 10 лет прошло.

или у монги WT

и вообще работу в embedded режиме

Тот же графит ощутимо бы выиграл

с тех пор уже больше 10 лет прошло.

с тех пор - с каких? они с InnoDb на RocksDb мигрировали вот в прошлом году. вместо того, чтобы выкинуть mysql и заюзать что-то более подходящее. Что как бы намекает.

ну я правильно понял что вы как бы говорите "ай ай вот в вертике все по стандарту, полноценный SQL" а я вот говорю что Вертика хороша, бесспорно, но в ней тоже ДОФИГА специфических вещей которыми тоже как в ClickHouse надо учиться пользоваться ;)

Вы путаете стандарт диалекта

Вы путаете стандарт диалекта

=)) простите, я не знаю что такое "стандарт диалекта", для меня это ортогональные понятия

с тех пор - с каких? они с InnoDb на RocksDb мигрировали вот в прошлом году. вместо того, чтобы выкинуть mysql и заюзать что-то более подходящее. Что как бы намекает.

Это намекает, что за ошибки в выборе базы, приходится расплачиваться пристраиванием костылей.

=)) простите, я не знаю что такое "стандарт диалекта", для меня это ортогональные понятия

Тогда и спор ни о чем

И какие у них ошибки были?

выбор между тормознутым на то время pg и глючным mysql?

Тот же графит ощутимо бы выиграл

Да в общем не факт что SQL дает такой значимый overhead

дает

если много запросов

с тех пор - с каких? они с InnoDb на RocksDb мигрировали вот в прошлом году. вместо того, чтобы выкинуть mysql и заюзать что-то более подходящее. Что как бы намекает.

намекает это только на одно - они вынуждены жить с выбранной СУБД на старте проекта, так как затраты на переезд в другую БД и разработку под нее будет огромны. Вопрос чисто финансовый) Дешевле лепить костыли)

С учетом их бюджетов им проще просто развивать выбранную субд

в ту сторону, куда им нужно

если много запросов

Вопрос в том насколько станет быстрее

вопрос в том, что SQL как API для работы с данными достаточно паршив

Вот это новость ?

А что же удобно? ?

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

А что же удобно? ?

Был с месяц назад в одной конторе, которая до сих пор тянет FoxPro...

ну если кому-то нормально, что машина с машиной пытается общаться на пинжин-инглише каком-то, то да

SQL - удобный API для бухгалтеров

:)

ну, например, монговский язык запросов чем плох?

:)

обычный JSON

Это намекает, что за ошибки в выборе базы, приходится расплачиваться пристраиванием костылей.

интересно, в чём костыль-то? почему, если мы ошиблись, мы тратим время на написание нового движка для стораджа, а не меняем БД полностью

обычный JSON

этим и плох.

ну, например, монговский язык запросов чем плох?

Тем, что он без структуры

это как без структуры?

json не читабелен человеком, куча лишних кавычек везде просто

а нафиг его читать человеку?

SQL тоже хреново читаем, когда в экран не влезает

:)

ну это как регулярки. кто-то один написал, а потом все используют

а нафиг его читать человеку?

потому что разработкой занимаются люди.

пока ещё.

это еще один вариант

надо что-то поменять - и чума

Был с месяц назад в одной конторе, которая до сих пор тянет FoxPro...

У меня на работе тоже пишут очередной Г биллинг на оракле 9, это не значит,, то все в восторге

если ты SQL генеришь по частям

это еще один вариант

был бы yml - те же яйца, только без кавычек по поводу и без, можно было бы поговорить

если ты SQL генеришь по частям

то в профайлере будет полный запрос.

SQL тоже хреново читаем, когда в экран не влезает

Читаемость спорный момент, разбивать на куски запрос никто не отменял

в зависимости от фильтров -- у тебя тоже нечитаемая мешанина будет

sql = "SELECT " + ....

это еще прочтешь

ну и JSON на куски бей

кто мешает?