M
200к записей заливается из csv часа 2
чето подозрительно долго
Size: a a a
2021 March 23
D
драйвер? как заливаете?
S
заполнить по какому то алгоритму, да. допустим в абстрактном CRM добавили новые поля и нужно их прокачать в витрины
это миграция данных
это не table schema migration
в обычном SQL это решается каким то ETL скриптом которые делает кучу UPDATE
в clickhouse такое не прокатит
и не пробуйте делать ALTER TABLE ... UPDATE
IMHO единственное что можно сделать ALTER TABLE .. ADD COLUMN ... DEFAULT и тут какое то выражение, которое делает ваш алгоритм
для новых данных будет работать
остальные данные заполнятся по мере мержей
это не table schema migration
в обычном SQL это решается каким то ETL скриптом которые делает кучу UPDATE
в clickhouse такое не прокатит
и не пробуйте делать ALTER TABLE ... UPDATE
IMHO единственное что можно сделать ALTER TABLE .. ADD COLUMN ... DEFAULT и тут какое то выражение, которое делает ваш алгоритм
для новых данных будет работать
остальные данные заполнятся по мере мержей
AN
По http 200К заливаю 3 секунды.
D
D
200к записей заливается из csv часа 2
по ХТТП тоже можно курлом
https://t.me/clickhouse_ru/198454
https://clickhouse.tech/docs/en/interfaces/http/
https://t.me/clickhouse_ru/198454
https://clickhouse.tech/docs/en/interfaces/http/
АР
драйвер? как заливаете?
разными клиентами разные люди пробовали, конкретно сейчас я лил через датагрип, дбивером пробовали также
АР
встроенными функциями импорта
АР
Ощущение, что оно едет одиночными инсертами всё
D
разными клиентами разные люди пробовали, конкретно сейчас я лил через датагрип, дбивером пробовали также
я думаю клиенты в принципе плохо умеют батчем вставлять. вставьте командной строкой или по хттп
АР
--format_csv_delimiter="^" разделитель такой не понимает консольный клиент что ли
Code: 27. DB::Exception: Cannot parse input: expected '^' before: '19^980^0.00^B 40
ERROR: garbage after Nullable(Date): "19^980^0.0"
Code: 27. DB::Exception: Cannot parse input: expected '^' before: '19^980^0.00^B 40
ERROR: garbage after Nullable(Date): "19^980^0.0"
DC
--format_csv_delimiter="^" разделитель такой не понимает консольный клиент что ли
Code: 27. DB::Exception: Cannot parse input: expected '^' before: '19^980^0.00^B 40
ERROR: garbage after Nullable(Date): "19^980^0.0"
Code: 27. DB::Exception: Cannot parse input: expected '^' before: '19^980^0.00^B 40
ERROR: garbage after Nullable(Date): "19^980^0.0"
понимает
printf "a^b\n" | clickhouse-local --input-format CSV --format_csv_delimiter="^" --query="SELECT * FROM table" --structure='a String, b String'
a b
DC
printf "a^b\n" | clickhouse-local --input-format CSV --format_csv_delimiter="^" --query="SELECT * FROM table format Pretty" --structure='a String, b String'
┏━━━┳━━━┓
┃ a ┃ b ┃
┡━━━╇━━━┩
│ a │ b │
└───┴───┘
DC
Кто-нибудь сталкивался с такими ошибками
Детали: есть Replicated таблица, 8 реплик(без шардов), каждое утро на 4 репликах запускается крон который выполняет несколько insert в эту таблицу, данные вставляются на каждом хосте в несколько потоков, данные разные но партиции вставляемых данных пересекаются.
После того как кроны отрабатывают - видим 10-20 ошибок в replication_queue на каждом хосте(даже на тех на которых не было вставки).
На хостах еще куча других таблиц replicated, с шардами, с зеркалами, но там запись идет всегда в одну ноду... неужели проблема в параллельной записи в разные зеркала? Подскажите куда можно копнуть?
Code: 49, e.displayText() = DB::Exception: Part 202103_8469_8537_12 intersects previous part 202103_8434_8470_3 (state Committed). It is a bug. (version 20.8.12.2 (official build)) на постоянной основе? Каждый день появляются такие ошибки *на одной и той же таблице* в system.replication_queue. Иногда лечатся через optimize table <> final , иногда не помогает, приходится делать detach/attach партиции(помогает 100%).Детали: есть Replicated таблица, 8 реплик(без шардов), каждое утро на 4 репликах запускается крон который выполняет несколько insert в эту таблицу, данные вставляются на каждом хосте в несколько потоков, данные разные но партиции вставляемых данных пересекаются.
После того как кроны отрабатывают - видим 10-20 ошибок в replication_queue на каждом хосте(даже на тех на которых не было вставки).
На хостах еще куча других таблиц replicated, с шардами, с зеркалами, но там запись идет всегда в одну ноду... неужели проблема в параллельной записи в разные зеркала? Подскажите куда можно копнуть?
надо лог КХ полный с нескольких реплик (в режиме trace) , чтобы понять всю историю партов, делайте тикет в гитхаб заливайте log файлы куда-то
_12 _3 -- это была куча мержей уже (12 уровень)
_12 _3 -- это была куча мержей уже (12 уровень)
R
всем спасибо! понял, что нужно дальше копать : )
проверим предложенные варианты, потом отпишусь по результатам.
проверим предложенные варианты, потом отпишусь по результатам.
как обещал, сообщаю об итогах.
HAproxy действительно в конце запроса посылает tcp-пакет RST, на который кликхаус-сервер нервно реагирует.
в принципе, жить можно, на процессах не сказывается, но логи засоряются основательно.
попробовали разные настройки, в итоге самым действенным стал отказ от keep-alive соединений. для нашего сценария работы это подходит.
пока оставили так, но запланировали проверку других прокси - CHproxy и т.п.
оставлю тут решение для в backend-секции haproxy:
HAproxy действительно в конце запроса посылает tcp-пакет RST, на который кликхаус-сервер нервно реагирует.
в принципе, жить можно, на процессах не сказывается, но логи засоряются основательно.
попробовали разные настройки, в итоге самым действенным стал отказ от keep-alive соединений. для нашего сценария работы это подходит.
пока оставили так, но запланировали проверку других прокси - CHproxy и т.п.
оставлю тут решение для в backend-секции haproxy:
mode http
option http-server-closeVR
надо лог КХ полный с нескольких реплик (в режиме trace) , чтобы понять всю историю партов, делайте тикет в гитхаб заливайте log файлы куда-то
_12 _3 -- это была куча мержей уже (12 уровень)
_12 _3 -- это была куча мержей уже (12 уровень)
ок, сейчас будем делать. Спасибо.
>_12 _3 -- это была куча мержей уже (12 уровень)
Да, партиция - месяц, вставок параллельно идет много в одну партицию и не все большие, отсюда очень много мержей появляется
>_12 _3 -- это была куча мержей уже (12 уровень)
Да, партиция - месяц, вставок параллельно идет много в одну партицию и не все большие, отсюда очень много мержей появляется
DC
ок, сейчас будем делать. Спасибо.
>_12 _3 -- это была куча мержей уже (12 уровень)
Да, партиция - месяц, вставок параллельно идет много в одну партицию и не все большие, отсюда очень много мержей появляется
>_12 _3 -- это была куча мержей уже (12 уровень)
Да, партиция - месяц, вставок параллельно идет много в одну партицию и не все большие, отсюда очень много мержей появляется
я про то что в чате это не разобрать, тут надо грепать логи часов 6
y
Можно ли сделать матвьюху AggregatingMergeTree поверх другой матвьюхи тоже AggretatingMergeTree?
DC
как обещал, сообщаю об итогах.
HAproxy действительно в конце запроса посылает tcp-пакет RST, на который кликхаус-сервер нервно реагирует.
в принципе, жить можно, на процессах не сказывается, но логи засоряются основательно.
попробовали разные настройки, в итоге самым действенным стал отказ от keep-alive соединений. для нашего сценария работы это подходит.
пока оставили так, но запланировали проверку других прокси - CHproxy и т.п.
оставлю тут решение для в backend-секции haproxy:
HAproxy действительно в конце запроса посылает tcp-пакет RST, на который кликхаус-сервер нервно реагирует.
в принципе, жить можно, на процессах не сказывается, но логи засоряются основательно.
попробовали разные настройки, в итоге самым действенным стал отказ от keep-alive соединений. для нашего сценария работы это подходит.
пока оставили так, но запланировали проверку других прокси - CHproxy и т.п.
оставлю тут решение для в backend-секции haproxy:
mode http
option http-server-close>на который кликхаус-сервер нервно реагирует.
да, это все из-за библиотеки POCO, она возвращает такой уровень ошибки, и понизить его в POCO нельзя, потому что этот же код в других местах КХ должен выдавать Error level
да, это все из-за библиотеки POCO, она возвращает такой уровень ошибки, и понизить его в POCO нельзя, потому что этот же код в других местах КХ должен выдавать Error level
DC
Можно ли сделать матвьюху AggregatingMergeTree поверх другой матвьюхи тоже AggretatingMergeTree?
можно. Есть промежуточный уровень домерживания комбинатор -State.
просто во второй вью пишете AvgMergeState
в 99.99% люди которые задают этот вопрос уже сделали что-то неправильно, потому что обычно все в 100 раз проще.
просто во второй вью пишете AvgMergeState
в 99.99% люди которые задают этот вопрос уже сделали что-то неправильно, потому что обычно все в 100 раз проще.