Google spanner что это

bannerbanner

Non progredi est regredi. Не идти вперед — значит, идти назад. Древние, изрекая эту универсальную мудрость, конечно же, предвидели, что применима она будет и спустя века. Так и вышло.

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

Проверенное временем и успешной эксплуатацией в десятках сервисов NoSQL-решение Bigtable оказалось неспособно справиться с главным требованием, предъявляемым Google+, — непротиворечивостью пользовательских данных, тысячи копий которых разбросаны по сотням тысяч серверов Google.

Хранилище Bigtable просто не имело механизмов, обеспечивающих абсолютную упорядоченность во времени действий над репликами пользовательских данных Google+. Механизмов, которые отлично работают в реляционных СУБД, поддерживающих концепцию ACID по отношению к выполнению распределённых SQL-транзакций.

Cloud Spanner in a minute

Именно поэтому Google пришлось сделать ещё один шаг вперёд, вступив на заполненную конкурентами площадку SQL-решений. Но новый путь — потому и новый, что идёт в стороне от проторённых дорог. И детище поискового гиганта — распределённое хранилище Spanner, анонсированное в 2012 году, — именно новое, поскольку относится к решениям NewSQL.

NewSQL — масштабируемость системы и непротиворечивость данных в одной упряжке

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

Google Spanner, конечно, не единственное NewSQL-решение, но однозначно самое масштабное, а уникальная архитектура делает его особенно интересным.

Архитектурным предком Spanner, безусловно, является Bigtable, от которой новичок унаследовал принцип разделения таблиц на таблеты и распределение их по множеству span-серверов.

Данные, хранящиеся в Spanner, как и в Bigtable, поддерживают мультиверсии благодаря временным меткам (timestamps), однако сама таблица Spanner не является плоской, а основывается на информационно-логической модели и поддерживает SQL-запросы. Такое гибридное решение дает право именовать Spanner полуреляционной системой управления данными.

Архитектура кластера Spanner настолько масштабна, что именуется Вселенной (Universe). В ее «галактиках» Zones обитают множество span-серверов, способных обрабатывать SQL-запросы.

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

What is Cloud Spanner?

Вот простой пример. Предположим, один из пользователей Google+ решает исключить из своего списка друзей другого пользователя. Это не было бы проблемой, если бы таблицы со списками хранились в единственном экземпляре, но увы: социальная сеть устроена куда сложнее. Spanner создаёт многочисленные реплики данных пользователей в сотнях географически распределенных ЦОДов. Наличие реплик — залог быстрого доступа пользователей социальной сети к информации друзей из разных стран, но из-за них простое изменение списка друзей выливается в необходимость синхронно модифицировать многочисленные копии данных, разбросанные по всему свету.

Одно дело, если база данных пользователей социальной сети работает на одном кластере Google. И совсем другое — когда реплики этой базы разбросаны по множеству тысяч кластеров в сотнях ЦОДов. Непротиворечивость данных в этих репликах становится серьёзной проблемой.

Каким образом Spanner справляется с этой проблемой? С помощью специального программного интерфейса, именуемого TrueTime API (от английского true time — «истинное время»).

Как найти одинаковые значения в Гугл таблицах в двух столбцах

Настенные часы и мастера Армагеддона на службе строгой непротиворечивости

В основе TrueTime API лежит концепция единого времени, действующего в рамках всего хранилища Spanner, распределённого по нескольким дата-центрам. Оно называется global wall-clock time — «глобальные настенные часы», общие для всех дата-центров.

Глобальное время в Spanner, конечно же, хранится не в одном месте. Оно тоже распределено. В составе каждого ЦОДа выделяются специальные серверы, именуемые «мастерами времени» (Time Master Devices — TMD).

Большинство из них получает сигналы точного времени от спутниковой системы GPS, однако для надёжности (мало ли что может случиться со спутниковым каналом в самый ответственный момент) в числе TMD есть особые экземпляры, которые называются «мастерами Армагеддона» (Armageddon Masters). Эти «часовщики» несут на своем борту… точнейшие атомные часы. И даже это не всё. Все сервера TMD постоянно синхронизируют время, общаясь друг с другом с помощью специального сервиса timeslave. Вот уж воистину TrueTime.

