имелось ввиду "transparent client ip". И, кстати. Какой сакральный смысл в паре in/out usernames? Псевдоучетки, скрывающие реальные?

in-user - пользователь взаимодействующий с chproxy. out-user - это пользователь от имени которго будет выполнен запрос в КХ. В README был пример использования: Suppose we have one ClickHouse user web with read-only permissions and max_concurrent_queries: 4 limit. There are two distinct applications reading from ClickHouse. We may create two distinct in-users with to_user: "web" and max_concurrent_queries: 2 each in order to avoid situation when a single application exhausts all the 4-request limit on the web user.

имелось ввиду "transparent client ip". И, кстати. Какой сакральный смысл в паре in/out usernames? Псевдоучетки, скрывающие реальные?

подразумевается, что chproxy может быть использован как единая точка доступа для КХ. Тогда необходимости в transparent-ip для КХ нет, так как весь контроль доступа будет на chproxy. Доступ к самому КХ можно лимитировать только адресами, где установлен chproxy

@hagen1778 Я так понимаю ты автор :) Отдельное логирование действий в chproxy в отдельный файл можно реализовать? Сюда же и вращение логов по объему, времени, кол-ву. Или это лучше отдельным ПР в гит оформить? В go не силен, но посидев, можно сделать?

@hagen1778 Я так понимаю ты автор :) Отдельное логирование действий в chproxy в отдельный файл можно реализовать? Сюда же и вращение логов по объему, времени, кол-ву. Или это лучше отдельным ПР в гит оформить? В go не силен, но посидев, можно сделать?

Со-автор. Аутпут любого приложения можно писать в файл. Это необязательно реализовывать непосредтсвенно в приложении. Мы использовали supervisor( http://supervisord.org/ ) для всех наших приложений. Он и занимался ротацией логов приложений, а так же их перезапуском в случае падений. Уверен, что существует много альтернатив такому решению.

Со-автор. Аутпут любого приложения можно писать в файл. Это необязательно реализовывать непосредтсвенно в приложении. Мы использовали supervisor( http://supervisord.org/ ) для всех наших приложений. Он и занимался ротацией логов приложений, а так же их перезапуском в случае падений. Уверен, что существует много альтернатив такому решению.

спасибо, потестирую на днях

Привет! Подскажите, стоит ли овчинка выделки? Есть реплики на которых место приходит к концу. Планируем сделать распределенные таблицы. Тут есть 2 выхода. Сделать большой вес на новые сервера, либо разбросать данные со старых серверов для распределения нагрузки на кластер. Большинство запросов делается по свежим данным. Склоняемся пока ко второму варианту, но неужели кто-то заморачивается ребалансировкой данных при каждом добавлении сервера в кластер?

Ребят привет! Подскажите правильно ли я понимаю что для кластера с distributed таблицами нужно как минимум 3 сервера?

или это нужно только для репликаций? а для дистриб можно 2 сервера?

Ребят привет! Подскажите правильно ли я понимаю что для кластера с distributed таблицами нужно как минимум 3 сервера?

Distributed таблицы вроде как могут содержать даже один шард.

Еще один вопрос а права для user в users.xml можно ограничит таблицами или права работают только на базы?

Еще один вопрос а права для user в users.xml можно ограничит таблицами или права работают только на базы?

в доках только про БД сказано

Привет! Подскажите, стоит ли овчинка выделки? Есть реплики на которых место приходит к концу. Планируем сделать распределенные таблицы. Тут есть 2 выхода. Сделать большой вес на новые сервера, либо разбросать данные со старых серверов для распределения нагрузки на кластер. Большинство запросов делается по свежим данным. Склоняемся пока ко второму варианту, но неужели кто-то заморачивается ребалансировкой данных при каждом добавлении сервера в кластер?

Сделать одинаковый вес, а старые партиции просто перекинуть на новые сервера. Тут имеет значение, сколько таблиц, много ли мороки будет. Если пару, то вполне можно и руками все сделать - детач партишн, перекинуть данные, аттач партишн.

Привет ребят, а как можно сравнить 2 даты и поискать записи у которых даты расходяться больше чем на Х секунд/минут/часов/дней?

Привет ребят, а как можно сравнить 2 даты и поискать записи у которых даты расходяться больше чем на Х секунд/минут/часов/дней?

Дата1 минус дата2 = колво дней

А так то в таймстемп можно перевести и будет разница в секундах

toRelativeSecondNum вроде оно?

Функций по датам и времени море, посмотрите в доке

Разница между двумя datetime секунды, кстати, кажется

И переводить не надо

Еще один вопрос а права для user в users.xml можно ограничит таблицами или права работают только на базы?

Только базы

Только базы

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

Привет! Подскажите, стоит ли овчинка выделки? Есть реплики на которых место приходит к концу. Планируем сделать распределенные таблицы. Тут есть 2 выхода. Сделать большой вес на новые сервера, либо разбросать данные со старых серверов для распределения нагрузки на кластер. Большинство запросов делается по свежим данным. Склоняемся пока ко второму варианту, но неужели кто-то заморачивается ребалансировкой данных при каждом добавлении сервера в кластер?

Привет, вы данные сколько храните? Если удаляете со временем то просто пиши в оба и со временем данные сравняются + можно часть партиций перекинуть на новый сервер и освободить место на старом.

хорошо что по акции

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

Там пока все достаточно очень просто сделано в плане проверки прав, по идее штука часто требуемая и, наверное, стоит пилить что-то вроде (https://www.postgresql.org/docs/current/static/sql-grant.html).

А так то в таймстемп можно перевести и будет разница в секундах

toDateTime из Date сделает DateTime

или это нужно только для репликаций? а для дистриб можно 2 сервера?

Репликацию можно и в рамках одного сервера делать, делайте как вам удобнее )

Репликацию можно и в рамках одного сервера делать, делайте как вам удобнее )

distributed table. На двух как я понял.

distributed table. На двух как я понял.

Минимальное количество серверов для DISTRIBUTED - 1 сервер

Минимальное количество серверов для DISTRIBUTED - 1 сервер

да я понял. Минимальное не ненужное для работы))) Если только для тестов.

