Я на такое наталкивался, пришлось отказаться от прямой вставки. Можно попробовать выгрузить данные в отсортированом виде на диск, а потом с диска их вставить через clickhouse-client

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

ClickHouse как раз использует MVCC. Некоторые свойства транзакций есть в минимальном виде: - вставка каждого блока атомарна и изолирована; - SELECT-ы видят снапшот данных на момент запроса. В случае репликации есть два варианта: - по-умолчанию, асинхронная репликация; - репликация с подтверждением от кворума (настройка insert_quorum). В первом случае вы будете видеть вставленные данные сразу после вставки на той реплике, на которую произведена вставка, а на других - с некоторой задержкой. Во втором случае, есть также возможность включить настройку, которая заставляет читать всегда подтверждённые данные (select_sequential_consistency = 1). Возможно, настройку переименуем, так как ещё не очевидно, какое название лучше подходит.

К сожалению при INSERT INTO table SELECT * FROM table2 данные видны до окончания выполнения запроса, что иногда не очень удобно. Нет ли ручки которую можно покрутить чтоб исправить такое поведение ?

Привет, кто нибудь хранит в кликхаусе деревья и каким шаблоном, таблицей связей?

Не поддерживает ли формат (col1, col2, col3) IN ( (1,2,3) ) wildcard, типа (1, 2, *)?

Не поддерживает ли формат (col1, col2, col3) IN ( (1,2,3) ) wildcard, типа (1, 2, *)?

наверно можно так IN (SELECT id FROM ids)

наверно можно так IN (SELECT id FROM ids)

не так понял вопрос, только так col in () AND col2 IN() ...

у нас оно выставлено, с самим запросом работает (хотя он и так в пямять влазит), а на INSERT оно не влияет

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

Может кто подскажет как на 3 серверах сделать распределенную таблицу с репликацией? Сделал 3 шарды и 2 реплики создал таблицы на нодах так 1 » shard 1 replica 1, shard 2 replica 1 2 » shard 2 replica 1, shard 1 replica 2 1 » shard 2 replica 2, shard 3 replica 2 Поверх этого сделал Распределенную таблицу с rand() в качестве ключа шардирования Как теперь проверить что все поднялось каак мне надо?

К сожалению при INSERT INTO table SELECT * FROM table2 данные видны до окончания выполнения запроса, что иногда не очень удобно. Нет ли ручки которую можно покрутить чтоб исправить такое поведение ?

В целом нет. Есть некоторые ухищрения, но на них рассчитывать не стоит.

Привет, кто нибудь хранит в кликхаусе деревья и каким шаблоном, таблицей связей?

Обычно деревья (регионы, товарные категории) хранятся отдельно и подключаются в виде иерархического словаря.

Не поддерживает ли формат (col1, col2, col3) IN ( (1,2,3) ) wildcard, типа (1, 2, *)?

Не поддерживает.

Может кто подскажет как на 3 серверах сделать распределенную таблицу с репликацией? Сделал 3 шарды и 2 реплики создал таблицы на нодах так 1 » shard 1 replica 1, shard 2 replica 1 2 » shard 2 replica 1, shard 1 replica 2 1 » shard 2 replica 2, shard 3 replica 2 Поверх этого сделал Распределенную таблицу с rand() в качестве ключа шардирования Как теперь проверить что все поднялось каак мне надо?

Посмотрите на тесты в репозитории, там есть пример перекрёстной репликации

спсб

у меня явно что-то не поднялось :) SELECT * FROM system.clusters SELECT * FROM system.clusters Ok. 0 rows in set. Elapsed: 0.001 sec.

https://github.com/yandex/ClickHouse/blob/c90ea346ce9ef51886875b8f3f99c24c6c19c2e0/dbms/tests/integration/test_cross_replication/test.py

спсб, буду разбираться. вопрос по распределенной таблице 1. Читать можно с любого сервера рандомно или только с того где таблицу распределенную создали? 2. Писать рандомно в низлежащие таблицы? А как оно перешардироваться будет или если в качестве ключа rand() то ляжет как положили?

Не поддерживает ли формат (col1, col2, col3) IN ( (1,2,3) ) wildcard, типа (1, 2, *)?

а что он должен делать?

привет, как вы с геоданными работаете в кликхаусе? например, у меня есть широта и долгота и нужно в радиусе n всех найти // пока еще не использую кликхаус

