не, это вы наверное с replicated путаете

я пока вижу вариант распарсить show create table . Есть ли проще способ?

не, это вы наверное с replicated путаете

Не понимаю. При создании Distributed вы же указываете название кластера (задается в конфигурации) и таблицы на которую будет "смотреть" Distributed. Ну и соотвественно если пустить DROP ... ON CLUSTER xxx - он должен на всех серверах входящих в этот кластер удалить эту таблицу.

кстати, я тут однажды для внутреннего использования накалякал https://github.com/oxgrouby/logrus-clickhouse-hook может кому-то понадобится, заодно шлите пулл-реквесты

Не понимаю. При создании Distributed вы же указываете название кластера (задается в конфигурации) и таблицы на которую будет "смотреть" Distributed. Ну и соотвественно если пустить DROP ... ON CLUSTER xxx - он должен на всех серверах входящих в этот кластер удалить эту таблицу.

У меня есть название distributed таблицы. Как мне найти таблицы, на которые она смотрит?

ага, теперь понял природу проблемы :)

SHOW CREATE TABLE nametable?

SHOW CREATE TABLE nametable?

замечательно. Можно ли удалить все таблицы, на которую смотрит данная distributed без распаршивания этой команды?

Ну дроп тейбл он кластер

не работает

Я вот делал подобное но по моему пришлось сделать просто на всех серверах просто дроптейбл

вопрос не про "все сервера", а про "все таблицы"

Ну у вас там так много таблиц что ли

одна на самом деле

Ну просто дропните ее

я не хочу парсить show create

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

а в чем проблема создать distributed_schema_version

Ощущение что у вас тысяча серверов и тысячи таблиц и вы не рулите всем через ансибл

а почему бы просто не использовать какую-то простое правило. Например distributed таблица называется так же как локальные таблицы, но с суффиксом _distributed. И тогда не нужно ничего парсить. Просто удалить суффикс.

такой вопрос КХ работает исключительно только под Ubuntu/Debian, или можно под другие дистрибутивы собрать? интересует Alpine

Ну или наоборот - все локальные таблицы с суффиксом _local

а почему бы просто не использовать какую-то простое правило. Например distributed таблица называется так же как локальные таблицы, но с суффиксом _distributed. И тогда не нужно ничего парсить. Просто удалить суффикс.

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

такой вопрос КХ работает исключительно только под Ubuntu/Debian, или можно под другие дистрибутивы собрать? интересует Alpine

можно из исходников собрать

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

ну вам в нее и надо тогда смотреть )))

а почему бы просто не использовать какую-то простое правило. Например distributed таблица называется так же как локальные таблицы, но с суффиксом _distributed. И тогда не нужно ничего парсить. Просто удалить суффикс.

это очень логично, у меня название репл.таблицы с _local, а Distributed без, получается, например, ShowLog и ShowLog_local

Ну или наоборот - все локальные таблицы с суффиксом _local

:)

такой вопрос КХ работает исключительно только под Ubuntu/Debian, или можно под другие дистрибутивы собрать? интересует Alpine

Есть готовые билды для Centos / Fedora и скрипты для билда. Знаю что собирается под FreeBSD и с некоторыми мучениями под MacOS. Теоретически должно собираться под любым относительно свежим Linux. Но обещать что все пойдет сразу как по маслу - не буду.

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

Я заинтригован :) Что это за утилита такая, если не секрет?

Я заинтригован :) Что это за утилита такая, если не секрет?

сорян, nda

Есть готовые билды для Centos / Fedora и скрипты для билда. Знаю что собирается под FreeBSD и с некоторыми мучениями под MacOS. Теоретически должно собираться под любым относительно свежим Linux. Но обещать что все пойдет сразу как по маслу - не буду.

CentOS тут https://packagecloud.io/Altinity/clickhouse

такой вопрос КХ работает исключительно только под Ubuntu/Debian, или можно под другие дистрибутивы собрать? интересует Alpine

ну под alpine можно пробовать собирать но тебе зачем? в докер пихнуть? ну так там здоровенный статический бинарник на выходе, экономии особой не будет

ну под alpine можно пробовать собирать но тебе зачем? в докер пихнуть? ну так там здоровенный статический бинарник на выходе, экономии особой не будет

да в докер там хороший контроль памяти, в Alpine

да в докер там хороший контроль памяти, в Alpine

аллокаторы все равно в Clickhouse будут использоваться свои а не системные которые с libc альпиновской облегченной идут =)

а в чем проблема создать distributed_schema_version

