name надо было оставить, как есть

Ааа

понял ща попробу

а вместо table, реальное название таблицы да ?

нет

То есть просто выполнить ваш запрос ?

можно дописать where table = ‘...’

ааа

он по всем таблицам выдаст

значит

и сделать sum() от колонок с размером

а потом грепнуть

ща посмотрю

и where active = 1

Привет, в доке тут написано, что при многократной записи одного и того же блока, содержащего одни и те же строки, блок будет записан только один раз. Вот я создал ReplicatedMergeTree с одной репликой, залил тестовые данные (ontime из архива) через clickhouse-client. Потом снова запустил заливку тех же самым данных - таблица продолжила рост. Почему так? xz -v -c -d < ontime.csv.xz | clickhouse-client -d airline -h 192.168.122.107 --max_insert_block_size=200000 --query="INSERT INTO ontime FORMAT CSV"

Друзья, с этим кто-нибудь сталкивался?

ну и самое главное — для некоторых видов данных другая сортировка может дать улучшение сжатия в разы

Друзья, с этим кто-нибудь сталкивался?

Это для последних 100 блоков по умолчанию вроде

ну и самое главное — для некоторых видов данных другая сортировка может дать улучшение сжатия в разы

formatReadableSize(data_compressed_bytes) - это сжатые данные formatReadableSize(data_uncompressed_bytes) - не сжатые верно ?

да

и where active = 1

а эт зачем, это ж columns

а, простите, тогда не надо :))

да

Спасибо, я вижу что сжатие дейстивтельно работает. И результат сжатия составляет от 1.3 до 250 раз в зависимости от столбца

Есть ли тут кто-нибудь, кто использует https://github.com/artpaul/clickhouse-cpp? Какие подводные камни?

я

мне нравится ?

главное date не используйте, а генерируейте в DEFAULT

но можно заставить КХ сбрасывать в своп промежуточный результат. но не могу подобрать соответтвующие значения

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

Добрый....! Кто-нибудь сталкивался после обновления на 18.14.8 с ошибкой на словарях : body: No 'query' in request body? Словари ODBC на разные БД, а ошибка одна. Открывать issue?

CentOS7

Добрый....! Кто-нибудь сталкивался после обновления на 18.14.8 с ошибкой на словарях : body: No 'query' in request body? Словари ODBC на разные БД, а ошибка одна. Открывать issue?

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

проблемы есть, воспроизвел и обошел на Debian. На centos вылезли новые )

Есть ли тут кто-нибудь, кто использует https://github.com/artpaul/clickhouse-cpp? Какие подводные камни?

мы используем. Немного привыкнуть к селекту в лямбде и в целом нормально :)

проблемы есть, воспроизвел и обошел на Debian. На centos вылезли новые )

мы тоже на центосе 7, но дальше первых проблем с ненайденым бинарником не пошли. Ждем обновлений

v18.14.9-stable на гитхабе есть уже, наверно пора собирать

мы тоже на центосе 7, но дальше первых проблем с ненайденым бинарником не пошли. Ждем обновлений

cwd для демона поменять на /usr/bin и "поедет" :)

