> А есть возможность на стороне сервера приоретезировать треды сетевых соединений над тредами мержа? Нет.

35 млн. строк в секунду - это на что? На один сервер очень трудно добиться такой скорости.

Это тест на данных оторванных от реальности. Проверяем кто лопнет первым, и ищем куда мы упираемся. Данные генерируются на лету, в единственную UInt8 колонку, жмутся LZ4 в одном event-loop'е и асинхронно отправляются в другом. На целевых данных получается в среднем 12-14 * ( 1024 * 1024) строк на запись в секунду.

Это больше, чем можно получить на более-менее реальных данных при вставке в MergeTree. На стороне сервера скорость выше (в порядке возрастания), если: - вставлять данные, которые оказываются заранее отстортированы по первичному ключу; - вставлять данные не в MergeTree (а например, в Log); - вставлять данные в таблицу типа Null (для тестов).

Основная цель у нас - заточить вставку большого кол-ва данных / сек. Причем структура данных заранее известна, это ID UInt64, timestamp DateTime/UInt32, value Uint64. Cортировка соответственно по timestamp, что в тестах мы стараемся обеспечить, но с виду оно дает прирост только из-за того, что мержи происходят быстрее и не кушают наше CPU. Собственно вот тест с ноутбука, для примера. ? select timestamp, count() from throughput_test group by timestamp order by timestamp SELECT timestamp, count() FROM throughput_test GROUP BY timestamp ORDER BY timestamp ASC ┌──────────── timestamp ─┬──count()─┐ │ 2018-03-22 20:24:29 │ 5242880 │ │ 2018-03-22 20:24:30 │ 5242880 │ │ 2018-03-22 20:24:31 │ 7340032 │ │ 2018-03-22 20:24:32 │ 8388608 │ │ 2018-03-22 20:24:33 │ 8388608 │ │ 2018-03-22 20:24:34 │ 9437184 │ │ 2018-03-22 20:24:35 │ 8388608 │ │ 2018-03-22 20:24:36 │ 10485760 │ │ 2018-03-22 20:24:37 │ 8388608 │ За Null спасибо, в некоторых тестах может пригодиться. Log скорее всего не подойдет, так как все-таки репликация и distributed таблицы нам тоже будут нужны позднее. И не хочется потерять все плюсы работы MergeTree, такие как возможность асинхронной вставки, и параллельной записи/чтения.

Да, Log рекомендуется только для одноразовых, временных данных, или однократно записанных небольших данных.

Скорость приличная, а если нужно дальше - смотрите потребление CPU на обеих сторонах, и на стороне ClickHouse - perf top.

Спасибо, попробую снять perf top под нагрузкой.

Добрый день, как в format TSV получить rows_before_limit_at_least ?

никак, только в JSON и XML

иначе, это нарушит структуру TSV

А если отправить доп хедером для http ?

А если отправить доп хедером для http ?

Было бы здорово, если бы такие характеристики возвращались в заголовках

+1

@milovidov_an а какая выгода от double-conversion по сравнению с glibc printf?

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

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

Приветствую ещё раз. Подскажите, а можно ли как-то дропнуть не одну партицию *MergeTree таблицы, а сразу десяток? Желательно с помощью подзапроса в system.parts.

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

@milovidov_an а какая выгода от double-conversion по сравнению с glibc printf?

Да. Преимущество double-conversion по скорости полностью очевидно. Конкретные цифры попробую найти, но если по памяти - то это многие разы.

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

В своём проекте? double-conversion даёт 100% точный результат, но при этом одновременно и эффективнее и имеет более гибкий интерфейс для настройки того, как выводить.

Приветствую ещё раз. Подскажите, а можно ли как-то дропнуть не одну партицию *MergeTree таблицы, а сразу десяток? Желательно с помощью подзапроса в system.parts.

select arrayStringConcat(arrayMap(x -> toString(x), groupArray(concat('ALTER TABLE DB.TABLE DROP PARTITION ',partition))), '; ') as query from (select partition from system.parts where active and database = 'DB' and table = 'TABLE' group by partition order by partition) clickhouse -n -q "query"

@milovidov_an ага, но у меня там нигде даже точность-то не нужна - 2-4 знака после запятой максимум

но dtoa тормозит :(

Добрый день Получаю ошибку DB::Exception: Size of filter doesn't match size of column.. https://pastebin.com/Vbjc68bU

когда убираю с prewhere блок выборки из словаря - все становится хорошо. Все становится хорошо если так же убрать поле int64_field с блока Select, тогда prewhere и выборка из словаря работает хорошо

Добрый день Получаю ошибку DB::Exception: Size of filter doesn't match size of column.. https://pastebin.com/Vbjc68bU

Известная ошибка в последнем релизе. Исправление уже в master и скоро мы соберём следующий релиз с ним.

Спасибо, а примерно когда ожидать релиз следующий?

Думаю, в понедельник или чуть раньше.

сори.:)

Скажите, а когда появятся бинарные сборки под ClickHouse под arm64?

Скажите, а когда появятся бинарные сборки под ClickHouse под arm64?

Мы не планировали этого делать. Лучше собирать самому.

Очень жаль ?

А ведётся ли вообще поддержка не x86-архитектур?

Народ, всем привет! Подскажите, пожайлуста. С внешними словарями возник вопрос. По определению написано, что словари хранятся в оперативке полностью или частично. Так вот, частично могут хранится только при типе хранения cache? Я правильно понял? Думаю над тем, можно ли сэкономить на оперативке;)

При другом типе хранения могут ли данные частично хранится на диске?

Если вы используете серверы на AArch64 - значит у вас будет много проблем, по сравнению с которыми собрать ClickHouse легко. ClickHouse успешно собирается и работает на AArch64, но полноценного тестирования нет.

Народ, всем привет! Подскажите, пожайлуста. С внешними словарями возник вопрос. По определению написано, что словари хранятся в оперативке полностью или частично. Так вот, частично могут хранится только при типе хранения cache? Я правильно понял? Думаю над тем, можно ли сэкономить на оперативке;)

Да, только словари типа cache (а также complex_key_cache) хранятся в оперативке частично. Остальная часть - во внешней базе данных, которая указана в качестве источника.

Из источника данные в оперативку полностью подгоужаются

Или по частям

При использовании словарей типа cache, данные из источника загружаются по частям.

@milovidov_an https://github.com/yandex/ClickHouse/issues/1697 Алексей, по последнему сообщению можете что-то прокоментировать?

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

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

Посмотрел - это конечно, неожиданное поведение (с чего бы нам рассчитывать на то, что программа начнёт что-то писать до получения входных данных) и это надо доделывать/исправлять.

Всем привет. Подключил словари с mysql, у юзера mysql был пароль с символами "&$" изза этого при попытке подключения к словарю падал clickhouse Exception on client: Code: 32. DB::Exception: Attempt to read after eof: while receiving packet from localhost:9000, 127.0.0.1 Connecting to localhost:9000. Code: 210. DB::NetException: Connection refused: (localhost:9000, 127.0.0.1) Можно как то экранировать эти символы или это баг у clickhouse? Поменяли на пароль без спецсимволов и все нормально работает

стандартное экранирование xml

cdata например

Добрый день, хотел бы задать вопрос про выгрузку большого количества данных по частям. Например, есть один проект на хадупе, и есть данные в CH. Хотелось бы импортировать данные в спарк из обоих систем и там же их использовать. Если я правильно понимаю можно использовать LIMIT offset,max. Будет ли он хорошо работать при больших объёмах данных? Допустим есть распределённая таблица с 1 ТБ данных. Соответственно для выгрузки этого сначала получить количество строк в таблице, а затем выгружать через select рода(числа только для примера) SELECT * from table LIMIT 0,500 SELECT * from table LIMIT 500,500 SELECT * from table LIMIT 1000,500 И так далее. Это будет хорошо работать или плохая идея?=) Если плохая, как можно это реализовать?

тут вроде поднимали вопрос, умеет ли стриминогово отдавать результаты clickhouse-jdbc (чтобы можно было select * from table просто сделать) - https://t.me/clickhouse_ru/46113 - но ответа не последовало, или я пропустил

@lfblue Если таблица разбита на части, например по месяцам, то мб имеет смысл бить на батчи по временному диапазону. Не знаю как конкретно CH но обычная субд при указании большого offset не очень работает

а кто нибудь настраивал ClickHouse на vmware workstation, чтобы по Http порту можно было выполнять запросы из windows хоста? У меня с VirtualBox получилось, а с vmware затык

мне кажется это никак не связано с системой виртуализации

как и с кликхаусом

имеете ввиду что я просто криворукий?)

Ну да, он будет отлично работать на любой виртуализации

Добрый день, хотел бы задать вопрос про выгрузку большого количества данных по частям. Например, есть один проект на хадупе, и есть данные в CH. Хотелось бы импортировать данные в спарк из обоих систем и там же их использовать. Если я правильно понимаю можно использовать LIMIT offset,max. Будет ли он хорошо работать при больших объёмах данных? Допустим есть распределённая таблица с 1 ТБ данных. Соответственно для выгрузки этого сначала получить количество строк в таблице, а затем выгружать через select рода(числа только для примера) SELECT * from table LIMIT 0,500 SELECT * from table LIMIT 500,500 SELECT * from table LIMIT 1000,500 И так далее. Это будет хорошо работать или плохая идея?=) Если плохая, как можно это реализовать?

Нет, так будет плохо работать: чтобы получить LIMIT 1000, 500 - первые 1000 строк тоже читаются. Лучше разбить по партициям или по диапазонам ключа.

012/03/11 13:05:49 -0700 кто нибудь знает как эту строку привести в дататайму на SQL? Нужно через sql среднее время узнать по таким строкам

*2012

parseDateTimeBestEffort(s) Только в свежей версии ClickHouse.

Доброго времени суток, коллеги. Когда имеет смысл использовать словарь, а когда обычный varchar? Самый простой пример, буду засовывать в CH информацию по звонкам. Для примера возьмем направление звонка: Inbound/Outbound. Имеет ли смысл делать словарь для этого поля?

какие +- c точки зрения производительности?

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

а для направления звонка надо UInt8. если вы хотите прямо из базы получать "Inbound", то можно енум, можно словарь

Доброго времени суток, коллеги. Когда имеет смысл использовать словарь, а когда обычный varchar? Самый простой пример, буду засовывать в CH информацию по звонкам. Для примера возьмем направление звонка: Inbound/Outbound. Имеет ли смысл делать словарь для этого поля?

Мы у себя практически все что можно превратить в id вынесли в словари. Банально по скорости и объёмам получается колоссальная выгода и апдейты расшифровок как приятный бонус. В случае с inbound/outbound может вообще стоит enum сделать как советовали выше.

это пример, атрибутов много

про enum соласен в данном случае

Зависит от количества вариантов атрибута. Если их мало, можно и со словарём не заморачиваться, если много то имхо словарь решает.

А если оооочень много относительно доступной памяти на сервере ch, то уже думать. Может словарь типа cache подойдёт. Или джоин с таблицей во внешней базе(если отзывчивость не так важна).

Но если вы например хотите расшифровывать ФИО абонента, а вы работаете в каком нибудь телекоме большой тройки, то словарь для ФИО абонентов не оч Хорошая идея.

Можно узнать почему?

Хочу использовать внешние словари

в mysql/CH, пока не решил. lookup по первичному ключу

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

Спасибо

логично

Основная идея - иметь аналитику. Для детализации можно и подождать

А аналитика будет прямо из базы или в какой то вебмордочке?

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

пока не решил

Я на стадии проeктирования

в первую очердь буду пробывать web мордля для CH, забыл название, был доклад на HighLoad вроде-бы

opensource

tabix?

Да сейчас много всяких работает

да

tabix

А есть какая-то дополнительная информация по GDPR? Я вижу в планах на Q2 но конец Q2 это уже GDPR во всей красе. Есть информация в рассылке, но там довольно хардкорно. Для начинающих пользователей плохо подходит. То есть вопрос будет ли это сделано во время, и как это будет работать и с точки зрения пользователя, ну и ради интереса, какая будет техническая имплементация.

@milovidov_an 'limit' не может работать в 1.1.54370? мы обновляем код, но обнаруживаем, что все «выбрать с лимитом» не удалось, с исключением