ищем в эллипсе, примерно соответствущему этому кругу в декартовых координатах. pointInEllipses()

спсб, буду разбираться. вопрос по распределенной таблице 1. Читать можно с любого сервера рандомно или только с того где таблицу распределенную создали? 2. Писать рандомно в низлежащие таблицы? А как оно перешардироваться будет или если в качестве ключа rand() то ляжет как положили?

1. Читать нужно из таблицы с движком Distributed. При этом можно создать такую таблицу на каждом сервере (так, чтобы структура кластера совпадала) 2. Писать можно как в Distributed таблицу (тогда нужно указать выражение для шардирования), так и отдельно на каждый шард. Подробнее написано в документации: https://clickhouse.yandex/docs/ru/table_engines/distributed.html

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

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

можно на каждом

круто

спсб

не могу понять почему в кластерах пусто

cat /etc/clickhouse-server/remote_servers.xml <yandex> <remote_servers> <metrics> <shard> <!— Optional. Wheight for writing. Default is 1. —> <weight>1</weight> <!— Optional. Write to only 1 replic?. By default, false - write to all replics. —> <internal_replication>true</internal_replication> <replica> <host>10.1.1.251</host> <port>9000</port> </replica> <replica> <host>10.1.1.86</host> <port>9000</port> </replica> </shard>

SELECT count(*) FROM Measures_Distributed Received exception from server: Code: 170. DB::Exception: Received from localhost:9000, 127.0.0.1. DB::Exception: Requested cluster 'metrics' not found. 0 rows in set. Elapsed: 0.020 sec. :)

SELECT * FROM system.clusters Ok. 0 rows in set. Elapsed: 0.001 sec. :)

сервер рестартовал

Переместите файл remote_servers.xml в /etc/clickhouse-server/conf.d/

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

ура спсб

SELECT * FROM system.clusters ┌─cluster─┬─shard_num─┬─shard_weight─┬─replica_num─┬─host_name──┬─host_address─┬─port─┬─is_local─┬─user────┬─default_database─┐ │ metrics │ 1 │ 1 │ 1 │ 10.1.1.251 │ 10.1.1.251 │ 9000 │ 1 │ default │ │ │ metrics │ 1 │ 1 │ 2 │ 10.1.1.86 │ 10.1.1.86 │ 9000 │ 1 │ default │ │ │ metrics │ 2 │ 1 │ 1 │ 10.1.1.251 │ 10.1.1.251 │ 9000 │ 1 │ default │ │ │ metrics │ 2 │ 1 │ 2 │ 10.1.1.145 │ 10.1.1.145 │ 9000 │ 1 │ default │ │ │ metrics │ 3 │ 1 │ 1 │ 10.1.1.86 │ 10.1.1.86 │ 9000 │ 0 │ default │ │ │ metrics │ 3 │ 1 │ 2 │ 10.1.1.145 │ 10.1.1.145 │ 9000 │ 0 │ default │ │ └─────────┴───────────┴──────────────┴─────────────┴────────────┴──────────────┴──────┴──────────┴─────────┴──────────────────┘ 6 rows in set. Elapsed: 0.004 sec.

Тогда вам нужен не DISTINCT, а LIMIT N BY

Спасибо!

Подскажите, есть 2 сервера конфигурация 2 шарда и 2 реплики - хочу чтобы чтение было с обоих серверов. В таком конфиге ведь чтение не обязательно будет идти с обоих серверов, как задать и возможно ли чтобы чтение было с двух серверов по возможности ? <yandex> <remote_servers> <graphite> <shard> <replica> <host>node1</host> <port>9000</port> </replica> <replica> <host>node2</host> <port>9000</port> </replica> </shard> <shard> <replica> <host>node1</host> <port>9000</port> </replica> <replica> <host>node2</host> <port>9000</port> </replica> </shard> </graphite> </remote_servers> </yandex>

Подскажите, есть 2 сервера конфигурация 2 шарда и 2 реплики - хочу чтобы чтение было с обоих серверов. В таком конфиге ведь чтение не обязательно будет идти с обоих серверов, как задать и возможно ли чтобы чтение было с двух серверов по возможности ? <yandex> <remote_servers> <graphite> <shard> <replica> <host>node1</host> <port>9000</port> </replica> <replica> <host>node2</host> <port>9000</port> </replica> </shard> <shard> <replica> <host>node1</host> <port>9000</port> </replica> <replica> <host>node2</host> <port>9000</port> </replica> </shard> </graphite> </remote_servers> </yandex>

