CockroachDB обещает единый SQL-интерфейс без ручного шардирования, но эта глава хорошо показывает цену такого обещания: локальность данных, маршрутизацию и задержки никто не отменял.
В реальных системах она помогает думать о размещении диапазонов и владельцев аренды, безопасном повторе транзакций и идемпотентности как о неизбежной части строгой транзакционной модели.
В интервью и архитектурном обсуждении этот материал особенно полезен, когда нужно объяснить, почему команда готова платить дополнительной задержкой и сложностью за строгую консистентность в распределённом SQL.
Практическая польза главы
Локальность диапазонов
Продумывайте размещение диапазонов и владельцев аренды для критичных регионов, чтобы держать задержку в рамках целевого уровня сервиса.
Сериализуемость по умолчанию
Планируйте безопасный повтор транзакций и идемпотентность на уровне приложения из-за строгой транзакционной модели.
Часы и сеть
Учитывайте неопределённость часов и влияние межрегионной сети на задержку записи и пропускную способность.
Защита решения
Объясняйте выбор CockroachDB через требования к распределённому SQL и цену строгой консистентности.
Рамка выбора и редакторский фокус
Фокус главы
диапазонах ключей, владельцах аренды, Raft-репликации и мультирегиональной локальности
Профиль нагрузки
Фокус — транзакционный SQL на горизонтальном и часто региональном масштабе, где один классический узел уже не даёт нужной формы роста.
Когда выбирать
Распределённый SQL оправдан, когда строгие гарантии важнее простоты и команда готова платить задержкой, координацией и эксплуатацией.
Граница и риск
Главные риски — горячие ключи, межрегиональные транзакции, стоимость консенсуса, ребаланс и ложное ощущение бесплатного шардирования.
Связать дальше
Всегда проверяйте решение через базовый вариант PostgreSQL/MySQL, распределённые транзакции и мультирегиональную архитектуру.
Источник
Wikipedia: CockroachDB
История CockroachDB, ключевые релизы и общий технологический контекст распределённой SQL-платформы.
Официальный сайт
CockroachDB Product Overview
Как продукт сам себя позиционирует: отказоустойчивость, горизонтальное масштабирование, локальность данных и нагрузки, под которые он заточен.
CockroachDB — распределённая SQL-СУБД, которая берёт на себя то, что обычно приходится собирать руками: строгую консистентность, переживание отказа целой зоны и рост записи добавлением узлов. В системном дизайне её достают, когда сервис транзакционной обработки (OLTP) должен работать в нескольких регионах, сам переключаться на резерв и оставаться обычным SQL без ручного шардирования в коде приложения. За это платят задержкой на согласование и дисциплиной проектирования — об этом ниже.
здесь означает привычный SQL-интерфейс поверх распределённого хранения, репликации и транзакционной координации — снаружи это одна база, внутри это кластер. Чтобы расти без ручного деления данных в коде, CockroachDB сама режет таблицы на , назначает им и держит копии в согласии через протокол консенсуса Raft.
Дальше всё крутится вокруг нескольких понятий, и каждое стоит денег или задержки: и требуют согласования, и добавляют сетевые проходы, эту задержку возвращает обратно, а под конкуренцией за одни и те же строки приложение обязано пережить .
История и контекст
Формирование идеи проекта
Спенсер Кимбалл публикует первый проект распределённой SQL-системы, позже ставшей CockroachDB.
Основание компании
Создаётся Cockroach Labs для развития продукта как распределённой SQL платформы для отказоустойчивых приложений.
Первый релиз для промышленной эксплуатации
Линейка 1.0 закрывает базовый контур, на котором можно строить продакшн: SQL-интерфейс, транзакционные гарантии и кластерный режим.
Переход на лицензию с доступным исходным кодом
Проект меняет лицензионную модель с Apache 2.0 на Business Source License (BuSL).
Стабильная ветка 25.1
Линия 25.1 смещает акцент на тех, кто уже эксплуатирует кластер в продакшне: производительность, поведение при масштабировании и операционная зрелость.
Ключевые архитектурные элементы
SQL-шлюз и совместимость с PostgreSQL
Запрос принимает любой узел: он говорит на сетевом протоколе PostgreSQL и сам становится шлюзом для распределённого выполнения. Для приложения это означает, что менять драйвер и переписывать запросы не нужно.
Диапазоны ключей, владелец аренды и Raft
Пространство ключей нарезано на диапазоны; за каждый отвечает владелец аренды (leaseholder), а копии держит в согласии протокол консенсуса Raft. Цена этой схемы — лишний сетевой проход, когда нужный диапазон живёт в другом регионе.
Транзакции модели ACID и параллельные фиксации (Parallel Commits)
Транзакционный слой держит строгую консистентность через намерения записи (write intents) и атомарную фиксацию. Параллельные фиксации (Parallel Commits) убирают один сетевой раунд из горячего пути — иначе распределённая запись стоила бы заметно дороже.
Локальность данных и автоматический ребаланс
Кластер сам раскладывает данные по регионам и перебалансирует их при добавлении узлов — ручного шардирования нет. Обратная сторона: если привязка строк к региону задана неудачно, задержку чтения это не уберёт, а добавит.
Модель данных и транзакционный контур
Главный фокус CockroachDB — стык, где привычная SQL-таблица превращается в распределённое хранилище ключ-значение (KV). Интерактивный блок показывает этот переход: диапазоны ключей, реплики, намерения записи, уровни изоляции и настройки локальности.
Модель данных CockroachDB: диапазоны, реплики, транзакции
CockroachDB строит SQL поверх распределённого KV-движка: данные делятся на диапазоны ключей и реплицируются через Raft.
Чем CockroachDB отличается от классической SQL-СУБД на одном узле
- Таблицы и индексы отображаются в распределённое пространство ключей KV, которое автоматически делится на диапазоны.
- У каждого диапазона есть реплики; владелец аренды координирует чтения и записи.
- Транзакции используют намерения записи, таблицу блокировок и протокол атомарной фиксации Parallel Commits.
- Настройки локальности помогают размещать данные по регионам и снижать задержку для чувствительных сценариев.
SQL -> пространство ключей KV
Строки таблиц и записи вторичных индексов хранятся как пары ключ-значение в едином глобальном пространстве ключей.
Ключевые элементы
Типичные сценарии
- Горизонтальный рост
- Изоляция горячих ключей
- Разбиение больших таблиц
Пример
CREATE TABLE orders (
id UUID PRIMARY KEY,
tenant_id UUID,
status STRING,
created_at TIMESTAMPTZ
);Архитектура CockroachDB по слоям
Чтобы понять, где возникает задержка, базу удобно разложить на слои: SQL-шлюз, транзакционный слой, распределение диапазонов, репликация через протокол консенсуса Raft и хранение с учётом локальности. Каждый слой добавляет свой шаг на пути запроса.
Системный контур
Профиль нагрузки
Эксплуатационная цена
Пути чтения и записи через компоненты
Здесь видно, откуда берётся стоимость каждого запроса: путь от SQL-шлюза через маршрутизацию по диапазонам, владельца аренды, консенсус Raft и до фиксации транзакции. Чем больше шагов уходит в другой регион, тем дороже операция.
Путь чтения и записи
Интерактивный разбор прохождения CockroachDB-запросов через SQL-шлюз, владельца аренды, Raft и транзакционный слой.
Путь записи
- Таблицы и индексы разбиваются на диапазоны; ключи транзакции определяют, потребуется ли один диапазон или несколько.
- Записи сначала оформляются как намерения записи: предварительные значения с семантикой блокировки.
- Фиксация требует большинства Raft-реплик для каждого затронутого диапазона и координации в транзакционном слое.
- При конкуренции за одни и те же данные возникают ошибки для повтора; приложение должно корректно повторять транзакции.
Когда выбирать CockroachDB
Хорошо подходит
- Критичная транзакционная обработка (OLTP), где потеря зоны или региона недопустима, а данные обязаны оставаться консистентными по модели ACID.
- Продукты, у которых нагрузка растёт, и расширять чтение и запись хочется добавлением узлов, а не очередным раундом ручного шардирования.
- Глобальные SaaS- и финтех-сценарии: данные нужно держать ближе к пользователю, переживать отказ региона и не терять доступность.
- Команда готова вложиться в проектирование схемы, индексов и ключей и тянуть эксплуатацию распределённого SQL-кластера — без этого преимущества не раскрываются.
Стоит избегать
- Одноузловое приложение, которому хватает классической локальной SQL-СУБД, — распределённый слой здесь только дороже и сложнее.
- Тяжёлые аналитические сканы: под них нужен специализированный движок аналитической обработки (OLAP), а не транзакционная база.
- Приложение, которое не умеет повторять транзакцию при конкуренции за одни и те же строки, — повторы здесь часть нормальной работы, а не сбой.
- Нет людей и инструментов, чтобы эксплуатировать многоузловую инфраструктуру и наблюдать за распределённым слоем — кластер тихо станет чёрным ящиком.
Практика: DDL и DML
От теории к коду: примеры SQL-операций для CockroachDB. DDL задаёт схему, индексы и мультирегиональные настройки, DML показывает транзакции, UPSERT и конкурентный доступ к одним и тем же строкам — там, где и появляются повторы.
Примеры DDL и DML в CockroachDB
DDL управляет схемой и индексами, DML — транзакциями, чтением и записью данных.
CockroachDB поддерживает онлайн-изменения схемы и PostgreSQL-совместимый SQL DDL, но проектирование ключей и индексов критично для распределённого выполнения.
Создание таблицы с первичным ключом
CREATE TABLEПервичный ключ определяет распределение записей по пространству ключей и диапазонам.
CREATE TABLE accounts (
id UUID PRIMARY KEY,
tenant_id UUID NOT NULL,
balance DECIMAL(18,2) NOT NULL,
status STRING NOT NULL,
created_at TIMESTAMPTZ NOT NULL DEFAULT now()
);Покрывающий вторичный индекс
CREATE INDEX ... STORINGСнижает число лишних поисков для горячих точек чтения.
CREATE INDEX idx_accounts_tenant_status
ON accounts (tenant_id, status)
STORING (balance, created_at);Региональная настройка БД
ALTER DATABASE ... REGIONМультирегиональные возможности SQL помогают управлять локальностью и устойчивостью между регионами.
ALTER DATABASE appdb PRIMARY REGION "us-east1";
ALTER DATABASE appdb ADD REGION "eu-west1";
ALTER DATABASE appdb ADD REGION "ap-southeast1";Связанные главы
- Фреймворк выбора СУБД - Где провести границу: когда распределённый SQL CockroachDB окупает свою цену по консистентности и масштабированию, а когда стоимость владения её перевешивает.
- PostgreSQL: история и архитектура - С чем сравнивать: классический одноузловой контур транзакционной обработки (OLTP) в PostgreSQL рядом с распределённой SQL-моделью CockroachDB — видно, за что платишь и что получаешь взамен.
- YDB: распределённая SQL-СУБД и архитектура - Две распределённые SQL-платформы бок о бок: где расходятся их мультирегиональные возможности, транзакционные гарантии и то, чего они стоят в эксплуатации.
- Распределённые транзакции: двухфазная и трёхфазная фиксация - Что происходит под капотом фиксации: как координируется распределённая транзакция и чем за это платит путь записи в задержке и доступности.
- Мультирегиональные и глобальные системы - Геораспределённый дизайн на практике: как локальность данных и отказоустойчивость между регионами тянут задержку в разные стороны и где приходится выбирать.
- Jepsen и модели консистентности - Заявленные гарантии и реальные — разные вещи: как проверять консистентность распределённой БД под отказами сети и узлов и не верить документации на слово.
