EZ
а какого формата апдейты? CDR вроде не апдейтят :)
они там какие-то кастомные json-поля апдейтят
нам однажды с реплицированными таблицами сильно помог запрос
select * from system.replication_queue where database='...' and table='...'
Size: a a a
2021 January 13
EZ
что в партициях?
нам однажды с реплицированными таблицами сильно помог запрос
нам однажды с реплицированными таблицами сильно помог запрос
нет, репликации нет
M
они там какие-то кастомные json-поля апдейтят
если апдейтов не много, то попробуйте апдейты через инсерт с ReplacingMergeTree. если много, то возможно другую бд...
EZ
если апдейтов не много, то попробуйте апдейты через инсерт с ReplacingMergeTree. если много, то возможно другую бд...
т.е. делаю ReplacingMergeTree с order by uniqueId, и вставляю обновлённую строку с этим же uniqueId, и КХ её заменит?
ВВ
да
DT
т.е. делаю ReplacingMergeTree с order by uniqueId, и вставляю обновлённую строку с этим же uniqueId, и КХ её заменит?
Когда нибудь, eventually
S
Всем привет. Пытаемся внедрить КХ для хранения cdr (лог звонков с АТС). Партиционирование по timestamp (yyyymm). При вводе в эксплуатацию начала валиться ошибка Too many parts (600). Merges are processing significantly slower than inserts. (version 20.12.5.14 (official build)). Пустил трафик через clickhouse-bulk ( "flush_count": 1000, "flush_interval": 5000 ) — ошибка не ушла. Добавил
<merge_tree>
<parts_to_delay_insert>300</parts_to_delay_insert>
<parts_to_throw_insert>600</parts_to_throw_insert>
<max_delay_to_insert>2</max_delay_to_insert>
<max_suspicious_broken_parts>5</max_suspicious_broken_parts>
</merge_tree>
— всё равно ошибка не ушла. Что я делаю не так?
<merge_tree>
<parts_to_delay_insert>300</parts_to_delay_insert>
<parts_to_throw_insert>600</parts_to_throw_insert>
<max_delay_to_insert>2</max_delay_to_insert>
<max_suspicious_broken_parts>5</max_suspicious_broken_parts>
</merge_tree>
— всё равно ошибка не ушла. Что я делаю не так?
вставлять надо БАТЧЕМ либо по 10 тыс записей (а лучше 100 тыс), либо не чаще 1 раз в секунду
можете еще ENGINE=Buffer таблицу поставить и в нее вливать, но там сохранность данных при рестарте не гарантируетс...
flush_interval оставьте в bulk 5000 а flush_count поднимите до 10000 хотя бы
можете еще ENGINE=Buffer таблицу поставить и в нее вливать, но там сохранность данных при рестарте не гарантируетс...
flush_interval оставьте в bulk 5000 а flush_count поднимите до 10000 хотя бы
EZ
вставлять надо БАТЧЕМ либо по 10 тыс записей (а лучше 100 тыс), либо не чаще 1 раз в секунду
можете еще ENGINE=Buffer таблицу поставить и в нее вливать, но там сохранность данных при рестарте не гарантируетс...
flush_interval оставьте в bulk 5000 а flush_count поднимите до 10000 хотя бы
можете еще ENGINE=Buffer таблицу поставить и в нее вливать, но там сохранность данных при рестарте не гарантируетс...
flush_interval оставьте в bulk 5000 а flush_count поднимите до 10000 хотя бы
там слишком мало строк на вставку, чтобы это было проблемой. в апдейтах беда 99%
M
про datetime64 в доке написано:
у нас datetime64(9)
CREATE TABLE dtт.е. можно не указывать размерность
(
`timestamp` DateTime64(3, 'Europe/Moscow'),
`event_id` UInt8
)
ENGINE = TinyLog
INSERT INTO dt Values (1546300800000, 1), ('2019-01-01 00:00:00', 2)
у нас datetime64(9)
:) insert into test.test_ip (dt64) values (1610525117709038246) ;вставку можно только через указание размерности делать?
1 rows in set. Elapsed: 0.005 sec.
:) insert into test.test_ip (dt64) values (1610525117.709038246) ;
1 rows in set. Elapsed: 0.006 sec.
:) SELECT dt64 FROM test.test_ip
┌────────────────────dt64─┐
│ 2021-01-13 08:05:17.709 │
└─────────────────────────┘
┌──────────────────dt64─┐
│ 2106-02-07 :30:38.246 │
└───────────────────────┘
ClickHouse server version 20.8.5 revision 54438
EZ
Когда нибудь, eventually
а примерно когда?
M
при мерже, обращение через group by
ВВ
а примерно когда?
Если не терпится - то добавлешь FINAL в селект. НО работает сразу медленее.
EZ
Вячеслав Владимиров
Если не терпится - то добавлешь FINAL в селект. НО работает сразу медленее.
понял. а если терпится, то порядок задержки? 5 секунд, 5 минут, полчаса?
ВВ
это у кого как. Закинь да проверь что именно у вас
MK
а че clickhouse-bulk норм софт?
EZ
а че clickhouse-bulk норм софт?
Несколько лет использую. Работает и не жужжит
EZ
Mergetree в replacing можно преобразовать? Или заново заливать?
M
понял. а если терпится, то порядок задержки? 5 секунд, 5 минут, полчаса?
по доке, при селекте на чистую таблицу кх не гарантирует отсутствие дубликатов. лучше делать с group by, а чтобы по памяти не падало - в конфиге указать, когда с диском начинать работать, если оперативки не хватит.
N
Всем привет!
Если есть таблица с колонкой time типа DateTime64(6). По этой колонке есть PARTITION BY и ORDER BY (составной). Будет ли эффективен следующий запрос? То есть не будет же вся колонка сортироваться?
Если есть таблица с колонкой time типа DateTime64(6). По этой колонке есть PARTITION BY и ORDER BY (составной). Будет ли эффективен следующий запрос? То есть не будет же вся колонка сортироваться?
select * from table order by desc(time) limit 10M
partition by - тут лишний кмк.