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

хочу заметить, что на другой ноде в этих папках только increment.txt и папка tmp

@milovidov_an поможете разобраться? При заливе в дистрибьютед таблицу - данные сторятся только на той шарде - куда был сделана вставка

Один из файлов повреждён. Перенесите его в сторонку.

Также можно включить синхронную запись: insert_distributed_sync = 1, она проще.

это в конфиге?

В users.xml, в profiles/default.

там в папке 149534 bin файлов

Уберите в сторону все файлы нулевого размера.

Уберите в сторону все файлы нулевого размера.

не вижу таких, все небольшого веса

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

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

то это больщой прецедент, так как это новые данные для статистики

судя по всему у поврежденного файла индекс 55884

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

Да, это значит, что данные не доезжали куда надо.

у последнего 205541

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

Да.

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

либо ноль и пустая строка, либо Nullable типы и null

Эффективнее использовать нули/пустые строки, а не NULL.

пустые строки это как ?

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

при учете того что 0 приемлимое значение а диапазон значений весь uint64 что лучше взять за дефолт ?

Тогда NULL.

а нулл хранится на диске будет ?

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

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

это довольно медленно. примерно 45к строк в секунду

Под каждую строчку не надо делать INSERT. Только пачками.

понятно пачками.

короч нужно делать один инсерт и указывать в нем null

таблица создавалась когда Null еще не было. сейчас ее надо както видоизменять чтобы вставлять с null ?

Да, можно проальтерить. Nullable физически хранится как два составляющих "столбца" - данные и маска NULL-ов. Вместо этого вы можете не использовать Nullable, а завести отдельный столбец типа has_x UInt8.

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

> Nullable физически хранится как два составляющих "столбца"

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

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

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

Да, после сжатия будет примерно одинаково. Но выполнение запроса дороже.

нам немного другое нужно

есть широкие таблицы

мы получаем результаты измерений с разными наборами колонок

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

хотелось бы иметь возможность в формате TSV вместо колонки указать что-то типа \N

типа -- тут нет значения в этой строке, не вставляй его в базу

это не NULL

а просто пропуск аттрибута при записи

типа -- тут нет значения в этой строке, не вставляй его в базу

а как это сочетается с тем что таблица имеет прямоугольную форму?

нет там никакой прямоугольной формы

просто много колонок

условно говоря - есть таблица метрик интерфейсов

там состояния, скорости на вход на выход, ошибки, ну и так далее

по части железа в настройках стоит собирать ошибки, по части - нет

разные комбинации параметров могут быть

хорошо. и как вы это делаете в любой другой базе

мы это уже делаем в CH

insert into columns ... values ...

собираем буферы по уникальным наборам полей

и сбрасываем их

но это не очень батчится. иногда за 30 секунд в части таких наборов получается 10000строк а для другого набора колонок может оказаться их 2 строки. в результате общая скорость не оч.

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

ну вот, скажем, скорости сибираются по 5M интерфейсов, а уровни оптического сигнала - по 10k

эти 10k попадут в отдельный батч

а если писателей несколько - еще и между ними размажутся

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

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

потому что вариант "нет значения - не вставляй его в базу" выглядит немного странно. неприменимость какого-то атрибута к конкретному туплу с некоторой точностью кодируется через null, этого в большинстве случаев достаточно. но кто-то его вставить таки должен, либо через дефолтное значение, либо если вы объединяете несколько разноформатных вставок на клиентской стороне, то через задание его явным образом в запросе.

@milovidov_an спасибо! все нормализовалось, данные равномерно распределились по шардам

PRIMARY ключ в ClickHouse всё равно не позволяет по одной строчке получать нужные значения, для этого нужно загрузить целый блок, и ещё и другие колонки прочитать. Поэтому результат запроса и читается целиком в память при выполнении JOIN. Но ИМХО лучше использовать словари, чем JOIN-таблицы, потому что их нужно каждый раз наполнять при рестарте.

Конечно, меня бы устроило, если бы грузились по блокам. Но JOIN грузит всю таблицу в память. Это 2 ГБ данных. Даже если я делаю JOIN для одной записи. Словари хотел использовать вначале, однако для данной задачи не увидел их преимуществ, они ведь так же полностью хранятся в оперативной памяти? Какие преимущества у словарей перед JOIN-таблицами, если считать, что: - в таблице только ключ-значение - значений больше 100 млн - размер таблицы постоянно увеличивается, хоть и не очень быстро

