переезжаем на шарды и у нас есть несколько мест где мы в ReplacingMergeTree обновляем данные (insert строки с большим значением в версии) - есть ли какой-то механизм таких “апдейтов” на шарде (вставлять в дистрибутед таблицу) при условии что изначально в шарды пишется рандомом (мы не знаем на каком шарде данные). При выборке из distributed таблицы строки с более актуальными версиями будут ли правильно мержится?
Прочитайте, что тако Distibuted таблица и скорей всего все ваши запросы уйдут.
А вы не можете использовать хэш функцию от ключа вместо настоящего рандома? С ней вы и равномерно раскидаете и гарантируете попадание обновляемых данных на один и тот же шард.
For example, for a query with GROUP BY, data will be aggregated on remote servers, and the intermediate states of aggregate functions will be sent to the requestor server. Then data will be further aggregated.
Ну по факту, дистрибьютед таблица кидает запрос на все шарды, а какие там данные, она не знает
подбирайте детерминированный ключ шардирования, обычно cityHas64(uuid column) может быть хорошим вариантом или что-то из доменной области
спс попробую, не хотелось ключ шардирования вообще (хотели не писать в упавший шард, добавлять шарды не думая о решардинге и тп)
“хотели не писать в упавший шард” для этого обычно ещё репликацию делают а вот решардинг пока больно)
реплики есть, но бывает что большой мерж делает плохо нескольким репликам сразу
КХ падает от мерджа?
Обсуждают сегодня