Не проблема. Только получается что миграции для локальных таблиц (если они используются) нельзя смешивать с миграциями для replicated таблиц. Если же в миграциях будешь использовать DDL с ON CLUSTER, тогда schema_version должна быть Distributed.

А кто как DAU/WAU/MAU считает? Положим, в таблицу всего 2 стоблца, (day Date, id String)

select uniq(id) ? :)

ну как правило, это нужно делать эффективно)

например, если делается отображение для графика MAU

то будет таймлайн в, скажем, последних 30 дней

и для каждого нужно посчитать метрику

можно кешировать или писать в другую таблицу то, что уже не поменяется, но я решил узнать, может, есть что-то вроде windowing

ну как правило, это нужно делать эффективно)

Мы как раз в Метрике считаем юников налету, просто с помощью функции uniq.

Ого, круто, спасибо

то есть для графика MAU за последние 10 дней будет 10 uniq по последним 30 дням?

Нет, плавающего MAU не считаем, то есть, если MAU - то график только по месяцам.

то есть для графика MAU за последние 10 дней будет 10 uniq по последним 30 дням?

можно по дням uniqState посчитать, потом дособирать разными окнами, чтобы по данным не ездить лишний раз

можно по дням uniqState посчитать, потом дособирать разными окнами, чтобы по данным не ездить лишний раз

а как окна в кх эмулировать?

Кирилл, ещё про миграции и golang-migrate - задумался сейчас про репликацию. Для реплицируемых таблиц должен быть своя реплицируемая таблица schema_migrations? Так чтобы все реплики "знали" какой они версии?

На самом деле golang-migrate подходит для достаточно простых случаев. Сейчас есть некоторое понимание миграций после некоторого опыта использования КХ "в бою". Мне сейчас более логичным кажутся 2-а варианта что стоит делать: 1) Вариант простой - сделать систему миграций узко заточеную под ClickHouse, но где-то сбоку 2) Сделать систему миграций куда-то совсем близко к КХ, возможно что даже что-то вроде clickhouse-migrate и использовать уже кодовую базу самого КХ - т.е. писать её на C++ опираясь на уже готовый функционал. Второй вариант сейчас мне кажется более предпочтительным хотя бы по тому, что можно в процессе дофиксить функциональность ON CLUSTER (там, насколко я помню, были с некоторыми типами таблиц проблемы), можно хранить информацию по миграциям в томже Zookeeper, не нужно сопровождать отдельную тулзу со своей конфигурацией (меньше шансов на ошибку), можно использовать "конфиги" clickhouse-server (хотя, конечно, это и со совсем сторонней тулзой тоже можно сделать).

можно кешировать или писать в другую таблицу то, что уже не поменяется, но я решил узнать, может, есть что-то вроде windowing

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

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

/stat@combot

combot.org/chat/-1001080295593

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

А как юники считал?

В pg есть hll-extension, может даже hll++. В кх чистый hll соседствуют с классической хэш-таблицей, во время вызова uniq, запускаются оба, вроде как

Доброго времени суток! [ 2272 ] <Error> HTTPHandler: Code: 173, e.displayText() = DB::Exception: Allocator: Cannot malloc 1.00 MiB., errno: 12, strerror: Cannot allocate memory, e.what() = DB::Exception, Stack trace: памяти - 7183/36211MB (used/total)

знакомо кому то? как лечить?

version: 1.1.54318

os: /etc/debian_version -> 8.9

SQL Error [1002]: ClickHouse exception, message: std::exception. Code: 1001, type: std::system_error, e.what() = Resource temporarily unavailable,

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

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

А как юники считал?

да собственно group by id; можно еще countDistinct, но особой разницы не ощутил

На самом деле golang-migrate подходит для достаточно простых случаев. Сейчас есть некоторое понимание миграций после некоторого опыта использования КХ "в бою". Мне сейчас более логичным кажутся 2-а варианта что стоит делать: 1) Вариант простой - сделать систему миграций узко заточеную под ClickHouse, но где-то сбоку 2) Сделать систему миграций куда-то совсем близко к КХ, возможно что даже что-то вроде clickhouse-migrate и использовать уже кодовую базу самого КХ - т.е. писать её на C++ опираясь на уже готовый функционал. Второй вариант сейчас мне кажется более предпочтительным хотя бы по тому, что можно в процессе дофиксить функциональность ON CLUSTER (там, насколко я помню, были с некоторыми типами таблиц проблемы), можно хранить информацию по миграциям в томже Zookeeper, не нужно сопровождать отдельную тулзу со своей конфигурацией (меньше шансов на ошибку), можно использовать "конфиги" clickhouse-server (хотя, конечно, это и со совсем сторонней тулзой тоже можно сделать).