Чтобы библиотека TrueTime могла вернуть каждому из Span-серверов точное глобальное время, в состав Spanner включены «мастера времени» — узлы, связанные с системой GPS и даже использующие собственные атомные часы.

Глобальное время в TrueTime API не так уж и глобально. Правильнее будет назвать его временем с ограниченной неопределённостью. Почему? В распределённой системе практически невозможно добиться мгновенного отклика всех узлов «здесь и сейчас». Поэтому функция TT.now() библиотеки TrueTime возвращает значение времени в виде интервала (TT.now().latest — TT.now().earliest), учитывающего неизбежную погрешность.

Таким образом, вызов любым узлом Spanner функции TT.now() приводит к возвращению текущего глобального времени, но в виде временного интервала.

Наличие этого временного зазора и позволяет узлам Spanner решать вопросы согласованности изменяемых в ходе транзакции данных. Базовым в данном случае является так называемый протокол двухфазной фиксации транзакции (2-Phase Commit Protocol), отлично зарекомендовавший себя в распределённых реляционных СУБД. Он основан на очень простом принципе: если транзакция, выполняемая в одном узле, влияет на изменения в узлах, содержащих реплики данных этого узла, то она должна быть или зафиксирована (результат изменения сохранён на диске узла) на всех этих узлах, или же не выполнена (откат) ни на одном из них.

В основе концепции TrueTime лежит совмещение принципа нестрого определённого глобального времени и протокола двухфазной фиксации транзакций, обеспечивающего строгую непротиворечивость данных.

Для реализации протокола двухфазной фиксации в Spanner применяется проверенный в ходе эксплуатации Bigtable алгоритм разрешения коллизий Paxos.

Узел, инициирующий транзакцию (например, удаление пользователя из списка друзей), автоматически становится координатором этой транзакции. О транзакции он уведомляет все узлы-участники, содержащие реплику изменяемых данных. Каждый из узлов получает для формирования временной метки обновляемых данных интервал текущего глобального времени TT.now().

Естественно, что у географически распределённых узлов он будет разным. Все узлы-участники дают координатору обещание, что постараются выполнить фиксацию транзакции в отведенный TT.now() интервал. Получение такого фьючерс-обещания завершает фазу готовности.

Дальше каждый из узлов реализует транзакцию (запись изменений в журнал redolog и выполнение изменений данных в оперативной памяти) независимо от других участников, но зафиксировать её участники могут лишь по команде координатора. Задачей координатора при этом является не только передача такой команды, но и рассылка всем участникам общей временной метки измененных данных, единой для всех реплик. При этом координатор внимательно следит, чтобы значение этой временной метки не превысило границу интервала TT.now().earliest, то есть находилось в рамках общего глобального времени.

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

Как разблокировать Хонор 7с Гугл

Реализация процесса двухфазной фиксации транзакции на примере удаления пользователя социальной сети из списка друзей.

Очевидно, что реализация протокола двухфазной фиксации в высоконадежных серверах баз данных, на которых выполняются реляционные СУБД, сильно отличается от его реализации в заведомо ненадежных серверах кластеров Google. И именно поэтому уникальной является комбинация аппаратно реализованной в TMD-узлах технологии синхронизации глобального времени и функций библиотеки TrueTime, представляющей это время в виде интервала, в рамках которого узлы успевают «договориться» о согласованности данных.

Недаром Google назвала свое новое хранилище Spanner («гаечный ключ»). Концепции, заложенные в эту NewSQL-систему, накрепко скрутили между собой всё лучшее, что было достигнуто Bigtable в области беспрецедентной масштабируемости и отказоустойчивости, со строгой непротиворечивостью хранимых данных, характерной для распределённых реляционных СУБД. Пять лет усилий, затраченных инженерами Google на получение этого крепкого соединения технологий, не пропали зря.

Сейчас в среде Spanner, наряду со страницами пользователей Google+, хранятся критически важные для бизнеса Google данные её системы контекстной рекламы Google F1 и корреспонденция почтового сервиса Gmail. В будущем, вероятно, сфера его применения станет ещё шире.

Источник: www.computerra.ru

Spanner. NewSQL хранилище от Google

