Упадет или ругнется и не загрузит кривой конфиг?

не упадет, будет каждые 2 сек писать в лог ошибки о том, что не смог обновиться

Однако.

мало того, по факту, SHOW PROCESSLIST тот же - это на самом деле запрос SELECT * FROM system.processes;, так что если хочется мониторить текущие запросы, можно выбирать не все столбцы, а какие-нибудь конкретные, тогда табличка будет поменьше

Спасибо.

https://github.com/yandex/ClickHouse/issues/81 https://github.com/yandex/ClickHouse/issues/76 на русском вот )

Комментарии имеются виду в коде, как я понимаю.

В коде да, переводят по мере сил и задетого кода на английский

да ! odbc ) это уже или еще ?

да ! odbc ) это уже или еще ?

похоже, что уже https://github.com/yandex/ClickHouse/tree/master/dbms/src/ODBC

а можно .. можно.. хотелку ? )) подержку именнованных подзапросов "with" мможна ?)

Интересно, что у Леши в стакане

На стакане кажется написано Martini

Выглядит как виски

Интересно, что у Леши в стакане? Отправь СМС на номер ...

)))

инеграцию с графитом поддерживаю обеими руками :)

А где голосовалка за фичи?:)

А что там про интеграцию с графитом?

А чем кликхаус лучше тарантула?

Они же для разного?

А чем кликхаус лучше тарантула?

тарантул для быстрой вставки и чтения по ключу, а КХ для агрегации

А где границы применения того и другого? Для каких задач вообще подходит кх, и какая граница сверху и снизу на разумный объём данных, которые в кх можно хранить?

Ну, вот, когда ещё рационально использовать, условно, бд для малых данных, а когда кх уже не справится?

А где границы применения того и другого? Для каких задач вообще подходит кх, и какая граница сверху и снизу на разумный объём данных, которые в кх можно хранить?

Если вам нужно работать с отдельными записями -- вставлять, менять и читать, то используйте Тарантул. Кстати он пока еще не умеет SQL.

тарантул для быстрой вставки и чтения по ключу, а КХ для агрегации

выборочное чтение одиночных записей - область применения ERP ?

выборочное чтение одиночных записей - область применения ERP ?

Область применеия чего угодно, где нужна быстрая работа с отдельными записями.

А, с какого момента кх рвет реляционные бд по скорости аналитических запросов? А когда рвет прочие колоночные бд?

А, с какого момента кх рвет реляционные бд по скорости аналитических запросов? А когда рвет прочие колоночные бд?

Сорри, без шуток, но он это делает с момента установки и запуска

По объему данных. И, кстати, не секрет, что в классических реляционных бд можно сделать партиционирование по дате, значительно уменьшив объём данных, читаемых с диска

Сорри, без шуток, но он это делает с момента установки и запуска

Правда?

Правда?

Истинная :)

То есть, если у меня маленькие аналитические данные, то кх мне тоже подойдет?

"маленькие" условно

То есть, если у меня маленькие аналитические данные, то кх мне тоже подойдет?

Подойдет по скорости

По удобству администрирования -- пока не факт

О, спасибо, всё ясно

инеграцию с графитом поддерживаю обеими руками :)

А есть же. Нужна более глубокая? Что-то специальное подразумевается под "интеграцией"?

А есть же. Нужна более глубокая? Что-то специальное подразумевается под "интеграцией"?

КХ как сторадж для Subj?

КХ как поставщик собственных метрик для Графита -- это уже как я понимаю есть

То есть, если у меня маленькие аналитические данные, то кх мне тоже подойдет?

Кстати, для маленьких данных обещают в следущем году сделать 'кликхаус в командной строке' -- ему можно будет через pipe (|) скармливать файл с форматированными данными и запрос, а он будет возвращать результат.

КХ как сторадж для Subj?

Да. https://github.com/yandex/ClickHouse/blob/master/dbms/include/DB/DataStreams/GraphiteRollupSortedBlockInputStream.h

КХ как сторадж для Subj?

Там на гитхабе уже есть пара проектов которые позволяют писать и читать в графит формате

ох ты ж блин... а как так получилось то??? в клинч встали имеется ввиду 100% disk utilization ?? и ты просто прервал?

не работает оно из сырцов 1) дропнул каталог 2) создал таблицу заново 3) перезалил файл кейс тот же —---— Received exception from server: Code: 57. DB::Exception: Received from localhost:9000, ::1. DB::Exception: Table default.ontime already exists.. 0 rows in set. Elapsed: 0.023 sec. :) SELECT count() FROM ontime ; SELECT count() FROM ontime Ok. 0 rows in set. Elapsed: 0.002 sec. :) SELECT count() FROM ontime ; SELECT count() FROM ontime Exception on client: Code: 32. DB::Exception: Attempt to read after eof: while receiving packet from localhost:9000, ::1 Connecting to localhost:9000. Code: 210. DB::NetException: Connection refused: (localhost:9000, ::1)