Если читаете из Distributed таблицы, то должно читаться со всех серверов.

А у меня такой вопрос. Вот есть движок ReplacingMergeTree, а есть ли для него Replicated эквивалент? Для всего семейства движков MergeTree кроме Replacing нашёл упоминание в доке

А у меня такой вопрос. Вот есть движок ReplacingMergeTree, а есть ли для него Replicated эквивалент? Для всего семейства движков MergeTree кроме Replacing нашёл упоминание в доке

Есть такой движок

ReplicatedReplacingMergeTree?

так точно

Если читаете из Distributed таблицы, то должно читаться со всех серверов.

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

вроде как есть параметр load_balancing и in_order - не очень понятно как правильно прописать их

Всем привет, используем таблицу ReplicatedReplacingMergeTree для схлопывания строк, и вот интересно, может ли она схлопывать записи с одинаковыми версиями? На практике видим, что не схлопывает, так и задумано? Или это будет меняться?

Всем привет, используем таблицу ReplicatedReplacingMergeTree для схлопывания строк, и вот интересно, может ли она схлопывать записи с одинаковыми версиями? На практике видим, что не схлопывает, так и задумано? Или это будет меняться?

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

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

Наверно по этому и не нужно вставлять одинковые версии. В доке https://clickhouse.yandex/docs/ru/table_engines/replacingmergetree.html#replacingmergetree описано что можно использовать DateTime

Наверно по этому и не нужно вставлять одинковые версии. В доке https://clickhouse.yandex/docs/ru/table_engines/replacingmergetree.html#replacingmergetree описано что можно использовать DateTime

ну, да, вопрос-то был про одинаковые версии :)

Да, испольузем dateTime - но в одну секунду может быть две записи

Подскажите, есть 2 сервера конфигурация 2 шарда и 2 реплики - хочу чтобы чтение было с обоих серверов. В таком конфиге ведь чтение не обязательно будет идти с обоих серверов, как задать и возможно ли чтобы чтение было с двух серверов по возможности ? <yandex> <remote_servers> <graphite> <shard> <replica> <host>node1</host> <port>9000</port> </replica> <replica> <host>node2</host> <port>9000</port> </replica> </shard> <shard> <replica> <host>node1</host> <port>9000</port> </replica> <replica> <host>node2</host> <port>9000</port> </replica> </shard> </graphite> </remote_servers> </yandex>

а как в таком конфиге задатать верные макросы ? делал кто-нибудь ?

Да, испольузем dateTime - но в одну секунду может быть две записи

а миллисекунды?

а миллисекунды?

DateTime - unix timestamp

нет миллисекунд у КХ :(

DateTime - unix timestamp

я имел в виду "записывать ms отдельно"

А куда сюда http://joxi.ru/zANGZyRilwRdZr записывать отдельно? Я бы попробовал заменить DateTime на UInt64 и переводить дату вставки в дату в милисекундах

Если только использовать UInt в качестве версии где оно равно timestamp*1000

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

все, группировать по уникальности только?

UInt64 может такое хранить https://clickhouse.yandex/docs/ru/data_types/int_uint.html#uint Т.е. можно конечно попробовать timestamp*1000 + что-то ещё зависящее от времени или версии строки

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

Подозреваю это не юзер-кейс ReplaceMergeTree и CH вообще

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

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

Нет такого поля

Только если на уровне приложение его генерировать и там же проверять уникальность. Сам CH никак не умеется автоинкреемнтить. Так же не отслеживается уникальность строк по какому-либо полю. Исключение - движки семейства MergeTree - ReplaceMergeTree, CollapsingMergeTree и т.п. Но они не делают в прямом смысле то, что ожидается от уникального поля

ERROR: S client not available

спасибо за подробный ответ

Всем привет, используем таблицу ReplicatedReplacingMergeTree для схлопывания строк, и вот интересно, может ли она схлопывать записи с одинаковыми версиями? На практике видим, что не схлопывает, так и задумано? Или это будет меняться?

Схлопывает же с одинаковыми версиями. Оставляет последнюю запись (видимо из кусочка с большим номером)

Я ловил что не схлопывает только в случае когда в КХ заинсертили всего один раз. Тогда у него всего один чанк, он ничего ни с чем не мерджит, соотвественно и схлопывания одинаковых ключей не происходит

Я ловил что не схлопывает только в случае когда в КХ заинсертили всего один раз. Тогда у него всего один чанк, он ничего ни с чем не мерджит, соотвественно и схлопывания одинаковых ключей не происходит

Т.е. в одном INSERT были одинаковые значения PKEY?

да

красиво, спасибо за информацию!

вроде как есть параметр load_balancing и in_order - не очень понятно как правильно прописать их

Если я правильно понимаю, то нужно указать параметр load_balancing = in_order (в настройках пользователя или через SET) и тогда реплики будут выбираться в порядке перечисления в конфигурационном файле

Т.е. в одном INSERT были одинаковые значения PKEY?

В разных. Просто два раза сделал один и тот запрос и одни и те же данные (в том числе версия тоже)

В разных. Просто два раза сделал один и тот запрос и одни и те же данные (в том числе версия тоже)

можно выполнить optimize table xxx partition 201708 final;

со своим месяцем

можно выполнить optimize table xxx partition 201708 final;

и положить кластер)

