Шардирование и репликация

Партиционирование против шардирования, зачем шардировать, выбор ключа шарда и борьба с горячими ключами, маршрутизация и ребалансировка шардов, кросс-шард операции, репликация, выбор SQL против NoSQL и вынос аналитики из OLTP в OLAP — как раскидать данные Go-сервиса по машинам, не получив горячий шард, лаг репликации и кросс-шард JOIN на каждом запросе.

IT Abyss

Шардирование и репликация

Когда данные Go-сервиса перестают влезать в одну машину или одна машина перестаёт держать поток записей, данные раскидывают по нескольким инстансам — и весь интерес начинается после слова «раскидать». Сначала нужно отличать партиционирование (разрезать одну таблицу на куски внутри одного инстанса БД) от шардирования (разнести данные по разным инстансам), потом выбрать ключ шарда, по которому строка попадёт на свою машину, найти способ маршрутизации запроса к нужному шарду, пережить ребалансировку при росте кластера и как-то отвечать на запросы, которым нужны данные из многих шардов сразу. Параллельно с этим идёт репликация: шард почти никогда не живёт в одиночку — у него есть реплики ради надёжности и масштабирования чтений.

Главная ловушка темы — считать, что шардирование «просто разносит данные по серверам» и на этом всё. На деле цена прячется в деталях: ключ шарда низкой кардинальности (вроде пола пользователя) создаёт горячий шард и перекос нагрузки; популярный пользователь или вирусный пост дают горячий ключ внутри шарда; асинхронная репликация приносит лаг и устаревшие чтения, а синхронная — медленнее; кросс-шард JOIN, агрегация и поиск без ключа дороги и съедают выигрыш. Отдельный пласт — выбор хранилища (SQL против NoSQL под реальные паттерны доступа) и развязка боевой нагрузки OLTP от аналитической OLAP, чтобы тяжёлый отчёт не клал прод. Эта тема разбирает распределение данных по слоям — от различия партиций и шардов до конвейера из OLTP в OLAP.

Карта темы

Партиционирование против шардирования — партиционирование режет одну таблицу на куски (range/list/hash) внутри одного инстанса БД, чтобы планировщик пропускал лишние партиции, а шардирование разносит данные по разным инстансам.
Зачем шардировать — поднять пропускную способность на запись, размазать нагрузку на CPU, гео-распределить данные ближе к пользователям и хранить объём, который не влезает в один сервер; шард всегда живёт с репликами.
Выбор ключа шарда — высокая кардинальность (user_id хорошо, пол плохо), равномерное распределение нагрузки и стабильные паттерны доступа; плохой ключ даёт горячий шард или кросс-шард на каждом запросе.
Горячие ключи — один ключ или шард забирает непропорционально много трафика (популярный пользователь, вирусный пост); лечится разбиением горячего диапазона, солью к ключу, кэшем или выделенным шардом.
Маршрутизация шардов — как запрос находит свой шард: строка DSN с координатами подключения, прокси со знанием карты или узел-координатор, который планирует и форвардит (например Citus для Postgres), с разменом по латентности и риском узкого места.
Ребалансировка шардов — срабатывает, когда шард распух, перегрелся, кластер вырос или сжался или сменился ключ шарда; диапазоны двигают с минимальным простоем, а консистентное хеширование минимизирует объём переезда.
Кросс-шард операции — кросс-шард JOIN, агрегация и поиск строки без ключа дороги; их избегают денормализацией, fan-out с последующим merge или поисковым индексом (Elasticsearch).
Репликация — primary/master принимает записи, реплики отдают чтения; асинхронная репликация быстра, но даёт лаг и устаревшие чтения, синхронная согласованна, но медленнее, а failover повышает реплику до primary.
SQL против NoSQL — SQL (реляционная модель, ACID, джоины, жёсткая схема, сильная согласованность) против NoSQL (документы, key-value, wide-column, гибкая схема, простое горизонтальное масштабирование, часто eventual consistency); выбор по паттернам доступа.
От OLTP к OLAP — держать транзакционную (OLTP, Postgres) и аналитическую (OLAP) нагрузку врозь, стримя изменения через CDC или доменные события и Kafka в OLAP (ClickHouse), даталейк (S3) и хранилище (Snowflake).

Частые ошибки и ловушки