Привет, вы данные сколько храните? Если удаляете со временем то просто пиши в оба и со временем данные сравняются + можно часть партиций перекинуть на новый сервер и освободить место на старом.

Данные не удаляем. Наверно отцепим партиции шашечками по дням и прицепим к другому шарду.

Данные не удаляем. Наверно отцепим партиции шашечками по дням и прицепим к другому шарду.

Да, можно так

Ребята вопрос такого плана - как вы решаете поиск данных по unixtimestamp? добавляете его в ключ?

Приветствую! Подскажите, пожалуйста, какую схему лучше использовать. У нас 2 типа данных: метрики, которые постоянно накапливаются, которые можно записать в SummingMergeTree, и метрики, которые периодически будут перезаписываться, скорее всего будут записаны в ReplacingMergeTree. Ключи этих двух таблиц пересекаются (есть составной уникальный ключ, одинаковый для обеих таблиц). Мы хотим использовать одну общую таблицу для хранения всех метрик. Скорее всего, для этого также подойдет ReplacingMergeTree. Данные из двух таблиц мержатся несколько раз в час во временную таблицу, после чего копируются в общую таблицу. Но после этого, чтобы получать корректные данные из общей таблицы, нужно делать SELECT с использованием FINAL. Такие запросы выполняются очень долго. Также, после optimize в общей таблице остаются дубликаты. Как можно улучшить эту схему? Использовать для общей таблицы CollapsingMergeTree? Джойнить данные без общей таблицы? Есть лучшее решение?

Приветствую! Подскажите, пожалуйста, какую схему лучше использовать. У нас 2 типа данных: метрики, которые постоянно накапливаются, которые можно записать в SummingMergeTree, и метрики, которые периодически будут перезаписываться, скорее всего будут записаны в ReplacingMergeTree. Ключи этих двух таблиц пересекаются (есть составной уникальный ключ, одинаковый для обеих таблиц). Мы хотим использовать одну общую таблицу для хранения всех метрик. Скорее всего, для этого также подойдет ReplacingMergeTree. Данные из двух таблиц мержатся несколько раз в час во временную таблицу, после чего копируются в общую таблицу. Но после этого, чтобы получать корректные данные из общей таблицы, нужно делать SELECT с использованием FINAL. Такие запросы выполняются очень долго. Также, после optimize в общей таблице остаются дубликаты. Как можно улучшить эту схему? Использовать для общей таблицы CollapsingMergeTree? Джойнить данные без общей таблицы? Есть лучшее решение?

У нас для таких задач используется UNION ALL

а в верхнем заросе, уже выбираются нужные метрики. Только тут есть нюанс. Список колонок должен быть одинаковым. И тут в запросы добавлять toType(0) AS missed_field

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

если цель в экономии места... то тогда да, собирать как то в одну. Но может можно сделать так, если у вас данные перестают обновлятся через час (допустим) то спустя час уже аггрегированные данные копировать в финализирующую таблицу. А все запросы строить поверх "временной" и финальной через юнион. Только из временной выбирать только последний час

потом чистить

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

Добрый день! Хочу перенести data директорию на другой диск

в конфиге нашел вот такое:

<!-- Path to data directory, with trailing slash. --> <path>/mnt/dbdisk/clickhouse/</path>

получается, что надо переносить всю папку из /var/lib?

или можно только data?