В разных. Просто два раза сделал один и тот запрос и одни и те же данные (в том числе версия тоже)

replacing схлопывает версии только при мерже кусков. если есть 2 одинаковых куска, то и в select запросе данные бедут дублироваться. при мерже, если версия совпадет, выберется строка с последней версией.

и положить кластер)

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

Если я правильно понимаю, то нужно указать параметр load_balancing = in_order (в настройках пользователя или через SET) и тогда реплики будут выбираться в порядке перечисления в конфигурационном файле

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

Привет! Есть задача: Хранить в clickhouse как оперативные данные (на серверах с SSD), так и архивные (серваки с HDD). Как это правильно реализовать? Как-то использовать Distributed-движок?

Скажите это нормально? Запросы к 3 локальным таблицам 1 rows in set. Elapsed: 0.381 sec. Processed 3.26 billion rows, 6.51 GB (8.53 billion rows/s., 17.07 GB/s.) 1 rows in set. Elapsed: 0.372 sec. Processed 2.99 billion rows, 5.99 GB (8.05 billion rows/s., 16.11 GB/s.) 1 rows in set. Elapsed: 0.513 sec. Processed 4.18 billion rows, 8.35 GB (8.14 billion rows/s., 16.28 GB/s.) 3.26+2.99+4.18=10.43 Запрос к распределенной 1 rows in set. Elapsed: 1.176 sec. Processed 11.60 billion rows, 23.20 GB (9.86 billion rows/s., 19.73 GB/s.)

10.43 != 11.60

+ Еще один вопрос. backgroung threads поставил в 16 в настройках потому как сластер начал отваливаться с too many parts смотрю в system.merges 0-2 записи, в parts 5000 или 7000 и растет а процессор не загружен почему КХ не мержит в 16 потков в срочном порядке?

один инсерт с множеством VALUES

Я, конечно, не знаю, что такое батчи. Можете ткнуть в меня ссылкой. Но таки получается, что если я буду делать живую аналитику на тыкдоме, то приложенько, которое будет у меня вызывать 20к вставок в секунду, просто положит сервер и всё. А обещалось как раз быстро вставлять. Таки а где ж оптимизатор умный, который будет там складывать, скажем в буфер, а потом вносить данные?

батчи=пачками по 20000 в вашем случае и да есть Buffer в КХ, но лучше делать самому подготовку пачки на стороне приложения по краиней мере документация Buffer не рекомендует почему-то

Ну, скажем, приложенько на пхп так едва ли сможет (готовить пачку). Не все ж могут себе купить чего-нибудь.

Чот яндекс опять наврал.

Ну, скажем, приложенько на пхп так едва ли сможет (готовить пачку). Не все ж могут себе купить чего-нибудь.

Мне кажется надо Buffer.

Тут упомянули ещё какие-то внешние решения, которые собирают батчи, но желания не возникло пробовать. В целом буффер именно для этого.

Вставлял ~500к в секунду.

Помимо того, что вставлять в буфер, ещё удобно вставлять чанками через http

Получается так сказать два буфера , там уже за 3млн переваливает легко.

Это на буфере и простом mergetree

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

Хотя... Я вообще не знаю, зачем писать о чём-то в доке, если есть предупреждение "не использовать"

Я точно не помню, но там вроде были описаны кейсы когда он не рекомендуется.