Ошибка	Последствие
Путать партиционирование с шардированием	Ждёшь масштаба по записи от партиций внутри одного инстанса — потолок одной машины никуда не делся
Шардировать без реплик	Падение одного узла теряет его данные и часть кластера — нет ни надёжности, ни чтений в масштабе
Брать ключ шарда низкой кардинальности (пол, статус)	Несколько перегруженных шардов и простаивающие остальные — перекос нагрузки
Выбирать ключ без учёта паттернов доступа	Каждый запрос ходит кросс-шард, потому что нужная строка не находится по ключу
Игнорировать горячий ключ внутри шарда	Один популярный пользователь или вирусный пост кладёт целый шард
Делать маршрутизацию через единственный координатор без резерва	Узел маршрутизации становится узким местом и единой точкой отказа
Ребалансировать обычным хешем по числу узлов	При добавлении узла переезжает почти весь кластер вместо малой доли
Строить продукт на кросс-шард JOIN и поиске без ключа	Каждый такой запрос веером бьёт по всем шардам — дорого и медленно
Считать асинхронную реплику источником свежих данных	Лаг репликации даёт устаревшие чтения и аномалию read-after-write
Тянуть NoSQL «для масштаба» без реальной причины	Теряешь джоины и сильную согласованность там, где хватило бы простого Postgres
Гонять аналитику тяжёлыми запросами по боевому OLTP	Отчёт нагружает транзакционную БД и роняет латентность основного сервиса

Значение для собеседований

Распределение данных — обязательная тема senior-уровня Go-интервью в части system design, и проверяют не знание слова «шардирование», а понимание его цены. Интервьюер смотрит, отличаете ли вы партиционирование от шардирования, выбираете ли ключ шарда по кардинальности и паттернам доступа, помните ли, что шард живёт с репликами, и понимаете ли, что асинхронная репликация приносит лаг, а кросс-шард операции дороги.

Что обычно проверяют:

В чём разница партиционирования (одна таблица, один инстанс) и шардирования (данные по разным инстансам) и зачем вообще шардировать.
Как выбрать ключ шарда (высокая кардинальность, равномерная нагрузка, стабильные паттерны доступа) и чем грозит плохой ключ.
Что такое горячий ключ и горячий шард и как с ними бороться (разбить диапазон, посолить ключ, закэшировать, выделить шард).
Как запрос находит свой шард (DSN, прокси, координатор вроде Citus) и где у маршрутизации узкое место и точка отказа.
Когда и как ребалансировать шарды и почему консистентное хеширование минимизирует переезд данных.
Чем дороги кросс-шард JOIN, агрегация и поиск без ключа и как их избегать (денормализация, fan-out + merge, поисковый индекс).
Как устроена репликация (primary принимает записи, реплики отдают чтения), чем асинхронная отличается от синхронной и что такое лаг репликации и failover.
Как выбирать между SQL и NoSQL по паттернам доступа и согласованности и почему разумно начинать с простого Postgres.
Зачем разделять OLTP и OLAP и как стримить изменения через CDC и Kafka в ClickHouse, S3 и Snowflake.

Типичный неверный ответ: «шардирование — это просто разнести данные по нескольким серверам». Это запускает разбор того, что без реплик падение узла теряет данные, что ключ низкой кардинальности создаёт горячий шард, что маршрутизация и ребалансировка — отдельная инженерная задача, что кросс-шард JOIN бьёт веером по всем шардам, что асинхронная репликация даёт устаревшие чтения, и что аналитику нельзя гонять по боевому OLTP.

advanced

Sharding and Replication

Partitioning versus sharding, why shard, shard-key selection and fighting hot keys, shard routing and rebalancing, cross-shard operations, replication, choosing SQL versus NoSQL, and moving analytics out of OLTP into OLAP — how to spread a Go service's data across machines without getting a hot shard, replication lag, and a cross-shard JOIN on every request.

go-sd-data-distribution

Practice: 10 questions →

Sections

Contents

Detailed explanation

Sharding and Replication

When a Go service's data stops fitting on one machine, or one machine stops holding the write flow, the data is spread across several instances — and all the interest begins after the word "spread." First you must distinguish partitioning (cutting one table into chunks within a single DB instance) from sharding (splitting data across different instances), then pick the shard key that decides which machine a row lands on, find a way to route a query to the right shard, survive rebalancing as the cluster grows, and somehow answer queries that need data from many shards at once. Running alongside all of this is replication: a shard almost never lives alone — it has replicas for durability and for read scaling.

