NewSQL и выбор хранилища под задачу

Это последний урок теории баз данных. NoSQL-базы купили масштаб ценой транзакций и свободных запросов. Возникает вопрос: можно ли получить и то, и другое, SQL с транзакциями и масштаб на много серверов? В этом уроке ответ на него, а потом практичный порядок, как выбирать хранилище под свою задачу, не утонув в сотне названий.

NewSQL: SQL на многих машинах

Вспомни сеть библиотек из урока про CAP. Каталог поделён на части, и у каждой части несколько копий. NewSQL-базы делают так, чтобы снаружи вся сеть выглядела как одна библиотека: читатель пишет обычный SQL, запускает обычную транзакцию, а система сама разносит данные по зданиям и держит копии в согласии.

NewSQL называют распределённые базы, которые сохраняют SQL и транзакции ACID, но масштабируются на много серверов. Три известных представителя:

• Google Spanner. Описан в статье Google 2012 года, журнальная версия вышла в 2013-м. Работает в дата-центрах по всему миру и, чтобы упорядочивать транзакции, опирается на очень точные часы с атомными и GPS-источниками времени.
• CockroachDB. Открытая база, вдохновлённая Spanner. Говорит по протоколу PostgreSQL, так что к ней подключаются обычными драйверами Postgres.
• YugabyteDB. Тоже совместима с PostgreSQL на уровне запросов и тоже делит данные на части с копиями.

Как они держат копии в согласии? Через консенсус: запись считается принятой, когда её подтвердило большинство копий. CockroachDB и YugabyteDB используют алгоритм Raft. Большинство из трёх копий это две, поэтому одна упавшая копия работу не останавливает.

Цена NewSQL

Чудес нет, теорема CAP никуда не делась. При разрыве сети NewSQL выбирает согласованность: часть, которая не видит большинства копий, перестаёт принимать запись. А в обычный день, по PACELC, платит задержкой: каждая запись ждёт подтверждения от большинства, и если копии в разных городах, это десятки миллисекунд на запись. Транзакция, которая трогает данные в разных частях, дороже транзакции на одном сервере.

Поэтому NewSQL нужен, когда данных и записей действительно больше, чем выдержит один хорошо настроенный сервер с репликами, или когда база обязана пережить потерю целого дата-центра. Для большинства проектов это не так.