Наверное всё зависит от конкретного сценария использования. У нас в принципе все изменения на продакшн всегда в полуавтоматическом режиме идут, под чутким надзором dba / или программистов. Миграции же сильно помогают на стейджингах / при тестах / ну и чтоб не "потерять" какие-то альтеры при апдейте на продакшн. Насколько я могу судить golang-migrate с этими задачами вроде как должен справляться. Только нужно быть аккуратным с таблицей schema_version - тот TinyLog, который создается по умолчанию по понятным причинам не будет правильно работать в многосерверных конфигурациях (например стейджинг у нас из 2х серверов). Про встроенную поддержку миграций - пока не очень понимаю, как бы это могло работать (ну кроме починки всех вариантов ON CLUSTER DDL, если какие-то не работают).

Наверное всё зависит от конкретного сценария использования. У нас в принципе все изменения на продакшн всегда в полуавтоматическом режиме идут, под чутким надзором dba / или программистов. Миграции же сильно помогают на стейджингах / при тестах / ну и чтоб не "потерять" какие-то альтеры при апдейте на продакшн. Насколько я могу судить golang-migrate с этими задачами вроде как должен справляться. Только нужно быть аккуратным с таблицей schema_version - тот TinyLog, который создается по умолчанию по понятным причинам не будет правильно работать в многосерверных конфигурациях (например стейджинг у нас из 2х серверов). Про встроенную поддержку миграций - пока не очень понимаю, как бы это могло работать (ну кроме починки всех вариантов ON CLUSTER DDL, если какие-то не работают).

TinyLog можно легко заменить, если есть такая необходимость (просто создать таблицу с нужным движком руками). Не совсем встроенную, во-первых - да, нужно починить / перепроверить все варианты с ON CLUSTER, во-вторых - не встроенная, а использующая коловую базу КХ (при этом если оно будет работать как надо и всех будет устраивать её вполне можно запулреквестить чтоб она как и client/copier и т.д. распространялась с самим КХ) там достаточно много всего есть что можно использовать. golang-migrate удобная штука, сейчас я несколько систем миграций смотрю чтоб попробовать "взять" самое удобное из них )

TinyLog можно легко заменить, если есть такая необходимость (просто создать таблицу с нужным движком руками). Не совсем встроенную, во-первых - да, нужно починить / перепроверить все варианты с ON CLUSTER, во-вторых - не встроенная, а использующая коловую базу КХ (при этом если оно будет работать как надо и всех будет устраивать её вполне можно запулреквестить чтоб она как и client/copier и т.д. распространялась с самим КХ) там достаточно много всего есть что можно использовать. golang-migrate удобная штука, сейчас я несколько систем миграций смотрю чтоб попробовать "взять" самое удобное из них )

Про TinyLog - да, я попробовал заменить и вроде бы всё работает. Про "встроенную" - да, я понял, что отдельная утилита на базе основного кода. Просто пока не очень понимаю что она будет делать "дополнительно" / лучше (опыта с миграциями для кх пока большого нет, поэтому пока не понятно какие там подложены грабли). С системами миграций - небольшой плюс в пользу "универсальных" миграций - это то, что оно может работать не только с ClickHouse и при наличии нескольких DBMS может быть удобнее пользоваться одним "универсальным" инструментом для миграций.

Надеюсь Telegram не закроют

Да будет эпичный вариант с техподдержкой, ну сейчас просто в европейском дц у них выключили свет, забавно что они выбирают дц для подключения по номеру телефона, тг с русским номером не подключался, а с тайским работал норм.

забавно что они выбирают дц который можно обесточить

Wolf А как же беспребойники?

забавно что они выбирают дц который можно обесточить

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

Бесперебойники дают пожить минут 10-15 до момента пока ты подашь альтернативное питание.

Есть возможность использовать external, однако иденитфикаторы у меня хранятся на локальной машине, дабы не нагружать трафик и используются многоразово. Если использовать локальный файл через ENGINE File, то придется создавать очень много таблиц, что совсем плохо. Пример из документации не подходит, так как использует НЕ ЛОКАЛЬНЫЙ файл: >curl -F 'passwd=@passwd.tsv;' 'http://localhost:8123/?query=SELECT+shell,+count()+AS+c+FROM+passwd+GROUP+BY+shell+ORDER+BY+c+DESC&passwd_structure=login+String,+unused+String,+uid+UInt16,+gid+UInt16,+comment+String,+home+String,+shell+String' Прошу подсказать, как можно использовать external таблицу при условии, что она находится на локальном диске? Нужно что-то продобное: >SELECT id FROM '/test.tsv'

