я что-то запутался))

я выше написал.

я выше написал.

пишет no data insert

cat banner_history_segments_data.native | clickhouse-compressor -d | clickhouse-client —user="default" —password="" —database="statistics" —query="INSERT INTO banner_history_segments FORMAT Native"

Всё верно, я к тому, что clickhouse-compressor -d data.compressed не сработает.

Алексей поясните пожалуйста почему падает сервер от это выгрузки и что в команде не так? падает если слать через POST на localhost c опцией декомпрессии

Сервер может упасть, если не хватает оперативной памяти.

Сервер может упасть, если не хватает оперативной памяти.

8 гигов мало для выгрузки 120 млн строк?

а если не хватает оперативки, надо слать кусочками поменьше

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

просто импорт тогда мне придется переписывать слать запросы limit offset и выбирать чанками по 10 млн. думал может есть способ(

ладно память но процессор сходит с ума

Это предположение - подтвердить можно, проверив dmesg.

2 vCPUs, 2.4 GHz, Intel Xeon Family, 8 GiB memory

это мало для импорта данных ?

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

Процессор загружен, потому что ClickHouse использует ресурсы машины на полную :)

Давайте сначала убедимся, что действительно памяти не хватает. Проверьте dmesg.

памяти хватает. но в притык занято 7 гб из 8 при импорте. но load average дошел до 6 и я уже даже select не смог выполнить он просто подвис. я остановил импорт. может можно как-то ограничить во время импорта процессор. я пользовался утилитой cpulimit и она хорошо справлялась. импорт довел до 0.4 average в спокойном режиме выгружать данные и кладет в облако. а вот с экспортом беда 1) я так и не понял какой командой можно кинуть файл на декомпрессию - у меня пишет no data insert 2) при импорте вылазит demon и жрет весь проц пока не завершится процесс что ограничивать не понятно .. импорт делать планируется ежедневно на тестовый сервер для отладки на свежих данных

no data insert - а какое в точности сообщение об ошибке?

Code: 108. DB::Exception: No data to insert

Проверил, вот так работает: $ clickhouse-client --query 'SELECT * FROM test FORMAT Native' | clickhouse-compressor > test.compressed $ cat test.compressed | clickhouse-compressor -d | clickhouse-client --query 'INSERT INTO test FORMAT Native'

No data to insert может быть, если действительно в файле нет данных - 0 строк

No data to insert может быть, если действительно в файле нет данных - 0 строк

вы правы не понятно как файл очистился.. я другой проверил работает. оперативку "не жрет" у меня сейчас занято около 800 мб - 1.3 Г

но сервак пыжится )

ну вы ж не будете такие объемы ежесекундно грузить?

раз в сутки ночью. дальше еще больше объемы будут

ну вот. а ночью часто select запросы нужны бывают?

каждую секунду

лан((

у нас данные запрашиваются и в кеш кладутся

агрегированные

кеш для ui - отдельный сервер. но запросы слаться будут при каждом сборе новых данных для кеша

у меня есть еще одна идея

сейчас подожду пока сервак отдохнет и добавлю ему cpulimit

выставлю на выполнение команды 10% cpu может будет норм если раз в сутки

Сейчас действительно тонкое разделение ресурсов между запросами проблематично. Будем исправлять.

Сейчас действительно тонкое разделение ресурсов между запросами проблематично. Будем исправлять.

круто если бы вы сделали аналог mysqldump утилиты для выгрузки всей базы или отдельной таблиц

Сейчас действительно тонкое разделение ресурсов между запросами проблематично. Будем исправлять.

и чтобы она выполнялась с каким-то своим приоритетом выставляемый опцией

или например реализовать выполнение в docker котейнере

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

может я ошибаюсь в чем-то. так мысли. но было бы круто)

Сейчас в запросах с несколькими фильтрами ClickHouse автоматически переносит некоторые фильтры в prewhere. Иногда он это делает неправильно, что приводит к увеличению времени выполнения запроса. (мы наблюдали, когда ошибочный перенос в prewhere увеличивал время выполнения с полутора до трех минут). Вопрос: какие эвристики используются для определения, когда имеет смысл переносить условие в prewhere, а когда нет? Предложение: было бы полезно добавить хинты, чтобы подсказывать КликХаусу, что можно переносить в prewhere, а что лучше не надо.

сейчас подожду пока сервак отдохнет и добавлю ему cpulimit

сильно не помогло. клиент то особо не грузит проц. удалось не превышать load average больше 2.4 а для двух ядерного cpu эти 0.4 это уже очередь операций то есть подвисания. Тут больше cllickhouse —daemon кушает проц. его не знаю как ограничить только для операции импорта

круто если бы вы сделали аналог mysqldump утилиты для выгрузки всей базы или отдельной таблиц

Можно ведь делать ALTER TABLE %s.%s FREEZE PARTITION '2'. Тогда зафризятся все партишены нашего тысячелетия

Можно ведь делать ALTER TABLE %s.%s FREEZE PARTITION '2'. Тогда зафризятся все партишены нашего тысячелетия

и тогда будет сотни файликов?)

