Google Cloud Spanner: огляд можливостей та перші враження від бази даних

Привіт! Мене звуть Роман Нога, я працюю Software Engineer у EPAM Ukraine (Львів). Вже не перший рік цікавлюся та слідкую за розробками інженерів Google. Хочу поділитися своїми дослідженнями можливостей Cloud Spanner. Хочу одразу зазначити, що наразі досвіду в продакшені з Cloud Spanner у мене немає. У статті поділюся враженнями від знайомства із сервісом і буду радий коментарям тих, хто має реальний досвід роботи зі Spanner.

Коротко про Google Cloud Spanner

У 2017 році Google анонсував Cloud Spanner як першу горизонтально масштабовану послідовну реляційну базу даних. Він був розроблений інженерами Google для внутрішніх сервісів корпорації і зараз використовується для Google+ і Gmail. Також заявлено, що Spanner дозволяє системі масштабуватись на мільйони обчислювальних вузлів через сотні дата-центрів і працювати з трильйонами рядків даних. Мене дуже зацікавили такі обіцянки, і я вирішив розібратись трошки глибше. Звісно, я не використовував таких великих обсягів даних, як згадано вище, але результати роботи Spanner мені дуже сподобались. До того ж, як і інші сервіси Google, Spanner має дуже зручну веб-консоль для створення таблиць, надає безліч репортів про використання бази та рекомендацію, коли потрібно маштабуватись. Отже, мені сподобалось експериментувати зі Spanner, тому вирішив написати про нього.

Проблеми скейлінгу

Зазвичай зі зростанням кількості користувачів з’являються проблеми з базою. Кількість запитів зростає, і настає момент, коли збільшується перформанс. Які шляхи вирішення цієї проблеми?

Можна використовувати існуючі технології кластеризації, такі як XtraDB або Vitess для MySQL і CitusDB для Postgres. Це може вирішити проблему, але також може частково не відповідати потребам проекту, принести додаткові складнощі та витрати на підтримку, або взагалі доведеться робити редизайн аплікації.

Також можна використати горизонтальне масштабування NoSQL. Для цього застосовуємо, наприклад, Cassandra, HBase, MongoDB, DynamoDB та BigTable. Тут слід пам’ятати, що ми позбуваємось деяких реляційних функцій, таких як JOIN, які приводять до того, що параметри запиту стають більш обмеженими. База даних, яка розміщена на хості, може бути виграшним рішенням в плані підтримки, однак перехід на NoSQL може бути неможливим через редизайн аплікації із сотнями таблиць і запитів.

Яке рішення пропонує Google

Spanner — горизонтально масштабована послідовна служба реляційних баз даних:

