Шардирование (sharding) — техника масштабирования баз данных, при которой таблица или коллекция физически разделяется на несколько частей (шардов), размещённых на разных серверах. Каждый шард содержит подмножество данных и обрабатывает запросы только для своего диапазона.
Стратегии шардирования
- Range-based — по диапазону ключа (записи с ID 1–1000 в шард 1, 1001–2000 в шард 2). Просто, но может привести к горячим шардам.
- Hash-based — ключ хешируется, результат определяет шард. Равномерное распределение, но диапазонные запросы медленнее.
- Directory-based — таблица маппинга ключ→шард. Гибко, но таблица маппинга — узкое место.
Проблемы шардирования
Шардирование усложняет архитектуру: JOIN-запросы между шардами невозможны или требуют scatter-gather; транзакции, затрагивающие несколько шардов, нужно реализовывать на уровне приложения (двухфазный коммит); изменение числа шардов (resharding) — сложная операция с простоем. Поэтому шардирование — крайняя мера, применяемая после исчерпания вертикального масштабирования и репликации.
История
Термин shard в контексте БД популяризировала компания Google в статье Bigtable (2006). MongoDB добавил встроенный шардинг в версии 1.6 (2010). MySQL Cluster предоставлял автошардирование с 2004 года. Vitess (YouTube, 2010) решил задачу шардирования MySQL для YouTube без изменения приложения. PostgreSQL поддерживает декларативное партиционирование с версии 10 (2017).
Связь с хостингом
Шардирование актуально при объёме данных от нескольких сотен ГБ и тысячах транзакций в секунду. На уровне хостинга это реализуется через кластеры: MongoDB Sharded Cluster, MySQL + Vitess, Cassandra (нативное шардирование). Большинство веб-проектов обходятся репликацией MySQL (master-slave) и кешированием без шардирования.
Как работает шардирование
Шардирование (sharding) -- разбиение базы данных на независимые части (шарды), каждая из которых хранится на отдельном сервере. Ключ шарда определяет, на каком сервере хранится запись. Горизонтальное шардирование: разные строки одной таблицы на разных серверах. Например, пользователи с ID 1--1M на shard-1, с ID 1M--2M на shard-2. MySQL не имеет встроенного шардирования -- используют ProxySQL или Vitess. PostgreSQL с расширением Citus (open source, от Microsoft) поддерживает шардирование. MongoDB имеет встроенный sharded cluster.
Когда нужно шардирование
Шардирование оправдано при: объёме данных >1 ТБ, нагрузке >100 000 запросов/сек, когда репликация (master-slave) не справляется с read-нагрузкой. До шардирования нужно исчерпать другие возможности: индексы, кэш (Redis), вертикальное масштабирование, read replica. Шардирование усложняет JOIN и транзакции между шардами. Ключевое ограничение: шард-ключ нельзя сменить без перебалансировки всех данных. NoSQL системы (Cassandra, MongoDB) спроектированы с шардированием изначально. Экспорт и бэкап шардированных данных сложнее, чем монолитной БД.
История шардирования
Термин «shard» в контексте баз данных popularized компанией Google в статье «Bigtable» (2006) и Amazon в «Dynamo» (2007). До этого схожие подходы назывались «horizontal partitioning». Flickr открыто описал свою шардированную MySQL-архитектуру в 2007 году, что вдохновило многих разработчиков. Vitess (созданный YouTube в 2010 году для шардирования MySQL) передан в CNCF в 2018 году. Шардирование остаётся сложнейшей операцией в жизненном цикле БД.