Spanner – географически распределенная высокомасштабируемая мультиверсионная база данных с поддержкой распределенных транзакций. Хранилище было разработана инженерами Google для внутренних сервисов корпорации. Research paper [8], описывающий базовые принципы и архитектуру Spanner, был представлен на научной конференции 10th USENIX Symposium on Operating Systems Design and Implementation в 2012 году.

Spanner является эволюционным развитием NoSQL-предшественника – Google Bigtable. Сам же c Spanner относят к семейству NewSQL-решений. В research paper [8] заявляется, что дизайн Spanner позволяет системе масштабироваться на миллионы вычислительных узлов через сотни дата-центров и работать с триллионами строк данных.

Spanner использует Colossus (GFS нового поколения) как слой хранения (storage) и алгоритм разрешения коллизий Paxos. В свою очередь на основе (on top) Spanner построена распределенная СУБД Google F1.

Spanner используется в социальной сети Google+, в почтовом сервисе GMail. Построенная на основе Spanner СУБД Google F1 использовалась на момент публикации [8] в сервисе Google Ad Service.

Базовые принципы

Данные в Spanner хранятся в полуреляционных таблицах, имеющих схему. Все данные имеют версию – временную метку (timestamp) подтверждения записи этих данных (commit). Spanner имеет SQL-подобный язык запросов, возможность конфигурировать количество реплик и политики Garbage Collector, ответственного за удаление записей со «старыми» временными метками.

  • поддержка распределенных транзакций;
  • глобальная согласованность операций чтения между географически распределенными ДЦ, т.о. данные, которые возвращают операции чтения из разных ДЦ, всегда согласованны и непротиворечивы.
  • неблокирующее чтение данных «из прошлого» (in past);
  • отсутствие блокировок для read-only транзакций;
  • атомарное изменение схемы таблиц данных;
  • синхронная репликация;
  • автоматическая обработка отказов как вычислительных узлов, так и ДЦ;
  • автоматическая миграция данных как между вычислительными узлами, так и между ДЦ.

Архитектура

Spanner Arhitecture

Каждый развернутый экземпляр (deployment) Spanner именуется Universe и содержит в себе:

  • Universe master – мастер-процесс, координирующий работу множества зон (в терминологии Spanner — Zone);
  • Множество Zone – географически распределенные (в общем случае) зоны Spanner. Zone – это единица как логической изоляции, так и физической.

Каждый из Zone, в свою очередь, содержит в себе:

  • ZoneMaster – мастер-процесс зоны (синглтон);
  • Множество — от сотни до нескольких тысяч — Spanservers;
  • Location proxy – раскрывают клиентам расположение Spanservers, ответственных за необходимые данные;
  • Placement driver – процесс (также, как и Zonemaster, синглтон), управляющий перемещением данных между различными Zone.

В research paper [8] подробно описаны функции и внутренне устройство только Spanserver.

Даты обновления алгоритмов Google

Каждый Spanserver содержит в себе от 100 до 1000 структур данных называемых tablet.

(key: string, timestamp: int64) -> string

В отличии от Bigtable, Spanner добавляет к структуре хранимых данных метку времени добавления этих данных, что является важным введением для реализации поддержки мульти-версионности данных.

Модель данных в Spanner – полуреляционные таблицы с поддержкой схем данных (schematized), SQL-подобного языка запросов и распределенных транзакций.

Реализация последних (транзакций) стала возможна благодаря одному из наиболее инновационных нововведений для такого рода программных систем – программного интерфейса TrueTime API.

TrueTime

Обычная задача для систем предоставления глобального времени (в частности атомных часов) – это предоставление максимально точного времени. TrueTime API же предоставляет клиентам глобальное время + некоторую неопределенность – TTinterval.

Это нужно потому, что для распределенных систем очень сложно гарантировать мгновенность отклика узлов, что важно для обеспечения согласованности данных в распределенном хранилище.

При подходе, когда вместо точного времени, возвращается некоторых временной интервал выполнение 2-ух конкурентных транзакций сводится (упрощенно) к сравнению TTinterval этих транзакций. Если TTinterval транзакций не пересекается, то можно однозначно узнать, какая из транзакций должна быть выполнена раньше. Если TTinterval – пересекается, то сказать можно только с определенной степенью вероятности. (Подробнее о аппаратной части сервиса TrueTime.)