сильно не помогло. клиент то особо не грузит проц. удалось не превышать load average больше 2.4 а для двух ядерного cpu эти 0.4 это уже очередь операций то есть подвисания. Тут больше cllickhouse —daemon кушает проц. его не знаю как ограничить только для операции импорта

я ошибся. уже load average больше 3 стал(( видимо единственное решение это разбить файл на чанки и грузить маленькими частями с командой sleep чтобы не дать подвиснуть

и тогда будет сотни файликов?)

нет, тогда в /<clickhouse_data_folder>/shadow/<version>/data/<db>/table лежать ваша таблица

партиции можно легко аттачить и детачить

нет, тогда в /<clickhouse_data_folder>/shadow/<version>/data/<db>/table лежать ваша таблица

надо попробовать

партиции можно легко аттачить и детачить

не сказал бы что легко)) ALTER TABLE statistics.audience_statistic_segments FREEZE PARTITION '2' ALTER TABLE statistics.audience_statistic_segments ATTACH PARTITION - тут name месяца указывается? а нельзя все кусочки влить в базу ?

ATTACH PARTITION '2'...

ALTER TABLE statistics.audience_statistic_segments ATTACH PARTITION '2' Received exception from server: Code: 248. DB::Exception: Received from localhost:9000, 127.0.0.1. DB::Exception: Invalid partition format: 2. Partition should consist of 6 digits: YYYYMM.

значит нельзя(

Проверил, вот так работает: $ clickhouse-client --query 'SELECT * FROM test FORMAT Native' | clickhouse-compressor > test.compressed $ cat test.compressed | clickhouse-compressor -d | clickhouse-client --query 'INSERT INTO test FORMAT Native'

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

что-то с первого раза вышло. а сейчас даже не остановить этот процесс

Максим, если не секрет, над каким проектом вы работаете? Какая компания, для чего будете использовать ClickHouse?

Максим, если не секрет, над каким проектом вы работаете? Какая компания, для чего будете использовать ClickHouse?

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

Максим, если не секрет, над каким проектом вы работаете? Какая компания, для чего будете использовать ClickHouse?

а что я уже всем надоел?))

Просто интересно.

у нас довольно большие объёмы данных статистики. кратко реклама

показы клики и т.д.

сильно не помогло. клиент то особо не грузит проц. удалось не превышать load average больше 2.4 а для двух ядерного cpu эти 0.4 это уже очередь операций то есть подвисания. Тут больше cllickhouse —daemon кушает проц. его не знаю как ограничить только для операции импорта

После вставки данных, в фоне выполняются слияния. Слияния могут использовать достаточно большое количество потоков, каждый из которых, как правило, упирается в CPU или в диск. Максимальное количество потоков для слияния определяется настройкой background_pool_size, которую можно изменить в users.xml в профиле default. По-умолчанию - 16. Впрочем, столь большое количество потоков используется редко. Сильно уменьшать этот параметр нельзя, так как тогда не смогут работать одновременно мелкие и крупные слияния, и вставка будет замедляться. Разумный минимум, в который можно выставить эту настройку - 4. Планировщик ОС устроен так, что если даже количество потоков, ожидающих CPU, в несколько раз превышает количество ядер, система не будет "залипать" на существенное время (секунды) при операциях типа работы по ssh. Залипания на существенное время могут возникать из-за ожидания диска. Виртуалка с двумя ядрами не является достаточно серьёзной для продакшена. Также стоит заметить, что часто у виртуалок очень слабая дисковая подсистема, и к тому же, диски могут быть перегружены соседями (мы наблюдали такое часто для виртуалок в OpenStack). Можно надеяться, что вы будете использовать более серьёзные машины для продакшен нагрузки. Чтобы проверить, почему тормозит ваша виртуалка, выведите куда-нибудь графики утилизации CPU, диска, сети...

После вставки данных, в фоне выполняются слияния. Слияния могут использовать достаточно большое количество потоков, каждый из которых, как правило, упирается в CPU или в диск. Максимальное количество потоков для слияния определяется настройкой background_pool_size, которую можно изменить в users.xml в профиле default. По-умолчанию - 16. Впрочем, столь большое количество потоков используется редко. Сильно уменьшать этот параметр нельзя, так как тогда не смогут работать одновременно мелкие и крупные слияния, и вставка будет замедляться. Разумный минимум, в который можно выставить эту настройку - 4. Планировщик ОС устроен так, что если даже количество потоков, ожидающих CPU, в несколько раз превышает количество ядер, система не будет "залипать" на существенное время (секунды) при операциях типа работы по ssh. Залипания на существенное время могут возникать из-за ожидания диска. Виртуалка с двумя ядрами не является достаточно серьёзной для продакшена. Также стоит заметить, что часто у виртуалок очень слабая дисковая подсистема, и к тому же, диски могут быть перегружены соседями (мы наблюдали такое часто для виртуалок в OpenStack). Можно надеяться, что вы будете использовать более серьёзные машины для продакшен нагрузки. Чтобы проверить, почему тормозит ваша виртуалка, выведите куда-нибудь графики утилизации CPU, диска, сети...

Алексей спасибо за развернутый ответ. реальную нагрузку на продакшене пока не проверяли. я делаю последние штрихи по бэкапированию данных в облако amazon s3 и выгрузку самого актуального дампа на staging машину для тестов. Потом займусь переписыванием кеша который собирает из базы агрегированные данные для отображения статистических данных на графиках и другие данные финансовые

Алексей спасибо за развернутый ответ. реальную нагрузку на продакшене пока не проверяли. я делаю последние штрихи по бэкапированию данных в облако amazon s3 и выгрузку самого актуального дампа на staging машину для тестов. Потом займусь переписыванием кеша который собирает из базы агрегированные данные для отображения статистических данных на графиках и другие данные финансовые

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

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

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

В таком случае вы можете искусственно уменьшить скорость вставки. Вставили блок данных, подождали, вставили ещё, таким образом, размазав нагрузку по времени.

кстати с экспортом все решилось просто. я выставил cpulimit на clickhouse-client и на операции архивирования. нагрузка 0.5 average

экспорт не мешает никак. с импортом были мысли делать sleep между чанками

наверное это единственные вариант на данный момент

проблема при экспорте в том что clickhouse-server ограничить через cpulimit не возможно, т.к. не понятно какой именно процесс подхватил данные а их там несколько выплывает - несколько потоков. и получается клиент ограничен в cpu а сервер жрет на полную )) ну я вас понял пока ограничимся чанками. потом когда переедем полностью докупим чуть более мощную машину. хотябы 4 cpu

не сказал бы что легко)) ALTER TABLE statistics.audience_statistic_segments FREEZE PARTITION '2' ALTER TABLE statistics.audience_statistic_segments ATTACH PARTITION - тут name месяца указывается? а нельзя все кусочки влить в базу ?

Вы можете физически скопировать кусочки в нужную папку с именем таблицы и выполнить ATTACH таблицы. Это позволит добавить все партиции

и тогда вам не нужно будет архивировать и розархивировать данные

Вы можете физически скопировать кусочки в нужную папку с именем таблицы и выполнить ATTACH таблицы. Это позволит добавить все партиции

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

когда вы делаете freeze partition '2' у вас получается дамп всей таблицы. Вы можете спокойно перемещать/копировать/архивировать эти данные из папки shadow. Когда же нужно восстановить бекап: создаете папку с именем таблицы в папке data, копируете туда бекап, выполняете ATTACH TABLE %table_name% (...)

когда вы делаете freeze partition '2' у вас получается дамп всей таблицы. Вы можете спокойно перемещать/копировать/архивировать эти данные из папки shadow. Когда же нужно восстановить бекап: создаете папку с именем таблицы в папке data, копируете туда бекап, выполняете ATTACH TABLE %table_name% (...)

так)) интересненько а что за запрос такой ? (...) ?

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

так)) интересненько а что за запрос такой ? (...) ?

вместо ... нужно указать столбцы таблицы создаваемой таблицы

go это хорошо) но можно ли пример запроса полный? ну или выдуманный. я сейчас выгружаю схему через SHOW CREATE TABLE %table_name% и это кидаю в файлик потом делаю DROP TABLE и заново CREATE TABLE из файлика и выгрузка данных

обратите внимание на https://clickhouse.yandex/reference_ru.html#ATTACH

схемы таблиц так же лежат в data папке КХ, их можно копировать оттуда

схемы таблиц так же лежат в data папке КХ, их можно копировать оттуда

может можно как-то схему натравить на ATTACH TABLE %table_name% (...) из файла?

может и можно) вы можете реализовать это на каком-нибудь из ваших любимых языков или написать скрипт на bash

получится выгружаю partials в shadows архивирую папочку кидаю в обалко. на другом сервере архив забираю распаковываю в папку data (предварительно очистив старую). выполняю ATTACH TABLE %table_name% .. не понял момент на счет схемы она должна быть заново создана ?

я пишу на bash решил что это будет самый быстрый вариант

freeze сам поместит данные в shadow. Попробуйте восстановить таблицу из этих файлов

freeze сам поместит данные в shadow. Попробуйте восстановить таблицу из этих файлов

FREEZE PARTITION на счет этого я понял. поместит в shadow. затем как это натравить на data ? объясните плиз как дураку)

Добрый вечер!

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

задали настройки движка, как в мануале

только поменяли max_rows -> 100 000

вместо 1 млн

данные не сливаются

в основную таблицу

а их там уже 197494

я понял...

это изза materialized полей...

создал другую буффер таблицу, без материалайзед полей