ИМ
Да , в chproxy
Посмотрите настройку read write_timeout. У меня была такая шляпа, когда закешированный ответ не успевал переслаться. Поставил две минуты и вылечилось
Size: a a a
2020 June 24
D
добрый день, а есть какая нибудь таблица показывающая чем занят background pool в данный момент? а то у нас replication queue застрял
V
Artur
Добрый день. У кого нибудь есть опыт переноса данных из Influxdb в CH?
Какая структура данный на стороне CH наиболее подходящая? Главный вопрос как лучше хранить набор тегов (key:value набор тегов у метрик зарание неизвестен).
Сейчас мы выбираем из нескольких вариантов
1. Использовать одну таблицу и динамически добавлять новые колонки на каждый новый тег. Как CH себя ведет при частом обновлении таблиц? Бедет ли такой вариант работат? Есть риск что получиться таблица с очень большим набором колонок.
2. Использовать две таблицы одну для метрик и одно для тегов как предложено здесь (https://groups.google.com/forum/#!searchin/clickhouse//clickhouse/pyy0OW12JKM/hlfvz-CVAQAJ)
1 table have 3 columns
key Int32,
timestamp DateTime
value Float64) order by (key, timestamp)
2 table have 2 columns: key - tag
Не очень понятно как заполнять вторую таблицу: key - tag
Видимо придется создавать отдельный кеш поверх это палицы на запись
3. Просто поесть все теги в Array или Json
Какая структура данный на стороне CH наиболее подходящая? Главный вопрос как лучше хранить набор тегов (key:value набор тегов у метрик зарание неизвестен).
Сейчас мы выбираем из нескольких вариантов
1. Использовать одну таблицу и динамически добавлять новые колонки на каждый новый тег. Как CH себя ведет при частом обновлении таблиц? Бедет ли такой вариант работат? Есть риск что получиться таблица с очень большим набором колонок.
2. Использовать две таблицы одну для метрик и одно для тегов как предложено здесь (https://groups.google.com/forum/#!searchin/clickhouse//clickhouse/pyy0OW12JKM/hlfvz-CVAQAJ)
1 table have 3 columns
key Int32,
timestamp DateTime
value Float64) order by (key, timestamp)
2 table have 2 columns: key - tag
Не очень понятно как заполнять вторую таблицу: key - tag
Видимо придется создавать отдельный кеш поверх это палицы на запись
3. Просто поесть все теги в Array или Json
У нас работает перенос один в один - т.е. на каждый межурмент своя таблица, которая создается динамически при необходимости. С колонками та же история - создаются автоматически при необходимости. Все это крутится в кластере 3х3 под нагрузкой 200к метрик/с - полет нормальный.
По нашим тестам - это самый оптимальный вариант с точки зрения скорости чтения, в таком виде кликхауз уделывает инфлюкс в среднем где-то в 3-5 раз. Вариант 2 таблицы или теги в массив - медленнее чем текущий.
По нашим тестам - это самый оптимальный вариант с точки зрения скорости чтения, в таком виде кликхауз уделывает инфлюкс в среднем где-то в 3-5 раз. Вариант 2 таблицы или теги в массив - медленнее чем текущий.
BB
Посмотрите настройку read write_timeout. У меня была такая шляпа, когда закешированный ответ не успевал переслаться. Поставил две минуты и вылечилось
Оно стоит по 15 минут, заведомо больше, в моем случае. Ошибка осталась.
VY
привет!
а как в клике посмотреть какие поля индексированы в таблице?
а как в клике посмотреть какие поля индексированы в таблице?
D
привет!
а как в клике посмотреть какие поля индексированы в таблице?
а как в клике посмотреть какие поля индексированы в таблице?
select * from system.tables;
VY
select * from system.tables;
спасибо!
IK
привет) народ, а может кто подсказать есть ли аналоги кластерных индексов? чтоб таблица была отсортирована всегда и можно было пользоваться ASOF JOIN без дополнительных сортировок?
NR
event.reply_to('@TehRealNoob')
D
Igor Kurmak
привет) народ, а может кто подсказать есть ли аналоги кластерных индексов? чтоб таблица была отсортирована всегда и можно было пользоваться ASOF JOIN без дополнительных сортировок?
в КХ естть только кластерный индекс по сути.
CREATE TABLE ... ORDER BY
CREATE TABLE ... ORDER BY
IK
в КХ естть только кластерный индекс по сути.
CREATE TABLE ... ORDER BY
CREATE TABLE ... ORDER BY
спасибо! я слегка не правильно представлял себе индексы в ch
AT
Добрый день. В логах вижу DB::Exception: Possible deadlock avoided. как понять в чем может быть причина?
Д
Добрый день. В логах вижу DB::Exception: Possible deadlock avoided. как понять в чем может быть причина?
Изменяешь структуру таблицы когда есть запрос который обращается к этой таблице
AT
Изменяешь структуру таблицы когда есть запрос который обращается к этой таблице
А как понять что за таблица? Как найти?
Д
А как понять что за таблица? Как найти?
на какой таблице deadlock?
AT
на какой таблице deadlock?
да
Д
да
на какой запрос он выкинул такую ошибку?
AT
на какой запрос он выкинул такую ошибку?
у меня много запросов к базе, я не могу точно понять что за запрос это вызывает, вот и хочу найти
Д
попробуй запрос SELECT * FROM tableName LIMIT 1, на каждую таблицу в базе. На какой будет ошибка, там и удаляли колонку
Д
во время запроса