В самом же Spanner согласованность данных при проведении транзакций обеспечивается протоколом двухфазной фиксации транзакции (2-Phase Commit Protocol), реализованным с помощью алгоритма Paxos.

Ограничения и CAP

На момент публикации research paper [8] Spanner не поддерживал вторичные индексы и автоматический resharding для целей балансировки нагрузки. Кроме того, авторы [8] отмечают, что Spanner не способен эффективно исполнять сложные SQL-запросы.

Spanner также не является «опровержением» CAP-теоремы. Spanner не является AP-системой, несмотря на свою NoSQL-природу; как и не является CA-системой, несмотря на поддержку стремление поддержки принципов ACID. Spanner «жертвует» доступностью (availability) для поддержания целостности данных (consistency) и поэтому является CP-системой.

Итоги

Spanner взял лучшие идеи двух миров — реляционных СУБД и NoSQL – и представляет из себя СУБД поколения NewSQL.

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

Список источников*

[8] 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.
* Полный список источников, используемый для подготовки цикла.

Дмитрий Петухов,
MCP, PhD Student, IT-зомби,
человек с кофеином вместо эритроцитов.

Источник: habr.com

Google Cloud Spanner — все, что вам нужно знать

Базы данных являются ключевым компонентом каждой программы, независимо от того, размещается ли она локально или в облаке.

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

Примером облачной базы данных является Google Cloud Spanner.

Давайте подробно рассмотрим Google Cloud Spanner в этой статье, включая все его возможности, варианты использования, цену и другие детали.

Что такое Google Cloud Spanner ?

Реляционная СУБД, использующая методологию NewSQL, называется Google Cloud Spanner. Он обеспечивает соответствие ACID (атомарность, согласованность, изоляция и надежность) и особенно подходит для OLTP (онлайн-обработка транзакций).

Он по-прежнему поддерживает масштабируемую архитектуру и очень масштабируем, как и системы NoSQL. Масштабируемая конструкция позволяет легко добавлять дополнительные узлы к существующему кластеру, чтобы распределить хранение данных и вычисления и добиться масштабируемости.

Преимущества NoSQL и NewSQL предоставляются Google Cloud Spanner.

Как в Гугл документах настроить поля страницы

TrueTime, глобально синхронизированные часы Google, является основой согласованности Google Spanner. Google создал TrueTime, широко распространенные и высокодоступные глобальные часы, которые доступны для всех облачных сервисов и серверов Google.

TrueTime гарантирует, что вновь созданная временная метка, скажем, T1, всегда будет выше, чем любая временная метка T2, если T2 была сгенерирована раньше, чем T1. В результате True-time может создавать временные метки, которые монотонно растут, а это означает, что они будут постоянно расти во всем своем домене.

Google Cloud Spanner

Затем приложения могут использовать это, чтобы присвоить каждой из своих транзакций отличительные возрастающие временные метки. Каждая часть данных, опубликованных в Google Cloud Spanner, получает метку времени с использованием TrueTime, и эта метка времени надежна во всем мире.

Это означает, что каждая транзакция, хранящаяся в Spanner, будет иметь специальную отметку времени, связанную с ней, которая фиксирует точный момент, когда Spanner обрабатывал транзакцию.

С помощью этих временных меток Google Cloud Spanner может обеспечить надежное чтение из любой точки мира, не препятствуя записи.

Кроме того, Google Cloud Spanner может обеспечить строгий контроль параллелизма для всех своих транзакций.

Хотя Google Cloud Spanner мог выполнять (и/или дублировать) все транзакции во многих местах, внешнему пользователю кажется, что все они произошли последовательно, одна за другой. Другими словами, Google Cloud Spanner функционирует как база данных на одном компьютере для внешних пользователей.

Google Cloud Spanner предоставляет глобальный порядок временных меток, который транзакции могут использовать для последующих операций и запросов. Пользователям приходилось выбирать между медленной производительностью + более надежными гарантиями ИЛИ высокой производительностью + более слабыми гарантиями в предыдущих системах баз данных.

