с некоторых пор есть (не в стабильной версии), но такие себе там какая-то проблема в jdbc-драйвере вроде была с этим связанная. клиент пихает нуллы, а драйвер пытается их же и пробросить

ок

хотя сделать, что если float32 равно 0, то ничего не добавляется, чтобы место сэкономить

Место с помощью NULL не сэкономится.

а ну тогда все проще)

спасибо

и париться не буду

а чем вы мониторите кликхаус?

Всем привет! У нас на одном из серверов в логах ошибка:

DistributedSessions.Distributed.DirectoryMonitor: Code: 32, e.displayText() = DB::Exception: Attempt to read after eof, e.what() = DB::Exception, Stack trace: 0. clickhouse-server(StackTrace::StackTrace()+0xe) [0xfd8d0e] 1. clickhouse-server(DB::Exception::Exception(std::string const&, int)+0x1e) [0xf9c69e] 2. clickhouse-server(DB::throwReadAfterEOF()+0x3a) [0xf9c86a] 3. clickhouse-server(DB::StorageDistributed::DirectoryMonitor::processFile(std::string const&)+0x7c9) [0x23f4759] 4. clickhouse-server(DB::StorageDistributed::DirectoryMonitor::run()+0x15d) [0x23f501d] 5. clickhouse-server(execute_native_thread_routine+0x20) [0x32a3300] 6. /lib/x86_64-linux-gnu/libpthread.so.0(+0x8184) [0x7ff7579c6184] 7. /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7ff756fe137d]

На остальных все норм. Как нам побороть эту ошибку?

Заканчивалось место на диске?

а чем вы мониторите кликхаус?

Есть встроенная поддержка Graphite для отправки метрик, а также экспортеры в Prometheus, munin и куда-то ещё.

На остальных все норм. Как нам побороть эту ошибку?

Зайти в директорию этой Distributed-таблицы: /opt/clickhouse/database/table/. Найти там первый (обрезанный) файл и перенести его куда-нибудь оттуда.

Есть встроенная поддержка Graphite для отправки метрик, а также экспортеры в Prometheus, munin и куда-то ещё.

а для жаглера нет?:)

Для Жаглера спроси у наших, например, у velom@.

Alexey Как определить обрезанный файл?

Это первый по номеру. Все файлы отправляются по порядку.

А не подскажете, насколько много данных за раз можно слать POST-запросом по HTTP API ClickHouse?

А не подскажете, насколько много данных за раз можно слать POST-запросом по HTTP API ClickHouse?

сколько угодно

Раздел руководства "Производительность при вставке данных." » Данные рекомендуется вставлять пачками не менее 1000 строк или не более одного запроса в секунду. Подскажите, эти рекомендации относятся к таблице или целиком ко всему инстанцу clh?

Такой вопрос: хочется и чтобы данные реплицировались, и чтобы при вставке одинаковых строк данные не дублировались и оставался один экземпляр. Нет ли какого-нибудь незадокументированного ReplicatedReplacingMergeTree-движка?) И можно ли такого как-нибудь достичь в принципе?

ахахах

Рили лол)) Сейчас посмотрю, работает ли :D

вообще этого можно достичь еще с помощью временной (промежуточной) таблицы. сначала залить туда данные, потом сделать INSERT INTO table SELECT * FROM temp_table WHERE id NOT IN (SELECT id FROM table)

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

(хотя, в таком случае можно создавать таблицы с рандомными именами)

Работает корректно)

Вот ребята скромные, делают всякие крутости, но не рассказывают об этом на каждом углу) Следующий вопрос: насколько это стабильно и как скажется на производительности?

вообще этого можно достичь еще с помощью временной (промежуточной) таблицы. сначала залить туда данные, потом сделать INSERT INTO table SELECT * FROM temp_table WHERE id NOT IN (SELECT id FROM table)

К сожалению, совсем не прод вариант, хотелось бы вот как ReplicatedReplacingMergeTree)

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

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

https://groups.google.com/forum/#!searchin/clickhouse/update|sort:relevance/clickhouse/jYwoyPblsk8/KSE7S8tvAQAJ

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

а зачем нужен FINAL? Вроде как и без него работает корректно

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

Да, по-моему так

final просит доделать все мерджи

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

эээ > мержи происходят по крону вы отдельно из крона дергаете optimize table что ли?

