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

Несколько лет Google использовала этот сервис исключительно для внутренних нужд. На нём работают ключевые системы Google, в том числе AdWords и Google Play. Spanner — эволюционное развитие NoSQL-предшественника Google Bigtable. Сам же c Spanner относят к семейству NewSQL-решений, то есть оно сочетает в себе преимущества реляционных и нереляционных СУБД. Это ACID-транзакции и SQL-синтаксис традиционных СУБД без ущерба для горизонтального масштабирования и высокой доступности, присущих NoSQL.

Исходя из опыта работы системы внутри компании, Google предлагает клиентам аптайм 99,9999% (шесть девяток, то есть максимум 31,5 секунды простоя в год), клиентские библиотеки с поддержкой Java, Go, Python, Node.js и др.

Принцип работы Spanner описан в научной работе James C. Corbett, Jeffrey Dean, Michael Epstein, Andrew Fikes, Christopher Frost, JJ Furman, et al. Spanner: Google’s Globally-Distributed Database. Proceedings of OSDI, 2012. См. также описание Spanner на Хабре (2013).



Спустя несколько лет внутреннего использования Google приняла решение выкатить этот инфраструктурный сервис во всеобщее пользование. Оформить подписку предлагают корпоративным клиентам, которым нужно развернуть высоконадёжное отказоустойчивое облачное приложение. Раньше им приходилось выбирать между традиционными БД с гарантированной согласованностью транзакций и базами NoSQL с простым управлением, горизонтальным масштабированием и распределённым хранением данных. Сервис Cloud Spanner призван устранить эти противоречия, объединив все преимущества обеих технологий.


Cloud Spanner завершает линейку сервисов БД в облаке Google Cloud Platform (GCP), дополняя Cloud SQL, Cloud Datastore и Cloud Bigtable.

В Cloud Spanner нет теоретического предела на максимальный размер базы. В то же время этот сервис можно использовать и для маленьких проектов. Основное преимущество здесь — не только масштабируемость, но и возможность осуществлять глобальные транзакции одновременно во всех дата-центрах по всему миру.

Стоимость использования сервиса Cloud Spanner установлена в размере $0,90 за узел в час и $0,30 за один гигабайт занятого дискового пространства в месяц. Оплата за трафик внутри региона не взимается, между регионами США — $0,01 за гигабайт, между странами — от $0,08 до $0,12 за гигабайт, в Китай — от $0,20 до $0,23 за гигабайт, в Австралию — от $0,15 до $0,19 за гигабайт.

Ключевая инновация в Spanner


На Хабре публиковалась статья, почему Google пришлось отказаться от NTP (Network Time Protocol) и внедрить собственную систему проверки времени с GPS и атомными часами, более точную и надёжную. Её назвали TrueTime API. Внедрение такой системы необходимо было для обеспечения целостности базы данных Google Spanner.

Обеспечение цельности данных за счёт новой системы кодирования информации о времени транзакций — одна из ключевых инноваций Spanner (так указано в вышеупомянутой научной работе). Инженеры Google разработали многоуровневую систему проверки времени, записи временных интервалов транзакций и оценки уровня надёжности меток о времени. Это ключевой фактор, от которого зависит надёжность системы.

Вместо приёма данных с внешних часов, компания Google оборудовала дата-центры собственными атомными часами и ресиверами GPS. Это оборудование подключено к некоторым серверам, которые раздают метки времени всем остальным серверам в дата-центре. По факту, на каждой машине в дата-центре работает в фоновом режиме демон, который постоянно опрашивает сервер времени в своём дата-центре и аналогичные серверы времени в других дата-центрах. Таким образом, серверы Google во всём мире гарантированно работают на одном времени.


Через Google TrueTime API обеспечивается синхронизация данных, когда разные дата-центры пытаются одновременно записать в одну и ту же ячейку в БД. Интерфейс TrueTime API выдаёт значение интервала времени TTinterval: это время с заложенной погрешностью измерения и неопределённостью. Если интервалы TTinterval двух конкурентных транзакций не пересекаются, то можно с уверенностью сказать, какая из них произошла раньше. Если они пересекаются, это означает некоторую долю неопределённости.

Соблюдение CAP-теоремы


Spanner совмещает свойства реляционных и нереляционных СУБД, не нарушая при этом CAP-теорему. как такое стало возможным — объясняет автор CAP-теоремы Эрик Брюер, ранее профессор Калифорнийского университета, а ныне вице-президент Google по инфраструктуре.



Бета-версию Cloud Spanner уже некоторое время используют избранные партнёры. Например, о своём опыте рассказал инженер компании Quizlet. Это интересный взгляд изнутри на интерфейс и протоколы Spanner, ведь кроме официальной документации у нас пока нет информации об этом уникальном сервисе.
Поделиться с друзьями
-->