Вопрос по движку MySQL ------------------------------ на стороне MySQL CREATE TABLE `t` ( `id` int(11) NOT NULL AUTO_INCREMENT, `transaction_id` decimal(30,0) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB insert into t values (1,1),(2,2),(3,3); select * from t; +----+----------------+ | id | transaction_id | +----+----------------+ | 1 | 1 | | 2 | 2 | | 3 | 3 | +----+----------------+ ------------------------------ на стороне КХ CREATE TABLE origin.t ( id Int64, transaction_id decimal(30,0) ) ENGINE = MySQL(....); SELECT * FROM origin.t Received exception from server (version 18.12.14): Code: 50. DB::Exception: Received from localhost:9000, 127.0.0.1. DB::Exception: Unsupported type Decimal(30, 0). Вопрос в том, можно ли в КХ прокинуть со стороны MySQL такой тип данных или нет? сам по себе КХ Decimal(30, 0) поддерживает.

Вопрос по движку MySQL ------------------------------ на стороне MySQL CREATE TABLE `t` ( `id` int(11) NOT NULL AUTO_INCREMENT, `transaction_id` decimal(30,0) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB insert into t values (1,1),(2,2),(3,3); select * from t; +----+----------------+ | id | transaction_id | +----+----------------+ | 1 | 1 | | 2 | 2 | | 3 | 3 | +----+----------------+ ------------------------------ на стороне КХ CREATE TABLE origin.t ( id Int64, transaction_id decimal(30,0) ) ENGINE = MySQL(....); SELECT * FROM origin.t Received exception from server (version 18.12.14): Code: 50. DB::Exception: Received from localhost:9000, 127.0.0.1. DB::Exception: Unsupported type Decimal(30, 0). Вопрос в том, можно ли в КХ прокинуть со стороны MySQL такой тип данных или нет? сам по себе КХ Decimal(30, 0) поддерживает.

Int64 не подходит?

нет, в int64 данные не влезут

нет, в int64 данные не влезут

посмотрел в доке, Decimal описан, КХ предлагает: Set setting allow_experimental_decimal_type = 1 in order to allow it..

allow_experimental_decimal_type = 1 про это в курсе, эта опция включена, без нее КХ не даст создать таблицу с Decimal(30,0)

Посоветуйте, пжл какие выставить настройки по памяти, что бы хватило запросу. на сервере 4Gb ОЗУ, в конфиге спейчас так: max_memory_usage = 3500000000 max_bytes_before_external_group_by = 3000000000 distributed_aggregation_memory_efficient = 1 max_execution_time = 2000 Запрос с group by падает через 2 минуты в: DB::Exception: Memory limit (for query) exceeded: would use 3.31 GiB (attempt to allocate chunk of 134217728 bytes), maximum: 3.26 GiB

попробуйте самый последний стейбл и set_max_block_size = 10000

почти 8 минут ?

отключили сжатие, стало около 4х минут, но все равно медленно и ядро в полку.

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

У кого-то есть история успеха с zstd? Выигрыш по диску 10-15%, но загрузка процессора зашкаливала, не успевали мержится данные при вставке со скоростью 50 тыс./с

Выиграли 30-50%

zstd: 250 Гб -> 180 Гб, вчера вот переливал

Коллеги, через какое примерно время после инсерта в таблицу данные должны появиться в мат-вью, которое смотрит на эту таблицу? Исходная таблица дистрибутед над replicatedmergetree, вьюха просто mergetree. Что-то до вьюхи данные доходят в каких-то рандомных количествах, вьюха с простым where для фильтрации, без группировок или ограничений по датам

я думаю что фиксированного времени нет

Коллеги, через какое примерно время после инсерта в таблицу данные должны появиться в мат-вью, которое смотрит на эту таблицу? Исходная таблица дистрибутед над replicatedmergetree, вьюха просто mergetree. Что-то до вьюхи данные доходят в каких-то рандомных количествах, вьюха с простым where для фильтрации, без группировок или ограничений по датам

Сразу должны

Коллеги, через какое примерно время после инсерта в таблицу данные должны появиться в мат-вью, которое смотрит на эту таблицу? Исходная таблица дистрибутед над replicatedmergetree, вьюха просто mergetree. Что-то до вьюхи данные доходят в каких-то рандомных количествах, вьюха с простым where для фильтрации, без группировок или ограничений по датам

а во вьюху вы тоже смотрите через ее distributed?

нет, вьюха на одной ноде и не дистрибутед

нет, вьюха на одной ноде и не дистрибутед

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

т.е. вьюху надо создавать "над" локальной таблицей?

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

вьюха простой mergetree смотрит на distributedmergetree

проблемы есть, воспроизвел и обошел на Debian. На centos вылезли новые )

Это проявляется при установке из каких пакетов? Возможно, проблема со сборкой rpm пакетов от Altinity?

Это проявляется при установке из каких пакетов? Возможно, проблема со сборкой rpm пакетов от Altinity?

Из них

С Altinity

вьюха простой mergetree смотрит на distributedmergetree

я никогда такое не пробовал, я считал что такое в принципе невозможно и UB. т.е. вот так пробовал (на стейдже) null ---> mv to distributed ---> mv to mergetree

UB ?

undefined behavior

В мануале нет явных указаний на то, что матвью нельзя создавать над distributed таблицей

@milovidov_an Алексей, а движок MySQL в принципе Decimal поля из MySQL не поддерживает?

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

разве побитовых сдвиг вправо ?

а как ?

Чтобы получить адрес сети, зная IP-адрес и маску подсети, необходимо применить к ним операцию поразрядной конъюнкции (логическое И)

(C) википедия

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

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

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

побитовый свиг операции над одним объектом

а or над двумя

В мануале нет явных указаний на то, что матвью нельзя создавать над distributed таблицей

ну и что. Попробовал у меня работает как вы хотите, все что в Distributed на этой ноде вставлял появилось в локальной mv, удивительно.

ну и что. Попробовал у меня работает как вы хотите, все что в Distributed на этой ноде вставлял появилось в локальной mv, удивительно.

тогда наверно все правильно, вставки у меня делаются в "локальные" таблицы (шардирование вручную). буду у себя переделывать логику

тогда наверно все правильно, вставки у меня делаются в "локальные" таблицы (шардирование вручную). буду у себя переделывать логику

ну так сделайте mv на каждой ноде и складывайте локально, смотрите на нее чере дистрибьютид

да, попробую сейчас так, спасибо

да, попробую сейчас так, спасибо

если она нужна целиком на каждой ноде, тогда ее тоже репликейтид но без шардов.

а вот через TSV Reader: err = ch_client.Do(queryString, process_row) ....

я правильно понимаю что tsvreader просто парсер tsv? Причем тут КХ? каким go драйвером вы в КХ ходите?

chclient это и есть драйвер

https://github.com/valyala/chclient

вооот этот

угу, КХ тут оказалось не при чем, запрос напрямую идет за 10 секунд

через либу и TSV парсер - 1-2 минуты ?

а, там http, ну так не должно быть никакой разницы, что curl, что chclient. curl сколько скачивает?

800 мб

я про время

11 секунд

ну ясно, что проблема в самой либе chclient

угумс

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

и я вижу постоянный поток около 40 мегабит до кластера КХ

кроме того, что меня смущает вдвойне, что ядро не в полку ?

кааакой-то странный боттлнек

Ну то есть как бы все в курсе были, да?

Простите

Ошибся