сейчас 1 шард 3 реплики. они не справляются с обработкой запросов по CPU (но и делать 4ю реплики - это уже будет 4х по диску объема данных)
Идея сделать 2-3 шарда по 3 реплики и перераспределить данные первого шарда по этим 3м.
как показал ресеч - дистрибютед таблица пересылает на шарды исходный запрос (пуш даун запроса)
если данные перераспределим рандомно по 3 новым шардам, то не получится ли так, что в новом состоянии будет упахиваться 3 шарда (9 реплик) так же на 100% как в текущих реалиях 3 реплики 1го шарда?
Повторяю вопрос😁
Шардируйте по высококардинальной колонке, что часто учавствует в group by
>если данные перераспределим рандомно по 3 новым шардам, то не получится ли так, что в новом состоянии будет упахиваться 3 шарда (9 реплик) так же на 100% как в текущих реалиях 3 реплики 1го шарда? если у вас простые запросы только по одной таблице - то не будет проблем, можно rand() или что-то высококрдинальное если нужны join'ы / подзапросы к другим таблицам, то тогда данные между шардами будут гоняться и будет всё медленно работать. Надо подбирать так чтобы все необходимые данные лежали на одном шарде( по user_id/app_id например шардировать ) Но это в будущём влечёт другие проблемы, типа неравномерного распределения данных между шардами
CityHash от user_id или app_id в качестве ключа шардирования избавляет от неравномерности.
Интересно каким это образом избавит?
Обсуждают сегодня