Базы данных
NewSQL: лучшее из двух миров
2010-е: компании бежали от PostgreSQL к Cassandra и MongoDB ради масштаба, жертвуя ACID. Потом писали сложную логику idempotency и reconciliation чтобы компенсировать потерю транзакций. Google внутри построил Spanner - масштаб NoSQL + гарантии SQL. CockroachDB сделал это доступным для всех.
- **Google Ads**: Spanner обрабатывает миллиарды транзакций в день с глобальной consistency через TrueTime API
- **Comcast**: CockroachDB для billing системы - 10M транзакций/день, мульти-регион failover без DBA intervention
- **Bilibili**: TiDB заменил 100+ шардированных MySQL таблиц - убрали application-level sharding логику
NewSQL: мотивация и история
NewSQL возник как ответ на false dichotomy 2000-х: NoSQL (масштабируемость, без ACID) vs SQL (ACID, плохо шардируется). NewSQL предлагает горизонтальное масштабирование NoSQL с ACID гарантиями SQL. Ключевые представители: Google Spanner (2012, внутренний), CockroachDB (2015, open source Spanner-inspired), TiDB (2017, open source).
Google Spanner обслуживает Google Ads - одну из крупнейших транзакционных баз данных в мире. Spanner использует TrueTime API (атомарные часы + GPS) для глобальной согласованности без координационного сервера. CockroachDB создан бывшими инженерами Google, вдохновлёнными Spanner.
Что принципиально отличает NewSQL от NoSQL при масштабировании?
CockroachDB: архитектура
CockroachDB автоматически шардирует данные на ranges (~64MB), каждый range реплицируется через Raft на 3+ нодах. При отказе ноды Raft автоматически переизбирает лидера - failover без участия оператора. CockroachDB совместим с PostgreSQL wire protocol: большинство PostgreSQL клиентов работают без изменений.
Comcast использует CockroachDB для billing системы - 10M транзакций/день с мульти-регионным развертыванием для disaster recovery. CockroachDB автоматически балансирует нагрузку: если одна нода перегружена, ranges мигрируют на другие ноды без downtime.
CockroachDB хранит данные ranges на 3 нодах через Raft. Что произойдёт если одна из трёх нод упадёт?
TiDB: MySQL-совместимый NewSQL
TiDB (PingCAP, 2017) - MySQL-совместимый distributed SQL. Архитектура разделена: TiDB (stateless SQL layer), TiKV (distributed key-value storage), PD (Placement Driver - координатор). TiKV использует RocksDB для локального хранения и Raft для репликации. TiFlash - колоночный replica для аналитики.
Xiaomi, Bilibili, Shopee (Sea Group) используют TiDB в production. Bilibili мигрировал 100+ шардированных MySQL таблиц в единый TiDB кластер - убрали application-level sharding логику. TiDB совместим с MySQL 5.7 protocol - миграция без изменения кода приложения.
В чём суть HTAP (Hybrid Transactional/Analytical Processing) в TiDB?
Google Spanner: глобально распределённый SQL
Google Spanner (2012) - планетарно масштабируемая реляционная БД. Ключевая инновация: TrueTime API - атомарные часы + GPS receivers в каждом дата-центре. Это позволяет Spanner назначать глобально монотонные timestamp без coordinator server. External consistency: транзакции линеаризуемы глобально, как будто всё происходит на одном сервере.
Google Ads, Google Pay, Gmail используют Spanner внутри Google. Cloudflare использует Spanner через Google Cloud для хранения DNS записей миллионов доменов с глобальной consistency. Spanner публично доступен как Cloud Spanner с 99.999% SLA для мульти-регион конфигурации.
Зачем Google Spanner использует атомарные часы (TrueTime) для транзакций?
Компромиссы Distributed SQL
NewSQL не серебряная пуля. Cross-shard транзакции через 2PC имеют latency в 10-100x выше локальных. Аналитические запросы на distributed data часто медленнее специализированных OLAP систем. Операционная сложность выше монолитной БД. CAP теорема: при network partition NewSQL выбирает consistency, жертвуя availability.
Benchmarks 2023 от Kyle Kingsbury (Jepsen): CockroachDB и TiDB прошли тесты на correctness под network partitions. Но throughput для single-region OLTP в 3-5x ниже PostgreSQL из-за Raft overhead. NewSQL - правильный выбор для мульти-регион и auto-scaling, не для максимального single-node performance.
NewSQL (CockroachDB, TiDB) всегда быстрее PostgreSQL - это же 'новое поколение'
NewSQL быстрее PostgreSQL при необходимости горизонтального масштабирования и мульти-регион, но медленнее для single-region OLTP из-за Raft overhead
PostgreSQL оптимизирован для single-node performance на протяжении 30 лет. CockroachDB добавляет distributed consensus (Raft) которая неизбежно стоит latency. Trade-off: PostgreSQL для performance, CockroachDB для scale-out и availability.
Почему мульти-регион транзакция в CockroachDB занимает 150-200ms?
Итоги
- **NewSQL = ACID + horizontal scale** - достигается через Raft консенсус для транзакций и автоматическое шардирование
- **TrueTime (Spanner)** - атомарные часы для глобально монотонных timestamp без coordinator; устраняет distributed time проблему
- **Компромисс** - cross-shard и мульти-регион транзакции 10-150x медленнее local; NewSQL не замена PostgreSQL для single-region high-performance
Связанные темы
NewSQL строится на концепциях распределённых систем:
- Репликация — CockroachDB и TiDB используют Raft (вариант Paxos) для репликации ranges - то же что и etcd и Kafka
- Шардинг — NewSQL автоматизирует application-level sharding: ranges мигрируют автоматически при дисбалансе нагрузки
- LSM-Tree — TiKV (хранилище TiDB) использует RocksDB (LSM-Tree) для локального хранения на каждой ноде
Вопросы для размышления
- Компания использует шардированный MySQL с application-level sharding логикой. Стоит ли мигрировать на TiDB? Какие риски и преимущества?
- Spanner гарантирует external consistency через TrueTime. Что произойдёт если GPS сигнал в одном дата-центре потерян на несколько минут?
- CockroachDB в мульти-регион конфигурации: как настроить geo-partitioning так чтобы EU запросы всегда обслуживались EU репликой с минимальным latency?