ну оно достаточно тупое - инсертить надо руками на нужные шарды, либо через специальный движок таблиц, который сам по указанной функции распределяет
решардирования нет (только если данные перезаливать через select from insert)
все реплики рид-райт, можно писать данные куда угодно, они потом внутри шарда засинкаются
работает нормально, есть возможность распараллелить запросы по репликам

Как работает кликхаус, я вроде знаю :) Даже chproxy помогал делать - https://github.com/Vertamedia/chproxy . Меня больше интересовал вопрос, насколько стабильно и беспроблемно работает репликация в кх на основе зукипера. Если судить по наиболен частым вопросам в @clickhouse_ru , то не очень :(

Мне кажется, что в VM логичнее делать шардирование в ELK стайле: по таймстемпу

Как работает кликхаус, я вроде знаю :) Даже chproxy помогал делать - https://github.com/Vertamedia/chproxy . Меня больше интересовал вопрос, насколько стабильно и беспроблемно работает репликация в кх на основе зукипера. Если судить по наиболен частым вопросам в @clickhouse_ru , то не очень :(

главная проблема это настройка зукипера, а так всё норм

вопрос №2 - что лучше - такая репликация или никакой репликации )

Замените слово "кассандра" на "gcp persistent disk", а "кортекс" на "викторияметрикс". Получите справедливое утверждение про вм, при том, что gcp диски намного проще в настройке и сопровождении по сравнению с кассандрой, и они вообще не выходят из строя, в отличие от кассандры. См. https://medium.com/google-cloud/persistent-disks-and-replication-9b9412fd9565 .
Не понимаю, почему люди любят строить сложные ненадежные системы из говна и палок вместо использования готовых, простых и надежных решений.

хм, а как же:
- ограничение скорости репликации (от выжирания сети или диска)
- исчезнувшие парты (missing parts)
- вымывание page cache
- неудавшиеся синки failed fetches
- отстающие реплики(replication lag) и как результат выдача неправильных данных
- leader elections приводящий к повышенному CPU usage на нодах
- зависающий alter на репликах

и я даже не смотрел сюда https://github.com/ClickHouse/ClickHouse/issues?page=2&q=is%3Aissue+is%3Aopen+replication&utf8=%E2%9C%93

хахахахахах

Скиньте, пожалуйста, ссылку из инета про выход из строя gcp persistent disk

Скиньте, пожалуйста, ссылку из инета про выход из строя gcp persistent disk

Ок, пять лет назад у гугла был инцидент с дисками из-за удара молнии в дц. При этом диски не рассыпались, а просто не записались последние данные. Еще примеры есть? Желательно поновее и там, где диски не подлежали восстановлению после инцидента, как у amazon ebs :) Кратковременная недоступность дисков без их повреждения не в счет.

С таким подходом можно просто взять сервер с 100% доступностью и как бы перестать нуждатся в репликации.

Может я отстал от жизни, а разве можно насетапить пачку машин с GCP, раскидать их по AZ и рандомно херачить их каким нить chaos monkey демоном имея при этом 100% доступность диска?