Шардирование — это когда большую базу данных перестают пытаться запихнуть в один сервер и начинают резать на куски. Эти куски и есть шарды: каждая часть хранит только свой фрагмент данных и при желании может жить на отдельной машине.
Почему вообще до этого доходят? С ростом пользователей, транзакций и функциональности одна «центральная» база в какой-то момент начинает задыхаться: запросы тормозят, ресурсы упираются в потолок, масштабирование уже не спасает. Тогда данные разбивают на несколько шардов и каждый обслуживается отдельно. На практике это даёт возможность:
- раскидать нагрузку по разным серверам, а не жарить один до красна,
- сократить время отклика за счёт меньших по размеру и более локальных наборов данных,
- устранить одно глобальное узкое место в производительности,
- масштабировать систему дальше без полной переделки всей архитектуры.
Важно не путать шардирование с репликацией. При репликации вы берёте одну и ту же базу и копируете её на несколько серверов — ради отказоустойчивости и доступности. При шардировании всё наоборот: данные именно делят, а не дублируют. У каждого шарда свой уникальный набор строк, и целиком картинка складывается только из всех шардов вместе.
Где это обычно встречается? В крупных интернет-магазинах, соцсетях, финтехе, аналитических системах, телеметрии — везде, где объём и скорость роста данных такие, что один сервер начинает казаться шуткой.
В PostgreSQL, MySQL, MongoDB и других СУБД подходы к шардингу отличаются, но идея одна: нагрузку разнести, горизонтальное масштабирование сделать нормальной операцией, а не катастрофой. Часто рядом всплывает термин «партиционирование», и тут тоже есть нюанс: партиционирование режет таблицы внутри одной базы и одного контура хранения, а шардирование — уводит части данных на разные физические базы или сервера.
Когда шардирование настроено аккуратно и продумано, это превращает базу в более устойчивую и масштабируемую систему, которая не ломается от роста трафика и объёмов, а просто расширяется по мере необходимости.
