Семь актов: от CREATE TABLE до Citus

День 0 в SaaS-стартапе. PM просит «поиск пользователей по email». Один инженер, один Postgres, одна таблица. Три года спустя: миллиард строк, шесть шардов Citus и runbook размером с учебник. Между этими двумя точками — семь моментов, когда база ломалась, а команда училась.

Семь пьес этой главы отображаются один к одному на семь актов роста продукта. У каждого акта есть триггер, симптом и рычаг. Пропусти рычаг — следующий акт обойдётся дороже.

Акт 1 — День 0, проектирование схемы. «users(email, name, org_id).» Должен ли email быть UNIQUE? Должен ли org_id быть foreign key? Должен ли prefs быть отдельной таблицей или JSONB? Решения: email — это UNIQUE NOT NULL CITEXT. org_id — это BIGINT REFERENCES orgs(id) ON DELETE CASCADE. prefs — это JSONB с GIN-индексом, когда поиск потребует. Суррогатный id BIGSERIAL изолирует от изменений email. Нарушай правило только под давлением throughput, никогда по умолчанию.

Акт 2 — Неделя 1, 10K строк, первый медленный запрос. Email-search endpoint p95 растёт с 30 мс до 800 мс. Планировщик делает sequential scan. CREATE INDEX users_email_idx ON users(email). Правило leading-column у B-tree означает WHERE email = ? разрешается двумя page reads. p95 падает до 4 мс.

Акт 3 — Месяц 1, 100K строк, планировщик врёт. Половина запросов быстрые, половина — 600 мс. EXPLAIN ANALYZE показывает: планировщик иногда выбирает seq-scan несмотря на индекс. Row estimate ошибается на 30×: stale statistics. ANALYZE users; перестраивает гистограммы. Планировщик выбирает планы из статистики, не из данных; поддержка статистики — это операционная дисциплина.

Акт 4 — Месяц 6, тихий bloat. Nightly report runner держит одну транзакцию открытой четыре часа. VACUUM не может вернуть мёртвые tuples ниже xmin-горизонта. Таблица users вздулась с 200 MB до 80 GB. Исправление: убить long transaction, установить idle_in_transaction_session_timeout = 60s, запустить pg_repack для возврата диска. Постоянное исправление: реплицировать на read replica для отчётов.

Акт 5 — Год 1, 1M пользователей + 50 app pods, connection storm. Каждый pod открывает свой Postgres backend на cold-start. На pod-rollout кластер видит 1000 concurrent backends; kernel scheduler трасится; запросы по 4 мс занимают 4 с. PgBouncer в transaction-mode: 100 server-side backends, 10000 client connections мультиплексированы. Правило размера: pool_size = active_concurrent_transactions × safety_factor, не max_app_workers.

Акт 6 — Год 2, миграция, которая заморозила prod. День мультитенантности. ALTER TABLE users ADD COLUMN tenant_id BIGINT NOT NULL DEFAULT 0 берёт AccessExclusiveLock и триггерит полную перезапись таблицы. Prod замерзает на восемь минут. Рецепт expand-contract: добавить nullable column, backfill батчами, add CHECK ... NOT VALID, VALIDATE CONSTRAINT, SET NOT NULL, drop check.

Акт 7 — Год 3, 1B строк, hot shard. Citus развёрнут, shard key — tenant_id. Tenant Acme даёт 40% всех запросов. Шард Acme насыщен, остальные простаивают. Исправление: co-location связанных таблиц на том же shard key; онлайн-решардинг через citus_rebalance_table_shards.

Почему порядок важен.

База под растущим продуктом — это как растущий город. Схема — зонирование. Индексы — карта улиц. Execution plans — диспетчер трафика. MVCC — несколько полос, чтобы машины проезжали без столкновений. Connection pool — парковка. Миграции — строительные бригады, которые не должны закрывать все дороги сразу. Шардирование — присоединение новых районов, когда один квартал не справляется с трафиком. Пропущенный урок означает: город растёт, но не тот слой перегружен.

Каждый акт открывает следующий только если предыдущий пройден правильно. Пропусти Акт 1 (схема) — Акты 2–7 воюют с неэффективными join-ами. Пропусти Акт 2 (индексы) — решения Акта 3 принимаются вслепую. Пропусти Акт 3 (статистика) — единственный рычаг Акта 4 это vacuum. Пропусти Акт 4 (bloat) — потоки пула Акта 5 видят замедляющиеся table scans. Пропусти Акт 5 (пул) — миграции Акта 6 задыхаются от connection storms. Пропусти Акт 6 (lock safety) — шардирование Акта 7 невозможно. Порядок — это ограничение, наложенное физикой и внутренностями Postgres.