"мержи", которые имеются в виду - это внутренний процесс склейки файлов-блоков

Не не, в принципе же так устроено, нет?

Да, я про них и говорю

Если они происходят только при вставке, а потом никаких склеек нет, то вариант с "подождать" в принципе должен работать нормально

А этот ReplacingMergeTree не мержится автоматически? Только по FINAL или OPTIMIZE?

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

А разве нельзя, как и с CollapsingMergeTree _сразу_ после вставки делать запросы, используя sign?

Просто не очень понятно, в чём Replacing хуже Collapsing в итоге

Или collapsing всегда мержится перед запросом?

Просто Replacing было бы очень соблазнительно использовать, если я правильно понимаю как он работает. Поскольку для Collapsing желательно использовать отдельный внешний KV storage, а в Replacing получается, что старые строки просто заменяются на новые

не заменяются, добавляются новые. просто там либо столбец версии добавляется (аналогично sign в collapsing merge tree), либо берется последняя строка с таким же PK ну в смысле заменяются, но после мерджа! (так же, как коллапсинг)

Кстати, а при any inner join выбирается последняя версия или произвольная?

Раздел руководства "Производительность при вставке данных." » Данные рекомендуется вставлять пачками не менее 1000 строк или не более одного запроса в секунду. Подскажите, эти рекомендации относятся к таблице или целиком ко всему инстанцу clh?

Рекомендации относятся к таблице. Но при этом на весь инстанс тоже желательно не сильно частые INSERT-ы делать. Может быть, в районе десятков пачек в секунду...

Если они происходят только при вставке, а потом никаких склеек нет, то вариант с "подождать" в принципе должен работать нормально

Нет, потому что слияния разных кусков делаются с разной частотой. Так, мелкие куски сливаются вместе часто, большие редко (до времён порядка месяца). Очень большие куски (по-умолчанию, 100 GB) вообще не сливаются. Строки с одним ключом могут оказаться в двух больших кусках.

мне от интересно, возможно ли быстро слить с influxdb в CH данные за год метрик несколько десяток машин (данных там на ~20гб).....

Кстати, а при any inner join выбирается последняя версия или произвольная?

Выбирается первая попавшаяся. Какая будет первой попавшейся - трудно сказать, так как это зависит от распределения работы по потокам.

Нет, потому что слияния разных кусков делаются с разной частотой. Так, мелкие куски сливаются вместе часто, большие редко (до времён порядка месяца). Очень большие куски (по-умолчанию, 100 GB) вообще не сливаются. Строки с одним ключом могут оказаться в двух больших кусках.

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

мне от интересно, возможно ли быстро слить с influxdb в CH данные за год метрик несколько десяток машин (данных там на ~20гб).....