The central trap of this topic is assuming sharding "just spreads data across servers" and that is that. In reality the cost hides in the details: a low-cardinality shard key (like a user's gender) creates a hot shard and load skew; a popular user or a viral post produces a hot key inside a shard; asynchronous replication brings lag and stale reads, while synchronous replication is slower; cross-shard JOIN, aggregation, and key-less search are expensive and eat the gain. A separate layer is the choice of storage (SQL versus NoSQL for the real access patterns) and the decoupling of the production OLTP load from the analytical OLAP load, so a heavy report does not take prod down. This topic breaks data distribution into layers — from the difference between partitions and shards to the pipeline from OLTP to OLAP.

Topic Map

Partitioning versus sharding — partitioning slices one table into chunks (range/list/hash) inside a single DB instance so the planner skips irrelevant partitions, while sharding spreads data across different instances.
Why shard — to raise write throughput, spread CPU load, geo-distribute data closer to users, and store a volume one server cannot hold; a shard always runs with replicas.
Shard-key selection — high cardinality (user_id good, gender bad), even load distribution, and stable access patterns; a bad key creates a hot shard or a cross-shard query on every request.
Hot keys — one key or shard taking disproportionate traffic (a celebrity user, a viral item); mitigated by splitting the hot range, salting the key, caching it, or giving it a dedicated shard.
Shard routing — how a query finds its shard: a DSN string with connection info, a proxy that knows the map, or a coordinator node that plans and forwards (e.g. Citus for Postgres), with trade-offs in latency and the risk of a bottleneck.
Shard rebalancing — triggered when a shard grows too large, runs hot, the cluster grows or shrinks, or the shard key changes; ranges move with minimal downtime, and consistent hashing minimizes how much data moves.
Cross-shard operations — cross-shard JOIN, aggregation, and key-less row search are expensive; you avoid them with denormalization, fan-out then merge, or a search index (Elasticsearch).
Replication — a primary/master takes writes, replicas serve reads; async replication is fast but causes lag and stale reads, sync replication is consistent but slower, and failover promotes a replica to primary.
SQL versus NoSQL — SQL (relational, ACID, joins, rigid schema, strong consistency) versus NoSQL (document, key-value, wide-column, flexible schema, easy horizontal scale, often eventual consistency); choose by access patterns.
From OLTP to OLAP — keep transactional (OLTP, Postgres) and analytical (OLAP) load apart, streaming changes via CDC or domain events and Kafka into OLAP (ClickHouse), a datalake (S3), and a warehouse (Snowflake).

Common Mistakes and Traps

Mistake	Consequence
Confusing partitioning with sharding	You expect write scale from partitions inside one instance — the single-machine ceiling is still there
Sharding without replicas	A single node failure loses its data and part of the cluster — neither durability nor read scaling
Picking a low-cardinality shard key (gender, status)	A few overloaded shards and the rest idle — load skew
Choosing a key without regard for access patterns	Every query goes cross-shard because the needed row is not found by the key
Ignoring a hot key inside a shard	One celebrity user or a viral post takes a whole shard down
Routing through a single coordinator with no backup	The routing node becomes a bottleneck and a single point of failure
Rebalancing with a plain hash over the node count	Adding a node moves almost the whole cluster instead of a small fraction
Building the product on cross-shard JOIN and key-less search	Every such query fans out across all shards — expensive and slow
Treating an async replica as a source of fresh data	Replication lag gives stale reads and a read-after-write anomaly
Reaching for NoSQL "for scale" with no real reason	You lose joins and strong consistency where a simple Postgres would do
Running analytics with heavy queries on the production OLTP	The report loads the transactional DB and tanks the main service's latency

Interview Relevance

Data distribution is a mandatory topic at the senior level of a Go interview in the system-design part, and the question is not whether you know the word "sharding" but whether you understand its cost. The interviewer checks whether you distinguish partitioning from sharding, whether you pick a shard key by cardinality and access patterns, whether you remember that a shard runs with replicas, and whether you understand that async replication brings lag and cross-shard operations are expensive.

What interviewers usually check:

The difference between partitioning (one table, one instance) and sharding (data across different instances) and why shard at all.
How to pick a shard key (high cardinality, even load, stable access patterns) and what a bad key costs you.
What a hot key and a hot shard are and how to fight them (split the range, salt the key, cache it, dedicate a shard).
How a query finds its shard (DSN, proxy, a coordinator like Citus) and where routing's bottleneck and point of failure are.
When and how to rebalance shards and why consistent hashing minimizes data movement.
Why cross-shard JOIN, aggregation, and key-less search are expensive and how to avoid them (denormalization, fan-out + merge, a search index).
How replication works (a primary takes writes, replicas serve reads), how async differs from sync, and what replication lag and failover are.
How to choose between SQL and NoSQL by access patterns and consistency and why it is sensible to start with a simple Postgres.
Why to separate OLTP and OLAP and how to stream changes via CDC and Kafka into ClickHouse, S3, and Snowflake.

A typical wrong answer: "sharding is just spreading data across several servers." This triggers a discussion that without replicas a node failure loses data, that a low-cardinality key creates a hot shard, that routing and rebalancing are a separate engineering problem, that a cross-shard JOIN fans out across all shards, that async replication gives stale reads, and that analytics must not run on the production OLTP.

Why it matters

When data stops fitting on one machine, distributed storage begins — and almost every step here has a cost that people forget in interviews. Sharding removes the ceiling on volume and write throughput, but moves the complexity into shard-key selection: a bad key creates a hot shard or forces a cross-shard query on every request. Replication gives read scaling and survival of a node failure, but asynchronous replication brings lag and stale reads. Cross-shard JOIN, aggregation, and key-less search are expensive and easily eat the entire gain from sharding. Whoever shards without replicas, picks a low-cardinality key, pours all analytics into the production Postgres, and reaches for NoSQL with no real reason gets data loss on a node failure, load skew, OLTP degradation under analytics, and a consistency model they did not expect.