Google запустила бета-версию Cloud Spanner — СУБД поколения NewSQL



    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, ведь кроме официальной документации у нас пока нет информации об этом уникальном сервисе.
    Support the author
    Share post

    Similar posts

    Comments 22

      +6
      Интересно, для госструктур США сразу интерфейс предусмотрен? )
        0
        По любому, корпорация добра же. Вот только если где-то добра прибыло где-то его убыло…

        ЗЫ ну конечно же мы(google) не предоставляем данные 3м лицам.
          –4
          Так если мне память не изменяет венчурный фонд ЦРУ In-Q-Tel — был инвестором № 2 в google или это они в Фейсбук вторыми вложились?
          Любопытно, насколько эффективны ЦРУшники как инвесторы? И можно ли, вложится в их фонд?
            0
            Про венчурные фонды не помню сейчас как кто назывался, но гугл был одним из оборонных стартапов. Его финансировали структуры подконтрольные DARPA.

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

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

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

          +2
          Скорее всего, есть ещё ошибки, но всё же…
          image
            0
            Очень интересно в работе было бы её увидеть, но думаю, что это очень дорогое удовольствие будет… к сожалению.
              0
              $0.90 per node per hr + $0.30 per GB per month. $650 за ноду в месяц + сторадж не особо дорогой
                0
                + за трафик :(
                " Оплата за трафик внутри региона не взимается, между регионами США — $0,01 за гигабайт, между странами — от $0,08 до $0,12 за гигабайт, в Китай — от $0,20 до $0,23 за гигабайт, в Австралию — от $0,15 до $0,19 за гигабайт."
                  0
                  Ну иметь OLTP базу в одном регионе, а апп-сервера в другом это достаточно странно. Тормозить будет нещадно.
              0
              Молодцы. Введение своего абсоютного-точного времени для такой задачи интересная мысль, теоретически проблему для таких БД может создать только размещение каких то её отдельных датацентров на другой планете)
                +1
                «абсоютного-точного времени» — не существует, все относительно.
                  0
                  В том-то и суть ;)
                –9
                Откуда максимальный простой в 31.5 секунд?
                Если аптайм 99,9999%, то максимальный простой — 0,0001%
                365 дней * 24 часов * 3600 секунд в часе * 0,0001 = 3153,6 секунд простоя в год или 52,5 минут
                  –3
                  Раз в четыре года и того больше. А по цифрам судя по всему кто-то ошибся на два порядка или в аптайме или когда считал.
                    +8
                    Необходимо ещё на 100 поделить, чтобы проценты в дробь перевести.
                      +3
                      0,0001% = 0.000001
                        –1
                        удалено
                        –1
                        Защита от роскомнадзора предусмотрена?
                          +1
                          Если интервалы TTinterval двух конкурентных транзакций не пересекаются, то можно с уверенностью сказать, какая из них произошла раньше. Если они пересекаются, это означает некоторую долю неопределённости.

                          На самом интересном месте не хватает подробностей — так что делать с этой неопределённостью? Так-к то и без атомных часов можно строить интервалы, только они будут гораздо больше и, соответственно, чаще будут перескаться, принципиальной разницы нет.
                            +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).
                            0
                            SQL-синтаксис традиционных СУБД без ущерба для горизонтального масштабирования

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

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

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

                            Only users with full accounts can post comments. Log in, please.