у меня 20 гб логов с объектами json парсятся питончиком и заливаются в КХ где-то за час-полтора (шесть потоков, mbpr 15") не инфлюкс, конечно, но мало ли

у меня 20 гб логов с объектами json парсятся питончиком и заливаются в КХ где-то за час-полтора (шесть потоков, mbpr 15") не инфлюкс, конечно, но мало ли

инфлюкс сильно втыкает при массовых выборках..... :(

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

Нет. Стоит иметь ввиду, что вариант Игоря работает так: при каждой вставке делается full scan таблицы. Часто это неприемлимо. Может подойти только для маленьких объёмов.

ну кстати я избежал full scan'а (если я правильно понял), делая SELECT min(timestamp), max(timestamp) FROM temp_table а потом делая INSERT INTO table SELECT .. FROM temp_table WHERE id NOT IN (SELECT id FROM table WHERE date BETWEEN toDate(<min_timestamp>) AND toDate(<max_timestamp>))

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

а по конкретным дате-времени

Нет. Стоит иметь ввиду, что вариант Игоря работает так: при каждой вставке делается full scan таблицы. Часто это неприемлимо. Может подойти только для маленьких объёмов.

Хорошо, а если мы закладываемся, что дубли могут быть, но хочется хотя бы уменьшить занимаемое место на диске, т.е. чтобы хотя бы часть (я так понимаю это большая) схлопывалась и у нас есть 1 час на мерж (выгрузка происходит ночью), является ли такой вариант боевым или все таки не стоит?

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

Таблица большая, 60 млрд. и каждую неделю выгружается по 150-160 млн.

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

и timestamp'у, если он в индексе прям за датой стоит, или близко к ней (но опять же, могу ошибаться)

Рекомендации относятся к таблице. Но при этом на весь инстанс тоже желательно не сильно частые INSERT-ы делать. Может быть, в районе десятков пачек в секунду...

Алексей, спасибо!

но да, признаю, объемы у меня небольшие, где-то 5-10кк строк в сутки

Хорошо, а если мы закладываемся, что дубли могут быть, но хочется хотя бы уменьшить занимаемое место на диске, т.е. чтобы хотя бы часть (я так понимаю это большая) схлопывалась и у нас есть 1 час на мерж (выгрузка происходит ночью), является ли такой вариант боевым или все таки не стоит?

После нескольких быстрых мержей, дублей уже будет мало.

Мои 5 коп. Если данные грузятся пакетами, а обычно так и бывает, то назначайте идентификатор пакета и проверяйте, что он уже загружен (не id отдельной записи, а id всего пакета). Накладные расходы невелики. Дополнительно можно ограничить по дате. Это подходит для больших таблиц (условно -- фактов). Для небольших, проверка уникальности id недорога, и можно на всякий случай делать иногда optimize, если загрузка может происходить с разных серверов.

После нескольких быстрых мержей, дублей уже будет мало.

Отлично, т.е. при фильтровать я планирую это дело все равно DISTINCT-ом для полного устранения дублей (если из-за этого не будет сильно просидать производительность), а это будет чисто в качестве очистки места. Алексей, а репликация будет происходит корректно? Я так понимаю, будет все равно некоторое расхождение

Мои 5 коп. Если данные грузятся пакетами, а обычно так и бывает, то назначайте идентификатор пакета и проверяйте, что он уже загружен (не id отдельной записи, а id всего пакета). Накладные расходы невелики. Дополнительно можно ограничить по дате. Это подходит для больших таблиц (условно -- фактов). Для небольших, проверка уникальности id недорога, и можно на всякий случай делать иногда optimize, если загрузка может происходить с разных серверов.

Спасибо, поиграюсь с разными вариантами

Посмотрю, как это отразится на времени выгрузки на нормальных объемах

Отлично, т.е. при фильтровать я планирую это дело все равно DISTINCT-ом для полного устранения дублей (если из-за этого не будет сильно просидать производительность), а это будет чисто в качестве очистки места. Алексей, а репликация будет происходит корректно? Я так понимаю, будет все равно некоторое расхождение

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

Что-то меня переклинило, решил, что на оригинале и реплике слияния будут происходить независимо.. Ок, всем спасибо!

Слияния координируются и происходят одинаковым образом. Данные на репликах будут одинаковы побайтово.

планирую писать в кластер CH около 20к значений в секунду на 6 серверах (3 шарда 2 реплики в 2 датацентрах) собственно вопрос - потянет ли http интерфейс такую нагрузку, если писатся будет пачками раз в секунду(константа) на всех нодах? и потянет ли рост нагрузки в 10х?

планирую писать в кластер CH около 20к значений в секунду на 6 серверах (3 шарда 2 реплики в 2 датацентрах) собственно вопрос - потянет ли http интерфейс такую нагрузку, если писатся будет пачками раз в секунду(константа) на всех нодах? и потянет ли рост нагрузки в 10х?

если пачками, то и 20к и 200к - не очень много.

https://habrahabr.ru/company/smi2/blog/317682/

Кстати, с сегодняшнего дня по пятое января в clickhouse-client будет пасхалка :3

будет не верно считать? чтобы народ отдыхал в НГ? ?

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

https://habrahabr.ru/company/smi2/blog/317682/

Ответьте пожалуйста на опрос) мне важно мнение сообщества

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

Игорь, спасибо за статью!

Не читал, но одобряю :)

Ещё не читал, позже

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

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

РНР большими буквами вроде как Ремотно Наладочные Работы ?

РНР большими буквами вроде как Ремотно Наладочные Работы ?

personal home page

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

да тоже думали над этим, разбить или вообще не писать про php оставить только sql - create table. что бы "не отвечать" а почему вы используете .х.. и не сделали на Asm или просто на C))) но хотелось поделится идеей и тулом с сообществом и статья больше была написана с "конца"

Да я без наезда, полно сайтов на PHP и людей, которые им пользуются, поэтому утилиты, наверняка, полезные.

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

а это нам только предстоит , и я как раз помня о вашем опыте буду "пытать" )