• Повністю керована DBaaS з горизонтальним масштабом та автоматизованим шарінгом даних.
• Традиційна модель реляційної семантики та послідовності: схеми, ACID транзакції, SQL.
• Автоматична синхронна реплікація в межах та між регіонами.
• Стандартний SQL.
• Моніторинг, логування, IAM.
• Клієнтські бібліотеки популярних мов (Java, Python, Go, C#, Node.js тощо).
• JDBC драйвер для підключення до популярних сторонніх інструментів.

Spanner використовує Colossus (GFS нового покоління) як шар зберігання (storage) і алгоритм вирішення колізій Paxos. Дані в Spanner зберігаються в таблицях, які мають схему. Всі дані мають часову мітку (timestamp), що важливо для реалізації підтримки мультиверсійності даних.

Початок роботи зі Spanner

Google надає 300 у. о. на рік під час реєстрації усім для використання всіх своїх сервісів. Цього насправді більш, ніж достатньо, щоб розібратись і спробувати попрацювати з Spanner-ом та іншими сервісами. Після реєстрації в консолі ми можемо створити наш інстанс, де ми вказуємо ім’я інстансу, ID, регіон та кількість нодів, які ми хочемо.
Після створення інстансу формуємо нашу базу даних. Для цього ми вказуємо ім’я нашої бази та починаємо створювати схему бази.

Перед початком роботи з базою нам необхідно все «засетапити». Google надає туторіал для різних популярних мов програмуванні. Після сетапу, у випадку .NET, нам необхідно заінсталювати Google.Cloud.Spanner.Data через NuGet.

Далі все просто: створюємо connection string ($"DataSource=projects/{projectId}/instances/{instanceId}"), формуємо SpannerConnection та робимо звернення до бази. Spanner підтримує всі необхідні запити, такі як: SELECT, JOIN, GROUP BY, HAVING.

Cloud Spanner підтримує прості типи даних, такі як INTEGER, а також більш складні типи — ARRAY та STRUCT. Максимальний розмір значення стовпця — 10 Мб.

Нововведеням в Spanner є interleaved table. Interleaved table використовується, коли необхідно мати доступ до рядків двох таблиць для заданого первинного ключа (кожен раз, коли ми отримуємо дані рядка одної таблиці, нам також потрібно отримати доступ до рядків другої таблиці), або іншими словами, це заміна звичайного foreign key. Буде корисним, наприклад, при CASCADE DELETE.

Для створення таких таблиць нам необхідно в таблиці, що наслідується від базової, вказати два PRIMARY KEY, нашої таблиці та батьківської.

CREATE TABLE Singers (
  SingerId   INT64 NOT NULL,
  FirstName  STRING(1024),
  LastName   STRING(1024),
  SingerInfo BYTES(MAX),
) PRIMARY KEY (SingerId);

CREATE TABLE Albums (
  SingerId     INT64 NOT NULL,
  AlbumId      INT64 NOT NULL,
  AlbumTitle   STRING(MAX),
) PRIMARY KEY (SingerId, AlbumId),
  INTERLEAVE IN PARENT Singers ON DELETE CASCADE;

Отримаємо такий вигляд:

Image source

Також Google гарантує, що всі зміни у схемі бази, наприклад, ALTER TABLE Singers ADD COLUMN Age INT64; будуть відбуватися на льоту (zero-downtime).

Такі заяви Google підтверджує тим, що Spanner тестувався більше 5 років на їхніх продуктах (GooglePlay, AdWords).

Як працює Google Spanner

На малюнку зображено інстанс з трьома нодами і трьома репліками в трьох зонах. У кожній зоні є повна копія даних. Кожна Cloud Spanner нода забезпечує 10 тисяч QPS запитів та 2 тисячі QPS записів і має ліміт в 2 TiB/ноду.

Є можливість моніторингу за допомогою Google Stackdriver. Ну і найцікавіше, для масштабування достатньо додати ноду. Як ми знаємо, якщо нода падає, вона піднімається автоматично за лічені секунди. Тому, якщо ми використовуємо більше ніж одну ноду для Spanner, наша база буде завжди онлайн.

Cloud Spanner використовує Data Splits:

Під час звернення до бази даних репліка запитує в лідера, чи має актуальні дані:

SELECT * FROM Table WHERE Name = ‘DOU’;

1. Запит.
2. Чи можна читати?
3. Так.
4. Відповідь.

На малюнку зображено, які кроки будуть відбуватись в типовій ситуації, коли ми щось читаємо, а потім пишемо щось на основі того, що вичитали.

1. Читання.
2. Лок.
3. Відповідь.
4. Запис.
5. Запис в репліки.
6. Підтвердження запису від реплік.
7. Зняття локу.
8. Відповідь.

TrueTime API

Реалізація транзакцій стала можлива завдяки програмному інтерфейсу TrueTime API. TrueTime API надає глобальний час та деяку невизначеність — TTinterval. Для розподілених систем дуже складно гарантувати миттєвість відгуку вузлів, що важливо для забезпечення узгодженості даних у розподіленому сховищі.

Коли замість точного часу повертається деяких часовий інтервал виконання двох конкурентних транзакцій, то порівнюються TTinterval цих транзакцій. Якщо TTinterval транзакцій не перетинаються, то ми можемо точно знати, яка з транзакцій повинна бути виконана перша. Якщо TTinterval перетинається, то визначити, яка транзакція має виконуватись перша, можна з певним ступенем ймовірності.

Рекомендація Google, коли використовувати Spanner

Звісно Google не рекомендує використовувати Spanner для всіх типів проектів. Найкраще використовувати його, якщо у нас є структуровані та реляційні дані та коли нам необхідне горизонтальне масштабування.

Недоліки та обмеження

Cloud Spanner не є дешевим. Очевидно, що через ціну він не підійде на будь-який проект.

Cloud Spanner рекомендує використовувати interleaved table для перформенсу та для каскадного оновлення та видалення. В іншому випадку каскадні операції не будуть виконуватись.

Ключі таблиці не можуть змінюватися. Ми не можемо додавати key column до існуючої таблиці або видалити з існуючої таблиці. Це означає, що якщо ми хочемо змінити PK таблиці, то нам доведеться дропнути та створити заново цю таблицю.

Перенесення ворклоаду, наприклад з MySQL, вимагає великих зусиль, як у дизайні, так і в імплементації, для забезпечення ефективної реалізації. Помилки в дизайні схеми можуть призвести до даунтаймів.

Підсумки

Google Spanner є новим типом БД (NewSQL), який об’єднує в собі два світи SQL та NoSQL. Він надає можливість для обробки величезної кількості транзакцій. При цьому гарантує цілісність даних з можливістю їх розподілення по всьому світі без обмежень розміром сховища, що вражає. Хоча наразі технологія має відносно невеликий список клієнтів та побудованих на її основі сервісів, але вона заслуговує на увагу широкого кола ІТ-спеціалістів.

Корисні посилання

Google Cloud Spanner
Spanner. NewSQL хранилище от Google
Google запустила бета-версию Cloud Spanner — СУБД поколения NewSQL
Работа с временем в Google
Introducing Cloud Spanner: a global database service for mission-critical applications

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU