каждый из 4000 человек в этом чате сталкивался с этой проблемой. И все как-то ее решили. Хорошего решения нет.

Можно либо не вставлять в КХ пока нету всех данных, можно записывать в collapsing / replacing при приходе новых данных запоминая состояние где-то в другой базе, mysql / cassandra ..., можно выбирать использовать aggregatingMT и как-то им вычислять, но тоже не быстро это https://gist.github.com/den-crane/d03524eadbbce0bafa528101afa8f794 .

не будет оно 20k RPS держать
сотни RPS да, десятки тысяч врятли, но можете попробовать побенчмаркать,

пачки оно эффективно разруливает да. если буфер достаточного размера, чтобы не плодить много кусков system.parts
но при перегрузке сервера данные теряются

если у вас уже есть буффер и он надежный (то есть реально не теряет данные), вам не нужны Buffer таблицы, пустая трата времени

если видите что ваш буффер данные теряет и не можете разобраться
то да, Buffer таблица может помочь
только  используйте постоянные соединения с clickhouse, чтобы у вас 20k rps по пулу в 100 TCP коннектов ходил

Всем привет! В clickhouse имеется движок таблиц s3, который во многом похож на движок file? То есть clickhouse выгружает данные на s3 в указанном формате (csv, tabseparated, native и так далее) и работает с ним по аналогии с тем, как таблица на движке File работала бы с локальным файлом?

да

Спасибо

optimize table ttt final;

OPTIMIZE TABLE tt FINAL

Timeout exceeded while receiving data from server. Waited for 300 seconds, timeout is 300 seconds.
Cancelling query.
Ok.
Query was cancelled.

0 rows in set. Elapsed: 566.146 sec.

объясните пожалуйста, optimize прошел или нет?

а разве отмена запроса не означает что процесс был прерван?

“ddl” не может быть отменен

Timeout exceeded while receiving data from server. Waited for 300 seconds, timeout is 300 seconds.
Cancelling query.

это ожидаемо на любую долгую “ddl” операцию насколько понимаю

Query was cancelled.

а вот это не понятно

0 rows in set.

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

optimize table ttt final;

OPTIMIZE TABLE ttt FINAL

Ok.

0 rows in set. Elapsed: 238.029 sec.

это обычный ответ на optimize

Оптимайз доработает, не хотите разрывов, запускайте клиента так: clickhouse-client —receive_timeout=86400

в данном случае он доработал или нет?

Да, если это оптимайз, можно прервать по Ctrl+C
и подключившись повторно, увидеть свой мердж, например, так:
select table,floor(elapsed,2) as elapse,floor(progress,2) as progre,floor((elapsed/progress)*(1-progress),2) as estimate,result_part_name, num_parts as n from system.merges order by estimate asc;

@den_crane привет. У меня возник такой вопрос: после взлома у меня реплики различаются по количеству данных, ты говорил что надо проделать процедуру восстановления, но мне @dj_mixer посоветовал вариант с созданием рядом таблички скажем с префиксом table_new туда залить данные и потом старую дропнуть или переименовать в table_old, а table_new переименовать в table. что посоветуешь ?

сервак то после взлома с нуля переставили? ;) или надеетесь что взлом не повториться?

у него ЗК был открыт для всех