?

труба у нас. У яндекса все хорошо.

Давайте начнем с простого. Как это работает.

Вы пишете в distributed, она смотрит на параметр internal_replication -- он true -- ага решает distributed, надо писать в любую реплику, дальше сами внутри replicated таблицы все сделают. Ура win.

Вы пишете в distributed, она смотрит на параметр internal_replication -- он false -- ага решает distributed надо писать во все  реплики (там внутри не умеют реплицировать). Пишет в три реплики и все умножается на 3 в случае если там была replicated.

Вроде кликхаус никогда не обеспечит строгой консистентности. Он ее будет постоянно восстанавливать, но блокировать до полного восстановления консистентности они никогда ничего не будет. Это буква А в САР-теореме.

какой тогда смысл в false я не понимаю, если мы не достигаем балансировки с помощью дистрьютед

аа

я догнал, сори ))

кто вообще говорил про чтение, мы еще дошли туда. internal_replication это про запись через distributed

последнее ваше изменение меня привело в чувства))

😊

получается в случае репликации всегда пишем в одну реплику, без вариантов

если нужно просто во все реплики писать без реплицируемых таблиц тогда false

у вас 1 шард. Вам можно не использовать distributed вообще. Балансировать ngnix и писать и читать из любой реплики.

да я к этому и вел

благодарю вас))!

наверно дистрибьютед таблица может помочь в случае серьезных селектов

из дистрибутед читать лучше, хз почему. Он как-то сгребает со всех реплик записи

👆🏻

есть один вариант использования когда distributed нужна для одного шарда.
это распараллеливание select  между репликами (max_parallel_replica >1).
НО нужен sampling у таблицы, и max_parallel_replica работает очень редко. Это нужно специально это все проектировать. И точить запросы под max_parallel_replica.

ага понятно

нет. По дефолту нет. У вас точно нет.