Google выложил статью о Spanner – глобально распределённой СУБД, которую компания готовит к публикации на OSDI 2012. Документ описывает систему, которая обслуживает рекламную платформу F1 и хранит данные в дата-центрах по всему миру. Главное в нём – не масштаб, а заявка: Spanner даёт транзакции с внешней согласованностью поверх данных, разнесённых на тысячи километров. До сих пор инженеры считали такое сочетание практически недостижимым. Разберём, какие идеи стоит забрать в работу уже сейчас.

TrueTime: время как сервис

Ключевой приём Spanner – API под названием TrueTime. Вместо одной отметки времени он возвращает интервал, в котором гарантированно лежит реальное время. Под капотом – атомные часы и GPS-приёмники в каждом дата-центре, опрашиваемые отдельными серверами времени. Система не делает вид, что часы синхронны идеально; она измеряет и явно фиксирует погрешность.

Дальше Spanner назначает транзакциям временные метки и просто ждёт, пока интервал неопределённости пройдёт, прежде чем зафиксировать результат. Это так называемая «commit wait» – задержка в несколько миллисекунд в обмен на строгий порядок транзакций по всей планете. Идея простая и честная: если не можешь убрать неопределённость во времени, измерь её и дождись, пока она перестанет влиять на корректность.

Вывод для прикладных систем шире самого Spanner. Рассинхрон часов между серверами – недооценённый источник ошибок. В биллинге, журналах аудита и финансовых проводках расхождение в секунды искажает порядок событий и ломает разбор инцидентов. Дисциплина NTP, фиксация погрешности и отказ от слепого доверия now() – то, что внедряемо в любой архитектуре, без атомных часов.

Цена согласованности никуда не делась

Spanner не отменяет теорему CAP и компромиссы распределённых систем – он их оплачивает. Внешняя согласованность стоит реальных денег: оборудование точного времени, ожидание на коммите, синхронная репликация через Paxos между регионами. Google может позволить себе такую инфраструктуру; большинству заказчиков она не нужна и не по карману.

Практический урок – считать требования к согласованности по бизнес-смыслу, а не по умолчанию. Каталог товаров и аналитические витрины спокойно живут на eventual consistency. Остаток на счёте, статус заявки в госуслуге, результат голосования – нет. Когда мы проектировали защищённый портал для избирательной кампании, именно строгий порядок и неоспоримость записей определяли выбор хранилища, а не пропускная способность.

Что забрать в проекты сегодня

Spanner – исследовательская система Google, недоступная как продукт. Но три идеи применимы уже сейчас в любом проекте, где данные превращаются в аналитику и отчётность.

Первое: делайте неопределённость явной. Метки времени, версии записей и границы погрешности должны быть в данных, а не в голове разработчика. Второе: разделяйте контуры по уровню согласованности. Строгие транзакции – для денег и юридически значимых действий; ослабленные гарантии – для остального. Это снижает нагрузку и стоимость без потери корректности там, где она критична.

Третье: помните про регуляторику. Глобальная репликация Spanner означает, что данные физически лежат в разных странах. Для российского бизнеса и госсектора это прямой конфликт с требованиями к хранению персональных данных по 152-ФЗ. Любая распределённая СУБД должна позволять привязать размещение данных к юрисдикции – иначе она непригодна для значительной части наших задач.

Вывод

Spanner ценен не как готовое решение, а как набор честных инженерных приёмов: измеряй время, плати за согласованность осознанно, разделяй данные по требованиям. Эти принципы работают на любом масштабе – от одного сервера до распределённого кластера. Архитектуру всегда диктует бизнес-смысл данных, а не мода на технологию.