Однако Google Cloud Spanner может предложить надежные гарантии, высокую целостность транзакций и более высокую производительность. Разработчики должны просто заботиться о том, чтобы убедиться, что каждая из их транзакций действительна и их логика приложения, а не беспокоиться о каких-либо конфликтах или гонках между их многочисленными транзакциями.

Особенности

  • Большинство приложений легко создавать, интегрировать и тестировать.
  • Ее можно охарактеризовать как базу данных NewSQL, поскольку она поддерживает как NoSQL, так и SQL, решая проблемы масштабируемости и производительности, характерные для обычных баз данных SQL.
  • Его точность довольно высока, поскольку он синхронизирует время с помощью атомных часов и технологий GPS.
  • Поддерживаются межтабличные транзакции.
  • Включает сложные функции управления и администрирования, в том числе резервное копирование, восстановление, возможность создания экземпляров SLA и многое другое.
  • Для локальных и мультирегиональных экземпляров обеспечивает доступность на уровне 99.999 %.
  • Горизонтально масштабируется плавно с небольшими помехами. Преимущество горизонтальной масштабируемости заключается в том, что при добавлении дополнительных серверов производительность системы значительно повышается.
  • Чтобы создать единый жизненный цикл данных, он предлагает запросы к большим данным в режиме реального времени.
  • В зависимости от объема запроса и размера данных он автоматически разбивает данные.
  • Он не выбирает автоматически вторичный индекс, несмотря на то, что он поддерживается.
  • Прозрачная репликация предлагается во многих конфигурациях и регионах.
  • предоставляет сложную аналитику и данные.
  • Данные из разных приложений и системы хранения синхронизированы.
  • Возможны физические зависимости между таблицами базы данных.
  • Для постоянного восстановления данных он предлагает восстановление на момент времени (PITR). Кроме того, вы можете получать данные с точностью до микросекунд.
  • Включены ключи шифрования, управляемые заказчиком (CMEK), интеграция IAM, шифрование на уровне данных и другие меры безопасности на уровне предприятия.

Use cases

1. Сайты электронной коммерции по всему миру

Заказ продуктов, сбор платежей и обновление запасов — все это функции транзакционной системы, определяющие электронную коммерцию. Крупные национальные или мировые следы можно увидеть на многих веб-сайтах электронной коммерции.

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

Как сравнить два списка в Гугл таблицах

2. Обработка аналитики в режиме реального времени

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

3. Аварийное восстановление (DR)

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

Для DR Spanner предлагает практический маршрут будущего. Репликация данных из базы данных Spanner в удаленное расположение позволит восстановить приложение без необходимости его перестроения с использованием данных с резервной ленты.

Создайте новые компьютерные ресурсы в другом месте и подключите их к системе резервной базы данных Spanner на случай, если основной сайт станет доступным. Благодаря своей простоте аварийное восстановление теперь доступно гораздо большему количеству ИТ-отделов.

4. Минимизация ручного вмешательства при увеличении времени отклика

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

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

5. Игровая база данных

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

Кроме того, поскольку базы данных NoSQL могут адаптироваться к изменениям базовой модели данных, они являются лучшим вариантом для игр. Избыточность также является важным компонентом игрового программного обеспечения.

Игровая база данных

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

6. финансовые услуги

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

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

Чтобы справиться с этим непрерывным потоком данных в прошлом, исторические базы данных должны были быть тщательно перестроены, и использовались нестабильные пользовательские решения. С штормом легко справляется Google Cloud Spanner.

Ограничение

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

Цены

Стоимость Spanner проста и предсказуема. Вам платят только за хранилище, которое используют таблицы и вторичные индексы вашей базы данных (не предварительно подготовленное), хранилище резервных копий, объем сетевого выхода и вычислительную мощность вашего экземпляра (измеряемую в количестве узлов или процессорных единиц).

Цены на гаечный ключ

Заключение

Поистине удивительный продукт, Google Spanner — превосходный пример огромного технологического мастерства Google.

Если Google продолжит выпускать такие новаторские продукты, вскоре он превзойдет других облачных провайдеров и займет позицию конкурента.

Источник: hashdork.com

Рейтинг
Загрузка ...