clickhouse_ru: Добрый вечер! Сегодня на встрече говорилось о том, что ClickHouse не подходит для финансовых расчетов, причем это мотивировалось, если я верно расслышал, возможной неконсистентностью данных при асинхронной репликации. Все ли я правильно понял?

clickhouse_ru: Добрый вечер! Сегодня на встрече говорилось о том, что ClickHouse не подходит для финансовых расчетов, причем это мотивировалось, если я верно расслышал, возможной неконсистентностью данных при асинхронной репликации. Все ли я правильно понял?

выделенный сервер не решит проблему ?

блин звучит как - считаем быстро но с ошибками |

нет гарантии, т.к. нет транзакций

выделенный сервер не решит проблему ?

Хороший вопрос, я бы тоже хотел понимать: дело только в асинхронной репликации или есть что-то еще, принципиально препятствующее возможности загрузить данные и гарантированно обсчитать их в новом запросе.

clickhouse_ru: Добрый вечер! Сегодня на встрече говорилось о том, что ClickHouse не подходит для финансовых расчетов, причем это мотивировалось, если я верно расслышал, возможной неконсистентностью данных при асинхронной репликации. Все ли я правильно понял?

возможно, мейнтейнеры меня поправят, но насколько понял - да, в данный момент ответ "ОК" не гарантирует консистентность данных

нет синхронной репликации

В этом причина, да.

нет гарантии, т.к. нет транзакций

Да, но в доках написано, что при добавлении данных есть гарантия, что всё либо целиком пройдет, либо ничего не пройдет.

Верно, на уровне этого сервера.

Ну и это немного разные вещи\

Это атомарность

А речь про надежность хранения

Верно, на уровне этого сервера.

Ну, то есть, если я, условно, пренебрегаю репликацией, т.е. сознательно храню все яйца на одном сервере, то всё ок?

Да, всё ОК

нет синхронной репликации

А планируется? Что-то об этом в начале встречи говорилось мельком вроде...

а надо?

а надо?

не плохо бы

а когда запись будет?

а надо?

Для моего use case это очень важно.

Да, планируется

Вроде Лёша говорил же

Будет настройка "хочу записать минимум на n нод"

а что вы там делаете, если не секрет, что нужны одновременно статистические агрегации и гарантии консистентности и на нескольких серверах? :)

ну и при чтении "хочу только точно записанное"

Вроде Лёша говорил же

Во и я припоминаю, только сроки и приоритетность не запомнил.

при сочетании этих двух всё будет надежно на уровне кластера.

не работает оно из сырцов 1) дропнул каталог 2) создал таблицу заново 3) перезалил файл кейс тот же —---— Received exception from server: Code: 57. DB::Exception: Received from localhost:9000, ::1. DB::Exception: Table default.ontime already exists.. 0 rows in set. Elapsed: 0.023 sec. :) SELECT count() FROM ontime ; SELECT count() FROM ontime Ok. 0 rows in set. Elapsed: 0.002 sec. :) SELECT count() FROM ontime ; SELECT count() FROM ontime Exception on client: Code: 32. DB::Exception: Attempt to read after eof: while receiving packet from localhost:9000, ::1 Connecting to localhost:9000. Code: 210. DB::NetException: Connection refused: (localhost:9000, ::1)

из пакета все работает.

По факту фича уже сделана =)

Но там пара минорных багов и немного доработать

а что вы там делаете, если не секрет, что нужны одновременно статистические агрегации и гарантии консистентности и на нескольких серверах? :)

а ВЫ точно уверены что у вас СТОЛЬКО финансовых данных что на одном сервере не уместется ?

По факту фича уже сделана =)

Круто, спасибо!

а ВЫ точно уверены что у вас СТОЛЬКО финансовых данных что на одном сервере не уместется ?

а совмещать данные как? крутить с разных кластеров данные?

при сочетании этих двух всё будет надежно на уровне кластера.

нуу, от split brain-ситуаций так себе гарантия

почему это?

отлично всё будет

а совмещать данные как? крутить с разных кластеров данные?

Финансовые данные привязаны к объектам - объекты не плох шардируются

делаем кластер из трёх

делаем настройку в 2

и никакого split brain

Ну или 5 и настройку на 3

Короче говоря, n/2 + 1

clickhouse_ru: Добрый вечер! Сегодня на встрече говорилось о том, что ClickHouse не подходит для финансовых расчетов, причем это мотивировалось, если я верно расслышал, возможной неконсистентностью данных при асинхронной репликации. Все ли я правильно понял?

Для финансовых расчетов еще нужна управляемая точность и округления. Чтобы давайть грубо погрешность в копейку на миллиарде.

КХ как работает с decimal?

а ВЫ точно уверены что у вас СТОЛЬКО финансовых данных что на одном сервере не уместется ?

Дело не только и не столько в хранении, сколько в желании иметь точную реалтайм онлайн-аналитику.

Короче говоря, n/2 + 1

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

Она не будет считать что она одна

Она просто не отдаст данные