ClickHouse это база данных, не визуализация.

Посмотрите доклад, например, или почитайте описание на сайте.

ClickHouse это база данных, не визуализация.

База это информация которую надо визуализировать

Ну, или не надо.

Можно, если это, например, "карта кликов" в Метрике.

Ага спасибо

База это информация которую надо визуализировать

"надо", а не "можно" - это ключевой момент

Ну пусть будет можно

визуализировать можно почти все, БД на это не влияет...

Я так понимаю что CH это eventually consistent хранилище, без каких либо гарантий чего либо?

ну тоесть я туда пишу данные и я не знаю что с ними будет

Всем привет :3

Всем привет :3

✋

Имеет смысл добавить этот чатик в раздел документации "если возникли вопросы" или здесь и так слишком много народу? )

Я уже добавил

https://clickhouse.yandex/#feedback

Спасибо ) А то я случайно в #176 наткнулся

ну тоесть я туда пишу данные и я не знаю что с ними будет

Если INSERT вернул Ok - значит данные записаны на файловую систему (не на диск) одной реплики. Это значит: - если kill -9, то с данными всё Ок; - если грубый рестарт сервера, то небольшой кусок последних данных будет потерян. При этом, данные которые были записаны не только что, не теряются, при условии выживания хотя бы одной реплики.

>- если kill -9, то с данными всё Ок; >- если грубый рестарт сервера, то небольшой кусок последних данных будет потерян. противоречивые параграфы

Если INSERT вернул Ok - значит данные записаны на файловую систему (не на диск) одной реплики. Это значит: - если kill -9, то с данными всё Ок; - если грубый рестарт сервера, то небольшой кусок последних данных будет потерян. При этом, данные которые были записаны не только что, не теряются, при условии выживания хотя бы одной реплики.

а если эта реплика после OK была безвозвратно утерена?

Первое - это убийство процесса clickhouse-server. Второе - это ресет на сервере (железо) нажали.

а, ты имеешь ввиду что фсинка нет

Из документации: "Кворумная запись отсутствует. То есть, вы не можете записать данные с подтверждением их получения более одной репликой. Если вы записали пачку данных на одну реплику, и данные ещё не успели разъехаться по остальным репликам, после чего сервер с этими данными перестал существовать, то эта пачка данных будет потеряна."

получается никаких гарантий нет

OK это чисто «ну окей, приняли»

Есть гарантия - например, те данные, которые уже реплицировались (см. SELECT * FROM system.replicas, SELECT * FROM system.replication_queue) никуда не исчезнут.

Это не гарантия

>- если kill -9, то с данными всё Ок; >- если грубый рестарт сервера, то небольшой кусок последних данных будет потерян. противоречивые параграфы

Никаких противоречий.

Не очень понятно, каких гарантий вы ожидаете. Синхронная репликация, если речь про это, дорогая вещь и не работает на больших потоках данных.

Надёжную вставку (exactly once) сделать можно без проблем.

О, кстати, как?

Надёжную вставку (exactly once) сделать можно без проблем.

Повторными вставками-то?

О, кстати, как?

Плюсую

Я делаю через промежуточную таблицу и INSERT INTO table SELECT FROM temp_table WHERE id NOT IN (SELECT id FROM table);

т.к. записей со временем становится дофига, заодно делаю фильтр по экстремумам (min/max от timestamp'а, например)

вам точно нужна CP-система для аналитики?

Повторными вставками, да

вообще это неплохо иметь гарантию вставки батча на сервер + 1 реплику

вообще это неплохо иметь гарантию вставки батча на сервер + 1 реплику

тогда цифр красивых не будет

CH судя по документации это очень большое количество компромиссов и «tradeoffs» для обеспечения высокой производительности на ряде специфичных нагрузок.

И хайп который из всех утюгов, звучит как «CH серебрянная пуля для аналитики», хотя есть куча подводных камней. Q&A на HL показателен

Меня очень сильно беспокоит что про подводные камни почти нигде никакой информации нет

я, в общем, не знаю даже как ответить, кроме повтора "вам точно нужна система с невероятными гарантиями для аналитики"?

я понимаю, что приятно иметь кворумную запись и записывать данные однократно

я, в общем, не знаю даже как ответить, кроме повтора "вам точно нужна система с невероятными гарантиями для аналитики"?

я не знаю с чего вы взяли «невероятные гарантии»

мне нужна гарантия что после OK данные рано или поздно появятся

всё

но это вообще не нужно таким продуктам

мне не нужно гарантии что они появятся сразу после OK

как не нужно?

это нужно хранилищам данных. вы же не будете в CH хранить сами данные?

если я деньги считаю, то как не нужно?

вы не будете иметь аккаунт с балансом в CH

я не собираюсь хранить данные в CH

ну вот

если я деньги считаю, то как не нужно?

мы уже обсудили этот момент, вроде как пришли к варианту, что CH не для нас...

что «ну вот»?

аналитка по деньгам, вы не поверите, это частный юзкейс

и там ничего страшного не произойдет, если 1% данных потеряется

я хочу посчитать сколько денег мне надо выплатить за некоторые виды событий партнёрам

эт не аналитика

и там ничего страшного не произойдет, если 1% данных потеряется

лол

окей

CH - это аналитика по логам, ни больше, ни меньше...

всем спасибо :)

короче CH это не аналитика, это игрушка для сбора «метрик на глазок»

или так, да

как long term сторадж для прометея покатит

ну я все-таки скажу еще раз, что с CH не сидел, но описываемые требования - это требования к хранилищу и бизнес-логике

я пойду пожалуй

ну я все-таки скажу еще раз, что с CH не сидел, но описываемые требования - это требования к хранилищу и бизнес-логике

открою секрет, в аналитике тоже есть точность, она нужна, и анализ - это не только прогноз

спасибо

окей, давайте от обратного

какой плохой кейс представляется вам, когда мы обсуждаем этот аспект?

Залили данные и не знаем залили ли

Какой тут ещё кейс

почему не знаем? сервак же ответил "ОК"

Ага, а чт опроизойдет для условного бизнеса?

Так пишут что ок это не факт что ок

А для бизнеса что?

ну, я может неправильно понял, но "не факт что ок" относилось к репликам, разве нет?

Ну и опять же, вся штука про распределенные системы - это building reliable things out of unreliable blocks. Если у вас бизнес-требование, что запись должна быть добавлена - то та самая eventual consistency просто достигается оберткой-приемником, который повторяет вставку раз в минуту, если не видит добавленной записи.

Ну и опять же, вся штука про распределенные системы - это building reliable things out of unreliable blocks. Если у вас бизнес-требование, что запись должна быть добавлена - то та самая eventual consistency просто достигается оберткой-приемником, который повторяет вставку раз в минуту, если не видит добавленной записи.

обертка на отдельной железке?

(с придыханием) микросервис

обертка падает, вслед за железкой БД?

хотя тут наверно я не прав

все, мне бежать надо, но ей-богу вы завышенные требования к продукту предъявляете. это как пинать php за отсутствие асинхронности.

наверно потому что продукт возвышенно назвался БД с аналитикой