Comments 10
Понравилось изложение. В статье не упомянуто, что партицирование (горизонтальное) на практике чаще всего делается по времени (по годам или же чаще по кварталам), т.к. 80% данных в большом бизнесе - это временные ряды (индексы таблиц чаще всего TimeStamp c наносекундами). Партицирование прекрасно реализовано даже в крохотных бессерверных аналитических движках типа DuckDB, без падения скорости выполнения запросов по всем партициям (и с ускорением в разы при запросах по последней партиции, самым частым, те же 80%).
Но в использовании оно все равно сложное, потому что "бухгалтерия в конце марта закрывает декабрь", а значит приходится обновлять не одну (4 кв.), а две партиции (4+1 кв.) А на практике часто все 5, потому что... Потому что изменения в марте часто вносятся и в 1-й квартал прошлого года, а значит придется изменить все 5-ть партиций.
Вы хотели говорить о методах, которые масштабируют за счёт увеличения количества узлов. Очень хочется спросить - какое отношение к этому методу имеет секционирование (партиционирование)? Вся работа данного метода осуществляется в рамках одного инстанса сервера БД, ну максимум можно раскидать партиции по разным томам.
Хорошая статья. Всё разложено по полочкам, структурно. Подходит для тех, кто готовится к собесам
не хватило примеров, теорию я понимаю, а как мне это реализовать на практике?
Такс, а теперь опрос: у кого есть горизонтальное масштабирование бд? Мастер-слейвы не в счёт. Не все могут заставить разрабов разделять запросы на запись и на чтение на уровне апки.
Хорошая статься познавательная
Есть ли готовые решения прокси или координаторов, которые понимают в какой шард отправлять запрос?
Горизонтальное масштабирование базы данных. Репликация. Партицирование. Шардирование