Когда НЕ стоит использовать шардинг
Реплики для чтения, секционирование и более мощные серверы решают большинство проблем масштабирования — узнайте, когда шардинг является неправильным решением
«Когда НЕ стоит использовать шардинг» — бесплатный урок SQL Academy на CoddyKit. Это урок 4 из 4. Ты можешь прочитать весь урок бесплатно ниже — а потом практиковать его прямо в браузере с встроенным редактором кода и ИИ-репетитором 24/7. Это часть пути обучения SQL Academy, и твой прогресс синхронизируется между веб-версией и приложением CoddyKit. Курс SQL Academy содержит 4 уроков всего.
Шардирование — крайняя мера
Шардирование многократно увеличивает операционную сложность. Большинству приложений оно никогда не требуется. Сначала исчерпайте более простые варианты.
Шаг 1: вертикальное масштабирование
Более мощный сервер. Современные облачные экземпляры легко поддерживают:
- 128 ядер
- 1 TB RAM
- 50 000 IOPS NVMe
Это 100–500 тысяч QPS на одном узле PostgreSQL. Большинство приложений работает в таких условиях без проблем.
Шаг 2: реплики для чтения
Если преобладает чтение, добавьте реплики. Один primary и 3 реплики могут обслуживать в 10 раз больше операций чтения.
Шаг 3: кэширование
Разместите Redis или memcached перед часто выполняемыми запросами. Часто это самый дешевый способ получить заметный результат.
Шаг 4: секционирование
Собственное декларативное секционирование PG решает проблему слишком большой таблицы в пределах одного сервера. Часто это в 100 раз проще, чем шардирование.
Шаг 5: разделение сервисов
Перенесите разные предметные области в разные базы данных: базу заказов, базу пользователей, аналитическую базу. Каждую из них можно масштабировать независимо.
Шаг 6: вынесение аналитики
Запросы OLTP → PostgreSQL. Аналитические запросы → ClickHouse / BigQuery / Snowflake. Многие истории «нам нужно шардирование» на самом деле означают: «аналитика поглощает ресурсы нашей OLTP-системы».
И только потом, возможно, шардирование
Если Вы по-прежнему упираетесь в предел при 50 TB данных только OLTP, а рабочая нагрузка требует большего объема записи, чем может обработать один сервер, начинайте планировать шарды.
Операционные расходы на шардирование
- Больше серверов для мониторинга и установки исправлений
- Резервное копирование всех шардов нужно координировать
- Запросы между шардами ложатся на код приложения
- Перераспределение шардов сложно выполнять
- Перегруженные шарды требуют активной балансировки
Стратегия «шардировать поздно»
Создавайте систему с учетом шардирования (всегда включайте tenant_id, никогда не используйте глобально увеличиваемые счетчики), чтобы позже CAN выполнить шардирование. Но не шардируйте систему, пока это не станет необходимостью.
Схема, удобная для шардирования
Даже если Вы остаетесь на одном узле, проектируйте систему так, будто в будущем может понадобиться шардирование:
- Идентификатор арендатора в каждой строке
- UUID или распределенные идентификаторы (не автоинкремент)
- Отсутствие глобально уникальных последовательностей
- Внешние ключи в пределах области арендатора
Признайте компромисс
Шардирование увеличивает емкость ценой функциональных возможностей. JOIN, транзакции и запросы усложняются. Убедитесь, что результат оправдывает затраты.
Итоги
Шардирование решает реальную проблему, но это тяжелый инструмент.
- Сначала вертикальное масштабирование
- Реплики для чтения и кэширование
- Секционирование до шардирования
- Вынесение аналитики из OLTP
- Проектируйте систему с возможностью шардирования, но откладывайте его реализацию
Быстрая проверка
Вы рассматриваете шардирование, потому что запросы OLTP выполняются медленно. Какой шаг с наибольшей вероятностью поможет до шардирования?
Часто задаваемые вопросы
Урок «Когда НЕ стоит использовать шардинг» бесплатный?
Да — полный текст урока «Когда НЕ стоит использовать шардинг» бесплатно доступен здесь в веб-версии. Чтобы практиковать его интерактивно (встроенный редактор кода и ИИ-репетитор 24/7) и разблокировать остальной курс SQL Academy, подпишись на CoddyKit PRO. Курс SQL Academy содержит 4 уроков всего.
Чему я научусь в уроке «Когда НЕ стоит использовать шардинг»?
Реплики для чтения, секционирование и более мощные серверы решают большинство проблем масштабирования — узнайте, когда шардинг является неправильным решением Ты практикуешь SQL Academy с помощью реального кода, который запускаешь прямо в браузере, и ИИ-репетитор 24/7 отвечает на твои вопросы во время урока.
Нужен ли мне опыт, чтобы начать SQL Academy?
Предыдущий опыт не требуется. SQL Academy на CoddyKit структурирован для всех уровней — от новичков до продвинутых, поэтому ты можешь начать отсюда или с самого начала и учиться в своем темпе. Это урок 4 из 4.
Сколько времени занимает урок «Когда НЕ стоит использовать шардинг»?
Большинство уроков CoddyKit занимают около 5–10 минут. Каждый из них компактный и интерактивный, поэтому ты постоянно делаешь прогресс и продолжаешь с того же места в веб-версии и приложении.
Можно ли писать и запускать код в этом уроке SQL Academy?
Да. Каждый урок SQL Academy включает встроенный редактор кода, поэтому ты пишешь и запускаешь реальный код прямо в браузере и получаешь моментальную обратную связь от AI — локальная установка не требуется.
Все уроки этого курса
- Стратегии шардинга: диапазон, хеш и каталог
- Запросы между шардами: сложная задача
- Citus и распределённый Postgres
- Когда НЕ стоит использовать шардинг