Google Cloud Spanner

Материал из Национальной библиотеки им. Н. Э. Баумана
Последнее изменение этой страницы: 18:29, 26 февраля 2019.
Google Cloud Spanner
Google Cloud Spanner logo.png
Разработчики: Google
Выпущена: 2017; 4 years ago (2017)
Постоянный выпуск: 2.1.0 / February 1, 2019 (2019-02-01)
Локализация: English
Лицензия: Google License
Веб-сайт cloud.google.com/spanner/

Cloud Spanner - первая в мире полностью управляемая служба реляционных баз данных, обеспечивающая как сильную согласованность, так и горизонтальную масштабируемость для критически важных приложений обработки транзакций (OLTP).Cloud Spanner использует все традиционные преимущества реляционных баз данных, но в отличие от любой другой службы, Cloud Spanner масштабируется горизонтально до сотен или тысяч серверов для обработки самых больших транзакционных рабочих нагрузок. [Источник 1]

История

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

Google Cloud Spanner впервые появился как хранилище NoSQL но со временем он стал включать в себя строго типизированную схему и систему SQL-запросов. Работа над его ядром NoSQL и интерфейсом SQL была частично основана на усилиях, предпринятых инженерами Google в рамках собственной системы F1 компании по управлению данными Google AdWords. Google Cloud Spanner стал общедоступным для клиентов в мае 2017 года. [Источник 2]

Возможности Cloud Spanner

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

  • Глобальная масштабируемость - по регионам и центрам обработки данных - от одного до сотен или тысяч узлов.
  • Полная управляемость - репликация и обслуживание автоматические.
  • Реляционная семантика - схемы, транзакции ACID и SQL-запросы.
  • Поддержка нескольких языков - клиентские библиотеки на C#, Go, Java, Node.js, PHP, Python и Ruby.
  • Драйвер JDBC - для подключения к популярным сторонним инструментам.
  • Согласованность транзакций
  • Безопасность промышленного уровня - шифрование на уровне данных, интеграция IAM для доступа и контроля и ведение журнала аудита.
  • Высокая доступность.

Инстансы

Когда впервые запускается Cloud Spanner (далее CS), необходимо создать экземпляр CS в своем проекте Google Cloud Platform. Экземпляр - это выделенные ресурсы, которые используются базами данных Cloud Spanner, созданными в этом экземпляре. Когда экземпляр создан, необходимо выбрать, где хранятся данные, и сколько узлов будет использоваться. [Источник 4]


Конфигурации

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

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

Количество нод

Количество нод определяет количество узлов в экземпляре. Выбор определяется объемом обслуживаемых ресурсов (и их хранилищ), доступных для баз данных в этом экземпляре. Для производственных сред рекомендуется минимум 3 узла.

Каждый узел Cloud Spanner может предоставлять до 10 000 запросов в секунду (QPS) чтения или 2000 QPS записи (записывая отдельные строки по 1 КБ данных в строку), а также до 2 ТБ хранилища. Для обеспечения оптимальной производительности лучше всего будет обеспечить достаточное количество узлов, чтобы поддерживать общую загрузку процессоров до 75%.

Cloud Spanner не имеет режима ожидания. Узлы являются выделенными ресурсами, и даже если они не нагружены на 100%, узлы Cloud Spanner часто выполняют фоновые работы для оптимизации и защиты данных.

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

Модель данных

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

Табличные связи "parent-child"

Cloud Spanner позволяет дополнительно определить отношения между родителями и дочерними элементами между таблицами, если это необходимо, чтобы Cloud Spanner физически совмещал их строки для эффективного извлечения. Например, если у вас есть таблицы КЛИЕНТЫ и ИНВОЙСЫ, и приложение часто извлекает все инвойсы для какого-то клиента, можно определить ИНВОЙСЫ как дочернюю для таблицы КЛИЕНТЫ. При этом объявляеся связь данных между двумя логически независимыми таблицами: позволяете Cloud Spanner физически хранить одну или несколько строк ИНВОЙСЫ с одной строкой КЛИЕНТЫ.

Первичные ключи

Как определить для Cloud Spanner, какие строки таблицы ИНВОЙСЫ c какими строками КЛИЕНТЫ хранить? Это можно сделать с помощью первичного ключа этих таблиц. Каждая таблица должна иметь первичный ключ, который может состоять из нуля или более столбцов этой таблицы. Если объявить таблицу дочерним элементом другой таблицы, столбец первичных ключей родительской таблицы должен быть префиксом первичного ключа дочерней таблицы. Это означает, что если первичный ключ родительской таблицы состоит из N столбцов, первичный ключ каждой из его дочерних таблиц должен также состоять из тех же N столбцов в том же порядке и начинаться с того же столбца.

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

Выбор первичного ключа

Если первичный ключ состоит из одного или нескольких столбцов, для каждой строки понадобится уникальный первичный ключ. Часто приложение уже имеет поле, которое естественным образом подходит для использования в качестве первичного ключа. Например, в приведенном выше примере таблицы КЛИЕНТЫ может быть предоставленный приложением Номер_Клиента, который служит в качестве первичного ключа. В других случаях может понадобиться сгенерировать первичный ключ при вставке строки, как уникальное значение INT64, которое создаются с использованием библиотеки UUID.

Разбиение базы данных

Сущесвтует возможность определить иерархии отношений между родительскими и дочерними элементами между таблицами до семи слоев, что означает, что можно сопоставлять строки из семи логически независимых таблиц. Если размер данных в таблицах невелик, база данных, вероятно, может обрабатываться одним сервером Cloud Spanner. Но что происходит, когда связанные таблицы растут и начинают достигать пределов ресурсов отдельного сервера? Cloud Spanner - это распределенная база данных, что означает, что по мере роста базы данных Cloud Spanner делит данные на части, называемые «split»-ы, где отдельные расщепления могут перемещаться независимо друг от друга и переназначаться на разные серверы, которые могут находиться в разных физических местоположениях.