Конечно, меня бы устроило, если бы грузились по блокам. Но JOIN грузит всю таблицу в память. Это 2 ГБ данных. Даже если я делаю JOIN для одной записи. Словари хотел использовать вначале, однако для данной задачи не увидел их преимуществ, они ведь так же полностью хранятся в оперативной памяти? Какие преимущества у словарей перед JOIN-таблицами, если считать, что: - в таблице только ключ-значение - значений больше 100 млн - размер таблицы постоянно увеличивается, хоть и не очень быстро

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

Конечно, меня бы устроило, если бы грузились по блокам. Но JOIN грузит всю таблицу в память. Это 2 ГБ данных. Даже если я делаю JOIN для одной записи. Словари хотел использовать вначале, однако для данной задачи не увидел их преимуществ, они ведь так же полностью хранятся в оперативной памяти? Какие преимущества у словарей перед JOIN-таблицами, если считать, что: - в таблице только ключ-значение - значений больше 100 млн - размер таблицы постоянно увеличивается, хоть и не очень быстро

Словарь 1 раз загружается в память, тогда как при джоине вы это делаете на каждый запрос

Не сталкивался ли кто-нибудь с такой проблемой: При относительно частых (1-2 с екунду) небольших batch insert-ах, отваливается zookeeper, с вот такой ошибкой: Feb 12 13:52:45 site2-deac-dwh-cas1 supervisord[22997]: zookeeper 2018-02-12 13:52:45,073 [myid:1] - ERROR [LearnerHandler-/10.100.20.22:57990:LearnerHandler@648] - Unexpected exception causing shutdown while sock still open Ну и конечно следующий insert в базу тоже валится (но это, как я понимаю, результат отсутствия зоокипера): ClickHouseDB\DatabaseException: Cannot allocate block number in ZooKeeper: zkutil::KeeperException: connection loss Затем всё поднимается и продолжает работать, но осадочек то остался :( Куда посмотреть? UPD: Проблема решилась, виновато было ядро и глюки сетевой карты в результате. Со свежим ядром всё заработало прекрасно.

Конечно, меня бы устроило, если бы грузились по блокам. Но JOIN грузит всю таблицу в память. Это 2 ГБ данных. Даже если я делаю JOIN для одной записи. Словари хотел использовать вначале, однако для данной задачи не увидел их преимуществ, они ведь так же полностью хранятся в оперативной памяти? Какие преимущества у словарей перед JOIN-таблицами, если считать, что: - в таблице только ключ-значение - значений больше 100 млн - размер таблицы постоянно увеличивается, хоть и не очень быстро

А почему вы не хотите в join задать условия в where? Чтобы не вся таблица грузилась

А почему вы не хотите в join задать условия в where? Чтобы не вся таблица грузилась

Хочу, я не понимаю как это сделать. id без WHERE оределяется 1 к 1. Сейчас часть с JOIN выглядит так: >ANY INNER JOIN urls2 USING id

Хочу, я не понимаю как это сделать. id без WHERE оределяется 1 к 1. Сейчас часть с JOIN выглядит так: >ANY INNER JOIN urls2 USING id

Пишите вместо urls2 селект-запрос в скобочках

Пишите вместо urls2 селект-запрос в скобочках

Имеете ввиду без JOIN?

Имеется в виду как я написал

Имеется в виду как я написал

Спасибо. >ANY INNER JOIN (SELECT id, url FROM urls2 WHERE id = url_id) USING id

Any inner join (select id, count() as shows from urls2 where day =today) using (id)

Group by там еще забыл, но это на ваше усмотрение

Any inner join (select id, count() as shows from urls2 where day =today) using (id)

У меня только id (без приявязки к дате)

Имеется в виду как я написал

Как в подзапросе сделать условие на колонку из внешней таблицы? Это вообще возможно?

Через словарь и getDict?

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

Коллеги, подскажите какой максимально размер таблицы в Кб(Мб,Гб & etc) в ClickHouse?

И в столбцах

Если вообще есть такое ограничение в пределах UInt16

речь не про количество столбцов

Про них тоже неплохо бы...

про количество столбцов гуглится

интересует какой максимальный размер таблицы в Мб в ClickHouse

На сколько диска хватит, дальше distributed и масштабироваться серверами

Угу. Сообщение в списке рассылки полуторагодовой давности. С тех пор много версий поменялось.

Еще для индексов память нужна, тоже есть шанс напоротся, но тоже постараться надо

И что нужно сделать, чтоб напороться?