Всем доброго дня! Есть такой вопрос: Можно ли вызвать функцию во время инсерта :) insert into flow(dictGetString('GEOIP', 'ASN', tuple(SrcAS))) values(?) Заранее спасибо!

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

Это обычные массивы

Struct Nested ( ID Int64 Value String ) Это Struct.ID Array(Int64) Struct.Value Array(String)

Всем доброго дня! Есть такой вопрос: Можно ли вызвать функцию во время инсерта :) insert into flow(dictGetString('GEOIP', 'ASN', tuple(SrcAS))) values(?) Заранее спасибо!

Пишите во временую таблицу, а потом INSERT INTO T SELECT dictGetString( ... FROM TMP

у меня disk01 и disk02

Что имелось ввиду под "использовать несколько дисков"?

у меня disk01 и disk02

/dev/sdb1 99G 94G 124M 100% /disk01 /dev/sdc1 197G 927M 186G 1% /disk02

disk01 заполнился хочу замаунтить 02

Всем доброго дня! Есть такой вопрос: Можно ли вызвать функцию во время инсерта :) insert into flow(dictGetString('GEOIP', 'ASN', tuple(SrcAS))) values(?) Заранее спасибо!

Можно, но неэффективно, будет работать медленный sql-парсер

выключи кх , перенеси папку /var/lib/clickhouse сделай с новго диска симлинк обратно на папку /var/lib/clickhouse

выключи кх , перенеси папку /var/lib/clickhouse сделай с новго диска симлинк обратно на папку /var/lib/clickhouse

в этом случии будут работать оба диска ?)

нет а зачем вам оба ?

хочу чтобы у меня дисковое пространство было disk01+disk02

ну сделай лвм над ними и обьедени их

лвм это на сколько я знаю на уровне ОС?

но если отвалится один диск вы потеряете все деньги

Для IP какой тип данных лучше подходит?

но если отвалится один диск вы потеряете все деньги

ОК спасибо ))

Для IP какой тип данных лучше подходит?

если форматированным хранить - то лучше String если Ipv4 числом - то Uint32 вполне хватит. для Ipv6 - все-таки String

если форматированным хранить - то лучше String если Ipv4 числом - то Uint32 вполне хватит. для Ipv6 - все-таки String

Спасибо

в подобной схеме: https://www.altinity.com/blog/2018/5/10/circular-replication-cluster-topology-in-clickhouse (3 шарда по 2 реплики на 3х узлах) реально ли каким то образом использовать запросы ON CLUSTER? то же создание таблиц

народ

помоги пожалуйста

на кластере, перенес /var/lib/clickhouse на другой диск

на 3х серверах все запустилось сразу

на последнем не хочет

2018.10.22 14:56:49.466860 [ 10 ] <Error> default.js_requests_local (StorageReplicatedMergeTree, RestartingThread): Couldn't start replication: DB::Exception, DB::Exception: Replica /clickhouse/tables/01/js_requests_local/replicas/01 appears to be already active. If you're sure it's not, try again in a minute or remove znode /clickhouse/tables/01/js_requests_local/replicas/01/is_active manually, stack trace:

и таких сообщений на каждую таблицу

А старый процесс сервера потушен на этой ноде?

Ещё такое бывает, если предыдущий процесс жёстко завершился. Но через полминуты должно пройти.

да

предыдущй процесс был принудительно остановлен

через forcestop

кончилось место на сервере

пришлось тушить КХ, докидывать больший диск, перемещать данные

и не возможно подключится локально к КХ

Code: 210. DB::NetException: Connection refused: (127.0.0.1:9000)

привет . кто может подсказать почему репликация в одну сторону работает

на сервере куда данные не реплицируются. такие ошибки

18.10.22 15:03:22.377107 [ 53 ] {} <Error> InterserverIOHTTPHandler: Code: 221, e.displayText() = DB::Exception: No interserver IO endpoint named DataPartsExchange:/clickhouse/tables/01/p_

2018.10.22 15:03:22.377297 [ 16 ] {} <Error> p_doublegis_ios.event_log (StorageReplicatedMergeTree): DB::StorageReplicatedMergeTree::queueTask()::<lambda(DB::StorageReplicatedMergeTree::LogEntryPtr&)>: Code: 33, e.displayText() = DB::Exception: Cannot read all data. Bytes read: 0. Bytes expected: 8., e.what() = DB::Exception, Stack trace:

версия кликхауса на обоих серверах 18.14.9

зукипер 3.4.9

Он по hostname вашу машину не видит

* скорее всего

именно хостнейм нужен?

я прописал в hosts файл

видят друг друга

но в конфиге днс имена. они другие

Как в докер контейнер подсунуть sql с инициализацией таблиц ? в mysql и postgresql есть папка docker-init.d или что то типо того

У меня docker-compose потому синтаксис ограничен