Разделение определяется как диапазон строк в таблице верхнего уровня, где строки упорядочены по первичному ключу. Начальные и конечные ключи этого диапазона называются «split boundaries». Cloud Spanner автоматически добавляет и удаляет границы разделения, что изменяет количество разделов в базе данных.

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

Разделение на основе нагрузки

В качестве примера того, как Cloud Spanner выполняет разбиение по нагрузке для уменьшения числа высоконагруженных точек, предположим, что база данных содержит таблицу с 10 строками, которые читаются чаще, чем все остальные строки в таблице. Пока эта таблица находится в корне иерархии базы данных, Cloud Spanner может добавлять «split boundaries» между каждой из этих 10 строк так, чтобы каждая из них обрабатывалась разными серверами, вместо того, чтобы позволить всем "read"-ам этих строк потреблять ресурсы одного.

Пределы размеров "split"-а.

Как правило, размер каждого набора связанных строк в иерархии таблиц "parent-child" должен быть меньше нескольких GiB. Набор связанных строк в иерархии родительско-дочерних таблиц определяется как: (одна строка таблицы в корне иерархии базы данных) + (все строки дочерних таблиц этой таблицы с тем же первичным ключом) + (все строки чередующихся индексов с тем же первичным ключом).

Сравнение с реляционными и нереляционными БД

В качестве управляемой реляционной облачной базы данных Google Cloud Spanner является альтернативой облачным реляционным базам данных, включая Azure SQL, Amazon Aurora , IBM DB2 и Oracle Database Cloud Service, а также широко используемые базы данных веб-приложений и облачных приложений с открытым исходным кодом, такие как MySQL и PostgreSQL. , Поскольку Google Cloud Spanner сочетает в себе черты NoSQL и SQL, его также можно классифицировать как базу данных NewSQL . Он конкурирует с CrateDB, NuoDB , системой управления базами данных в памяти MemSQL, CockroachDB и другими.[Источник 5]

Google Cloud Spanner Реляционные БД Нереляционными БД
Схема + + -
SQL + + -
Согласованность сильная сильная конечная
Доступность Высокая отказоустойчивость Высокая
Масштабируемость горизонтальная вертикальная горизонтальная
Репликация Автоматическая Настраиваемая Настраиваемая

Система аудита

Службы Google Cloud Platform записывают журналы аудита, чтобы помочь ответить на вопросы: «Кто, когда, где и что сделал?». Каждый проект содержит только журналы аудита для ресурсов, которые находятся непосредственно внутри проекта. Другие объекты, включая папки, организации и платежные учетные записи, содержат журналы аудита для самих себя.

Информация, полученная в процессе аудита делится на разные категории:

  • Активность администратора: операции, которые изменяют конфигурацию и метаданные ресурса. Cloud Spanner предоставляет информацию о,активности администратора по умолчанию.
  • Доступ к данным (ADMIN_READ): операции, которые считывают конфигурацию или метаданные ресурса. Cloud Spanner не предоставляет информацию ADMIN_READ по умолчанию.
  • Доступ к данным (DATA_READ): операции, которые считывают предоставленные пользователем данные из ресурса. Cloud Spanner не предоставляет данные DATA_READ по умолчанию.
  • Доступ к данным (DATA_WRITE): операции, которые записывают предоставленные пользователем данные в ресурс. Cloud Spanner не предоставляет данные DATA_WRITE по умолчанию.

Операции, подверженные аудиту

  • Активность администратора:
    • Операции с инстансами: CreateInstance, DeleteInstance, UpdateInstance;
    • Операции с БД: CreateDatabase, DropDatabase, GetDatabase, UpdateDatabaseDdl;
  • ADMIN_READ:
    • Операции с инстансами: GetInstance, GetInstanceConfig, ListInstanceConfigs, ListInstances;
    • Операции с БД: GetDatabase, GetDatabaseDdl, ListDatabases;
  • DATA_READ: BeginTransaction, ExecuteSql, ExecuteStreamingSql, GetSession, ListSessions, Read, StreamingRead;
  • DATA_WRITE: BeginTransaction, Commit, CreateSession, DeleteSession, Rollback;

Приступая к работе

Регистрация в системе и знакомство с интерфейсом

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

Процесс создания экземпляра БД и его удаление

Источники

  1. Cloud Spanner Documentation Product Overview // Google Documents [2017 - 2019]. Дата обновления: 29.12.2018. URL:https://cloud.google.com/spanner (дата обращения: 28.01.2019)
  2. Spanner (database) // TechCrunch. [2016–2019]. Дата обновления: 08.01.2019. URL: https://techcrunch.com/2018/12/19/googles-cloud-spanner-database-adds-new-features-and-regions/ (дата обращения: 20.01.2019)
  3. Spanner: Spanner: Google’s Globally-Distributed Database // Google Documents [2012 - 2019]. Дата обновления: 13.10.2012. URL:http://static.googleusercontent.com/media/research.google.com/en/us/archive/spanner-osdi2012.pdf (дата обращения: 18.02.2019)
  4. Spanner: Google’s Globally-Distributed Database // Google Documents [2012 - 2019]. Дата обновления: 13.10.2012. URL:http://static.googleusercontent.com/media/research.google.com/en//archive/spanner-osdi2012.pdf (дата обращения: 18.02.2019)
  5. Google Cloud Spanner // Techtarget News [2017 - 2019]. Дата обновления: 13.10.2019. URL:https://searchdatamanagement.techtarget.com/definition/Google-Cloud-Spanner (дата обращения: 18.02.2019)