только на репликах одного шарда?
Понятно, что можно обойти только нужные реплики индивидуально и создать на каждой табличку, но это не очень удобно...
не существует
Мне пришла в голову идея создать ещё один кластер, впихнуть в него только реплики одного шарда, и посмотреть запустятся ли реплики с таким конфигом. Если да - то по идее можно будет делать CRTEATE ... ON CLUSTER cluster_shard1, и цель будет достигнута. Но проверю только завтра.
Репликация не связана с on cluster. Если у вас 25 шардов и вам надо на каждом индивидуально создавать то придется +25 кластеров описать. Если вам надо создать таблицу без шардов типа 50 реплик, то для этого не надо ещё один кластер создавать, on cluster позволяет такое.
У нас кейс немного другой - надо создавать kafka-консьюмеры, с учетом того что мы сами регулируем какой топик на какой шард писать. Если создать консьюмеры на всех шардах - то писаться будет, как я понимаю, на случайный. Нам это не надо.
А как вы планируете говорить консумеру что он будет читать?
Тут как раз не сложно, очереди для разных шардов разделены на разные топики. Соответственно делается консумер по нужному списку топиков.
Правильно ли понял что у вас однотипные данные в кафке в разных топиках. Вы хотите эти однотипные данные сливать в одну дистрибьютед таблицу в клике, но делать это через заливку в локальные таблицы консумерами кафки. Т.е. у вас и данные которые должны быть в одном топике почемуто размазаны, так еще и заливку хотите целенаправленно перекашивать по шардам, чтобы и там разброд с потреблением ресурсов был?
Не совсем. У нас каждая физическая нода нашего SaaS пишет поток в свой топик. А дальше мы хотим выбирать сами, на какой шард пойдут данные с какой ноды (и соответственно топика) и писать сразу в физическую таблицу (не distributed). То есть сами реализуем шардирование. Из distributed мы только читаем.
значит все правильно понял. А зачем надо настолько микроменеджерить данные? Сливали бы все один топик и равномерно бы из него выливали. А так будут перекосы которые вы не сможете устранить
Лить в один топик точно не будем - из этих топиков читают и другие приложения, не только clickhouse, и для них удобнее держать в отдельных топиках. А выливать сразу в Distributed одним потоком не хочется, потому что не гибко. 1. Если происходит что-то на одной ноде (скажем, в очередь начинают литься неконсистентные данные; да что угодно) - встаёт всё. А так мы можем очень гибко регулировать, что, куда и как. 2. В планах разносить шарды далеко друг от друга физически, и тогда надо будет лить данные ноды в шард поближе.
Да, так можно. У нас есть кластер 3 шарда по две реплики и к нему ещё три кластера: шард1, шард2 и шард3. Т.е. каждая года в двух кластерах. Полёт нормальный.
макросы можно использовать в неожиданных местах, возможно в имени топика можно использовать макрос shard (я не проверял)
Обсуждают сегодня