Комментарии (22)


  1. Kassab
    15.02.2017 13:07
    +6

    Интересно, для госструктур США сразу интерфейс предусмотрен? )


    1. unet900
      15.02.2017 17:30

      По любому, корпорация добра же. Вот только если где-то добра прибыло где-то его убыло…

      ЗЫ ну конечно же мы(google) не предоставляем данные 3м лицам.


    1. wikipro
      15.02.2017 17:53
      -4

      Так если мне память не изменяет венчурный фонд ЦРУ In-Q-Tel — был инвестором № 2 в google или это они в Фейсбук вторыми вложились?
      Любопытно, насколько эффективны ЦРУшники как инвесторы? И можно ли, вложится в их фонд?


      1. unet900
        16.02.2017 07:32

        Про венчурные фонды не помню сейчас как кто назывался, но гугл был одним из оборонных стартапов. Его финансировали структуры подконтрольные DARPA.

        Поищите в поиске «Дмитрий Перетолчин гугл» ну и интервью Игоря Ашманова

        ЗЫ ну и ожидаемо сейчас меня заклеймят как конспиролога полюбому. Этого не может быть так как такого быть не может…


        1. Shirasik
          16.02.2017 15:28

          Так вся силиконовая долина — это одна большая DARPA-кормушка, никто этого и не скрывает)


  1. Jemdo
    15.02.2017 13:41
    +2

    Скорее всего, есть ещё ошибки, но всё же…
    image


  1. delef
    15.02.2017 13:41

    Очень интересно в работе было бы её увидеть, но думаю, что это очень дорогое удовольствие будет… к сожалению.


    1. le1ic
      15.02.2017 15:22

      $0.90 per node per hr + $0.30 per GB per month. $650 за ноду в месяц + сторадж не особо дорогой


      1. wikipro
        15.02.2017 18:01

        + за трафик :(
        " Оплата за трафик внутри региона не взимается, между регионами США — $0,01 за гигабайт, между странами — от $0,08 до $0,12 за гигабайт, в Китай — от $0,20 до $0,23 за гигабайт, в Австралию — от $0,15 до $0,19 за гигабайт."


        1. le1ic
          15.02.2017 19:02

          Ну иметь OLTP базу в одном регионе, а апп-сервера в другом это достаточно странно. Тормозить будет нещадно.


  1. heleo
    15.02.2017 14:14

    Молодцы. Введение своего абсоютного-точного времени для такой задачи интересная мысль, теоретически проблему для таких БД может создать только размещение каких то её отдельных датацентров на другой планете)


    1. delef
      15.02.2017 15:45
      +1

      «абсоютного-точного времени» — не существует, все относительно.


      1. heleo
        15.02.2017 15:58

        В том-то и суть ;)


  1. zipo
    15.02.2017 15:06
    -9

    Откуда максимальный простой в 31.5 секунд?
    Если аптайм 99,9999%, то максимальный простой — 0,0001%
    365 дней * 24 часов * 3600 секунд в часе * 0,0001 = 3153,6 секунд простоя в год или 52,5 минут


    1. heleo
      15.02.2017 15:10
      -3

      Раз в четыре года и того больше. А по цифрам судя по всему кто-то ошибся на два порядка или в аптайме или когда считал.


    1. romka777
      15.02.2017 15:13
      +8

      Необходимо ещё на 100 поделить, чтобы проценты в дробь перевести.


    1. le1ic
      15.02.2017 15:13
      +3

      0,0001% = 0.000001


    1. marenkov
      15.02.2017 15:22
      -1

      удалено


  1. Maa-Kut
    15.02.2017 17:29
    -1

    Защита от роскомнадзора предусмотрена?


  1. PQR
    15.02.2017 23:35
    +1

    Если интервалы TTinterval двух конкурентных транзакций не пересекаются, то можно с уверенностью сказать, какая из них произошла раньше. Если они пересекаются, это означает некоторую долю неопределённости.

    На самом интересном месте не хватает подробностей — так что делать с этой неопределённостью? Так-к то и без атомных часов можно строить интервалы, только они будут гораздо больше и, соответственно, чаще будут перескаться, принципиальной разницы нет.


    1. sumerman
      17.02.2017 13:11
      +2

      Всё именно так. Люди не до конца разобравшись пишут статьи на хабр или ещё куда-нибудь. TrueTime сообщает время + неопределёность, Spanner всегда сериализует транзакции, чтобы интервалы не пересекались. Если они всё таки пересекаются система просто ждёт. GPS нужно чтобы ждать меньше.

      Например практически одновременно с анонсом выпустили статью (на котору даже ссылка в тексте есть) за авторством небезывестного Эрика Брюэра (автор CAP-теоремы). Там прямым текстом:

      Many assume that Spanner somehow gets around CAP via its use of TrueTime, which is a service that enables the use of globally synchronized clocks. Although remarkable, TrueTime does not significantly help achieve...

      One subtle thing about Spanner is that it gets serializability from locks, but it gets external consistency (similar to linearizability) from TrueTime. Spanner’s external consistency invariant is that for any two transactions, T1 and T2 (even if on opposite sides of the globe):
      if T2 starts to commit after T1 nishes committing, then the timestamp for T2 is greater than the timestamp for T1

      Spanner’s use of TrueTime as the clock ensures the invariant holds. In particular, during a commit, the leader may have to wait until it is sure the commit time is in the past (based on the error bounds).


  1. http3
    16.02.2017 11:31

    SQL-синтаксис традиционных СУБД без ущерба для горизонтального масштабирования

    Причина не в синтаксисе, а в реляционности…

    А NoSQL на самом деле не «без SQL», а без реляционности.

    Вот такой мир. :)