Есть возможность использовать external, однако иденитфикаторы у меня хранятся на локальной машине, дабы не нагружать трафик и используются многоразово. Если использовать локальный файл через ENGINE File, то придется создавать очень много таблиц, что совсем плохо. Пример из документации не подходит, так как использует НЕ ЛОКАЛЬНЫЙ файл: >curl -F 'passwd=@passwd.tsv;' 'http://localhost:8123/?query=SELECT+shell,+count()+AS+c+FROM+passwd+GROUP+BY+shell+ORDER+BY+c+DESC&passwd_structure=login+String,+unused+String,+uid+UInt16,+gid+UInt16,+comment+String,+home+String,+shell+String' Прошу подсказать, как можно использовать external таблицу при условии, что она находится на локальном диске? Нужно что-то продобное: >SELECT id FROM '/test.tsv'

https://clickhouse.yandex/docs/en/single/#sources-of-external-dictionaries не подойдет?

Есть возможность использовать external, однако иденитфикаторы у меня хранятся на локальной машине, дабы не нагружать трафик и используются многоразово. Если использовать локальный файл через ENGINE File, то придется создавать очень много таблиц, что совсем плохо. Пример из документации не подходит, так как использует НЕ ЛОКАЛЬНЫЙ файл: >curl -F 'passwd=@passwd.tsv;' 'http://localhost:8123/?query=SELECT+shell,+count()+AS+c+FROM+passwd+GROUP+BY+shell+ORDER+BY+c+DESC&passwd_structure=login+String,+unused+String,+uid+UInt16,+gid+UInt16,+comment+String,+home+String,+shell+String' Прошу подсказать, как можно использовать external таблицу при условии, что она находится на локальном диске? Нужно что-то продобное: >SELECT id FROM '/test.tsv'

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

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

Мне надо читать файл полностью. Файлов много, малая часть из них постоянно меняется. Очевидно, если я положу его в табличку, то надо будет таблицу постоянно пересоздавать при небольшом изменении части данных.

Добрый день! Подскажите с таким вопросом. В рекомендациях написано вставлять не по одной записи, а группами. Кто как это реализует? Источник данных один сервис.

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

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

Всем привет, а можно спросить про репликацию и stale состояние?

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

@msBooM источник данных мы направили в redis pub/sub - а после небольшой сервис который слушает редис и каждые Н секунд вставляет в кх

Есть разные способы, проще всего где-то "перед" вставкой собирать данные. Есть https://github.com/nikepan/clickhouse-bulk (не пробовал), есть https://clickhouse.yandex/docs/ru/table_engines/buffer/ (не пробовал, у него есть определенные минусы, читайте доки), ну и кафка конечно.

bulk пару месяцев назад пробовал - у меня он собирал два инсерта в один и всё.

buffer вполне себе работает, но да, есть минусы. Наиболее существенный - в основную таблицу данные попадают с запаздыванием.

подскажите пожалуйста у нас - два шарда - по две реплики в каждом в логах такое <Warning> ClusterProxy::SelectStreamFactory: Local replica of shard 1 is stale (delay: 4565220s.)

по факту в реплике данные норм

А что в system.replication_queue и в system.replicas?

всем привет. Подскажите пожалуйста, как правильно добавлять новые колонки из результатов cселекта той же таблицы. Пробовал так Добавил колонку Array(String) ALTER TABLE nginx_stat ADD COLUMN params_ar Array(String) ; Вставил туда результат запроса той же таблицы INSERT INTO nginx_stat (params_ar) SELECT splitByString('&', RequestParams) FROM nginx_stat ; Все без ошибок ; и тут выяснилось, что все колонки кроме новой — пустые Видимо это связано с ключом, который при вставке я не указывал Но если ключ не уникальный — то это ок вставлять дубликаты ?

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

Правильно так: добавляете колонку с DEFAULT выражением. Для всех новых данных она будет заполняться автоматически, для старых считаться "на лету". Если хотите чтоб для старых данных эта колонка тоже "материализовалась" и была заполнена данными - то только OPTIMIZE FINAL поможет.

Mikhail в replication_queue на одной из реплик test quotes1sec_shared clickhouse-sing-03 8 queue-0000062482 GET_PART 2018-02-04 16:04:27 0 20180204_20180204_46288_51317_2962 [] 0 0 14879 Code: 234, e.displayText() = DB::Exception: No active replica has part 20180204_20180204_46288_51317_2962 or covering part, e.what() = DB::Exception 2018-03-29 12:28:04 0 0000-00-00 00:00:00

таких строк несколько это причина?

/stat@combot