Привіт, хабрівчани. Традиційно продовжуємо ділитися цікавим матеріалом напередодні старту нових курсів. Сьогодні спеціально для вас ми переклали статтю про Google Cloud Spanner, приурочивши її до запуску курсу .
Спочатку опубліковано в .
Як компанія, яка пропонує безліч хмарних POS-рішень для роздрібних торговців, рестораторів та онлайн-продавців по всьому світу, Lightspeed використовує кілька різних типів платформ баз даних для безлічі трансакційних, аналітичних та пошукових кейсів. Кожна з цих платформ баз даних має свої сильні та слабкі сторони. Отже, коли Google представив на ринку Cloud Spanner — багатообіцяючі функції, небачені у світі реляційних баз даних, такі як практично необмежена горизонтальна масштабованість та 99,999% угода про рівень сервісу (SLA), — ми не могли прогаяти можливості отримати її в наші руки!
Щоб дати вичерпний огляд нашого досвіду з Cloud Spanner, а також критерії оцінки, які ми використовували, ми розглянемо наступні теми:
- Наші критерії оцінки
- Cloud Spanner двома словами
- Наша оцінка
- Наші висновки
1. Наші критерії оцінки
Перш ніж поглиблюватись особливо Cloud Spanner, її подібності та відмінності з іншими рішеннями на ринку, давайте спочатку поговоримо про основні юзкейси, які ми мали на увазі при розгляді питання про те, де розгорнути Cloud Spanner в нашій інфраструктурі:
- Як заміна (переважного) традиційного рішення для бази даних SQL
- Як OLTP рішення з підтримкою OLAP
Примітка: Для простоти та зручності порівняння ця стаття порівнює Cloud Spanner із MySQL варіантами сімейств рішень GCP Cloud SQL та Amazon AWS RDS.
Використання Cloud Spanner як заміна традиційного рішення для бази даних SQL
У середовищі традиційних баз даних, коли час відгуку на запит до бази даних наближається або навіть перевищує попередньо визначені граничні значення програми (в основному через збільшення кількості користувачів та/або запитів), існує кілька способів знизити час відгуку до прийнятних рівнів. Однак більшість цих рішень включають ручне втручання.
Наприклад, перший крок, який потрібно зробити, - це подивитися на різні параметри бази даних, пов'язані з продуктивністю, і налаштувати їх так, щоб вони найкраще відповідали шаблонам сценаріїв використання програм. Якщо цього недостатньо, можна вибрати масштабування бази даних по вертикалі або по горизонталі.
Вертикальне масштабування програми тягне за собою оновлення інстансу сервера, зазвичай шляхом додавання більшої кількості процесорів/ядер, більшого обсягу оперативної пам'яті, швидшого сховища і т. д. Додавання більшої кількості апаратних ресурсів призводить до збільшення продуктивності бази даних, що вимірюється в основному в транзакціях секунду, та затримці транзакцій для систем OLTP. Системи реляційних баз даних (які використовують багатопотоковий підхід), такі як MySQL, добре масштабуються по вертикалі.
Цей підхід має кілька недоліків, але найбільш очевидним є максимальний розмір сервера на ринку. Як тільки досягається межа найбільшого інстансу сервера, залишається лише один шлях: горизонтальне масштабування.
Горизонтальне масштабування — це підхід, коли кластер додає більше серверів, щоб в ідеалі лінійно збільшувати продуктивність з додаванням кількості серверів. Більшість традиційних систем баз даних погано масштабуються по горизонталі чи взагалі масштабуються. Наприклад, MySQL може горизонтально масштабуватись для операцій читання, додаючи slave-читачів, але не може горизонтально масштабуватись для операцій запису.
З іншого боку, завдяки своїй природі Cloud Spanner може легко масштабуватись горизонтально з мінімальним втручанням.
Повнофункціональна СУБД як сервіс має оцінюватися з різних сторін. Як основу ми взяли найпопулярнішу СУБД у хмарі – для Google, GCP Cloud SQL та для Amazon, AWS RDS. У нашій оцінці ми зосередилися на наступних категоріях:
- Порівняння фіч: екстент SQL, DDL, DML; бібліотеки підключень/конектори, підтримка транзакцій тощо.
- Підтримка розробки: простота розробки та тестування.
- Підтримка адміністрування: управління інстансами - наприклад, масштабування вгору/вниз та апгрейд інстансів; SLA, резервне копіювання та відновлення; безпека/контроль доступу.
Використання Cloud Spanner як рішення OLTP за допомогою OLAP
Хоча Google не стверджує, що Cloud Spanner призначений для аналітичної обробки, він розділяє деякі атрибути з іншими механізмами, такими як Apache Impala & Kudu та YugaByte, які призначені для робочих навантажень OLAP.
Навіть якщо б існувала лише невелика ймовірність того, що Cloud Spanner включив у себе узгоджений горизонтально масштабований двигун HTAP (гібридної транзакційної/аналітичної обробки) з (менш-менш) придатним для використання набором функцій OLAP, ми думаємо, що це заслуговувало б нашої уваги.
Маючи це на увазі, ми розглянули такі категорії:
- Завантаження даних, індекси та підтримка партиціонування
- Продуктивність запитів та DML
2. Cloud Spanner двома словами
Google Spanner — кластерна система управління реляційними базами даних (РСУБД), яку Google використовує для кількох власних сервісів. Google зробив її загальнодоступною для користувачів Google Cloud Platform на початку 2017 року.
Ось деякі з атрибутів Cloud Spanner:
- Сильно узгоджений кластер РСУБД, що масштабується: використовує апаратну синхронізацію часу для забезпечення узгодженості даних.
- Підтримка кростаблічних транзакцій: транзакції можуть охоплювати кілька таблиць — необов'язково обмежуватися однією таблицею (на відміну Apache HBase чи Apache Kudu).
- Таблиці на основі первинного ключа: усі таблиці повинні мати оголошений первинний ключ (ПК), який може складатися з кількох стовпців таблиці. Табличні дані зберігаються в порядку ПК, що робить їх дуже ефективними та швидкими для пошуку по ПК. Як і інші системи на основі ПК, реалізація має бути змодельована з огляду на попередньо продумані юзкейси для досягнення .
- таблиці, Що Чергуються: таблиці можуть мати фізичні залежності один від одного. Рядки дочірньої таблиці можна порівняти з рядками батьківської таблиці. Такий підхід прискорює пошук відносин, які можна визначити на етапі моделювання даних, наприклад, при спільному розміщенні клієнтів та їх рахунків-фактур.
- Індекси: Cloud Spanner підтримує вторинні індекси. Індекс складається з проіндексованих стовпців та всіх стовпців ПК. За бажання індекс також може містити інші неіндексовані стовпці. Індекс може чергуватись з батьківською таблицею для прискорення запитів. До індексів застосовуються кілька обмежень, наприклад, максимальна кількість додаткових стовпців, що зберігаються в індексі. Також запити через індекси можуть бути не такими прямолінійними, як інші РСУБД.
«Cloud Spanner вибирає індекс автоматично лише в окремих випадках. Зокрема, Cloud Spanner не вибирає вторинний індекс автоматично, якщо запит запитує будь-які стовпці, які не збережені в ».
- Угода про рівень обслуговування (SLA): розгортання в одному регіоні зі SLA з 99,99%; мультирегіональні розгортання із 99,999% SLA. Хоча сама угода про рівень обслуговування є лише угодою, а не будь-якою гарантією, я вважаю, що у співробітників Google дійсно є деякі точні дані, щоб зробити таке серйозне твердження. (Для довідки, 99,999% означає 26,3 секунд недоступності послуги на місяць.)
- більше:
Примітка: Проект Apache Tephra додає розширену підтримку транзакцій в Apache HBase (також тепер реалізований в Apache Phoenix як бета-версія).
3. Наша оцінка
Отже, ми всі читали заяви Google про переваги Cloud Spanner - практично необмежену горизонтальне масштабування при збереженні високої узгодженості та дуже високого SLA. Хоча ці вимоги, принаймні надзвичайно важко досягти, нашою метою було не спростовувати їх. Натомість давайте зосередимося на інших речах, які хвилюють більшість користувачів баз даних: парність та зручність використання.
Ми оцінили Cloud Spanner як заміну Sharded MySQL
Google Cloud SQL та Amazon AWS RDS, дві найбільш популярні OLTP СУБД на хмарному ринку, мають дуже великий набір функцій. Однак, щоб масштабувати ці бази даних за межі розміру одного вузла, вам необхідно розбивати програми. Такий підхід створює додаткову складність як додатків, так адміністрування. Ми розглянули, як Spanner вписується в сценарій об'єднання кількох сегментів в один інстанс і якими функціями (якщо є), можливо, доведеться пожертвувати.
Підтримка SQL, DML та DDL, а також конектор та бібліотеки?
По-перше, під час запуску з будь-якою базою даних необхідно створювати модель даних. Якщо ви думаєте, що ви можете підключити JDBC Spanner до вашого улюбленого інструменту SQL, ви виявите, що можете запитувати ваші дані за його допомогою, але не можете використовувати його для створення таблиці або зміни (DDL) або будь-яких операцій вставки/оновлення/видалення ( DML). Офіційний JDBC від Google не підтримує ні того, ні іншого.
"В даний час драйвери не підтримують оператори DML або DDL".
Документація Spanner
З консоллю GCP ситуація не краща — ви можете надсилати лише SELECT-запити. На щастя, існує драйвер JDBC із підтримкою DML та DDL від спільноти, включаючи транзакції . Хоча цей драйвер дуже корисний, відсутність власного драйвера JDBC від Google викликає подив. На щастя, Google пропонує досить широку підтримку клієнтських бібліотек (на основі gRPC): C#, Go, Java, node.js, PHP, Python та Ruby.
Практично обов'язкове використання користувацьких API-інтерфейсів Cloud Spanner (через відсутність DDL і DML у JDBC) призводить до деяких обмежень для пов'язаних областей коду, таких як пули з'єднань або фреймворки зв'язування бази даних (наприклад, Spring MVC). Як правило, під час використання JDBC можна вільно вибирати улюблений пул з'єднань (наприклад, HikariCP, DBCP, C3PO тощо), який протестований і добре працює. У разі користувацьких API Spanner ми повинні покладатися на фреймворки/пули зв'язування/сесії, які ми створили самі.
Конструкція, яка орієнтована на первинний ключ (ПК), дозволяє Cloud Spanner бути дуже швидкою при доступі до даних через ПК, але також призводить до деяких проблем із запитами.
- Ви не можете оновити значення первинного ключа; Ви повинні спочатку видалити запис з оригінального ПК і знову вставити його з новим значенням. (Це схоже на інші ПК орієнтовані бази даних/механізми зберігання.)
- Будь-які оператори UPDATE і DELETE повинні вказувати ПК у WHERE, отже, не може бути порожніх операторів DELETE all — завжди має бути підзапит, наприклад: UPDATE xxx
- Відсутність опції автоінкремента або чогось подібного, що задає послідовність поля ПК. Щоб це працювало, відповідне значення має бути створене на стороні програми.
Вторинні індекси?
Google Cloud Spanner має вбудовану підтримку вторинних індексів. Це дуже приємна особливість, яка не завжди є в інших технологіях. Apache Kudu зараз взагалі не підтримує вторинні індекси, а Apache HBase не підтримує індекси безпосередньо, але може додавати їх через Apache Phoenix.
Індекси в Kudu та HBase можна моделювати як окрему таблицю з різним складом первинних ключів, але атомарність операцій, що виконуються з батьківською таблицею та зв'язаними індексними таблицями, повинна виконуватися на рівні програми і не є тривіальною у правильній реалізації.
Як згадувалося в огляді Cloud Spanner, його індекси можуть відрізнятись від індексів MySQL. Таким чином, слід виявляти особливу обережність при побудові запитів та профілюванні, щоб забезпечити використання належного індексу там, де він необхідний.
Уявлення?
Дуже популярний і корисний об'єкт у базі даних – уявлення. Вони можуть бути корисні для великої кількості юзкейсів; два моїх фаворити - це рівень логічної абстракції та рівень безпеки. На жаль, Cloud Spanner не підтримує уявлення. Однак це лише частково обмежує нас, оскільки для дозволів доступу немає деталізації на рівні стовпців, де подання можуть бути прийнятним рішенням.
У документації Cloud Spanner у розділі, в якому детально описуються квоти та обмеження (), є, зокрема, одна, яка може бути проблематичною для деяких додатків: Cloud Spanner з коробки має обмеження максимум 100 бази даних на інстанс. Очевидно, що це може стати серйозною перешкодою для бази даних, яка призначена для масштабування більш ніж на 100 баз даних. На щастя, після розмови з нашим технічним представником Google ми з'ясували, що цей ліміт може бути збільшений до будь-якого значення через службу підтримки Google.
Підтримка розробки?
Cloud Spanner пропонує досить пристойну підтримку мов програмування для роботи з API. Офіційно підтримувані бібліотеки знаходяться в C#, Go, Java, node.js, PHP, Python і Ruby. Документація досить деталізована, але, як і у випадку з іншими передовими технологіями, спільнота досить невелика порівняно з найпопулярнішими технологіями баз даних, що може призвести до збільшення часу, що витрачається на вирішення менш поширених випадків використання чи проблем.
Отже, як щодо підтримки локальної розробки?
Ми не знайшли спосіб створити інстанс Cloud Spanner у локальному середовищі. Найближче, що ми отримали - Docker-образ , що у принципі схоже, але практично сильно відрізняється. Наприклад, CockroachDB може використовувати PostgreSQL JDBC. Оскільки середовище розробки має бути максимально наближеним до робочого середовища, Cloud Spanner не ідеальний, оскільки потрібно покладатися на повний інстанс Spanner. Для економії витрат ви можете вибрати інстанс для одного регіону.
Підтримка адміністрування?
Створити інстанс Cloud Spanner дуже просто. Потрібно просто вибрати між створенням мультирегіонального або інстансу для одного регіону, вказати регіон(и) та кількість вузлів. Менш ніж за хвилину інстанс буде запущений і готовий до роботи.
Декілька елементарних метрик безпосередньо доступні на сторінці Spanner в консолі Google. Докладніші уявлення доступні через Stackdriver, де ви також можете встановити порогові значення метрик та політики оповіщень.
Доступ до ресурсів?
MySQL пропонує великі та дуже детальні налаштування дозволів/ролей користувачів. Можна легко налаштувати доступ до певної таблиці або навіть до підмножини її стовпців. Cloud Spanner використовує інструмент Google Identity & Access Management (IAM), який дозволяє встановлювати політики та дозволи лише на дуже високому рівні. Найбільш деталізований варіант - це дозвіл на рівні бази даних, який не вписується у більшу частину виробничих випадків. Це обмеження змушує вас додавати додаткові заходи безпеки у ваш код, інфраструктуру або те й інше для запобігання несанкціонованому використанню ресурсів Spanner.
Резервні копії?
Говорячи просто, резервних копій в Cloud Spanner не існує. Хоча високі вимоги Google SLA можуть гарантувати, що ви не втратите будь-які дані через збоїв обладнання або бази даних, від людських помилок, дефектів додатків тощо. Ми всі знаємо правило: висока доступність не замінює розумну стратегію резервного копіювання. На даний момент єдиним способом резервного копіювання даних є програмна передача їх з бази даних в окреме середовище зберігання.
Продуктивність запитів?
Для завантаження даних та тестування запитів ми використовували Yahoo! Cloud Serving Benchmark. У таблиці нижче представлено робоче навантаження B YCSB із співвідношенням читання 95% та запису 5%.
* Навантажувальний тест виконувався на обчислювальному движку (CE) n1-standard-32 (32 vCPU, 120 ГБ пам'яті), і тестовий інстанс ніколи не був вузьким місцем у тестах.
** Максимальна кількість потоків в одному екземплярі YCSB становить 400. Усього потрібно було запустити шість паралельних екземплярів YCSB тестів, щоб отримати загалом 2400 потоків.
Дивлячись на результати тестів, зокрема поєднання навантаження на процесор і TPS, ми бачимо, що Cloud Spanner досить добре масштабується. Велике навантаження, яке створюється великою кількістю потоків, компенсується великою кількістю вузлів у кластері Cloud Spanner. Хоча затримка виглядає досить високою, особливо при роботі з 2400 потоками, для отримання точніших чисел може знадобитися повторне тестування з 6 меншими екземплярами обчислювального двигуна. Кожен екземпляр запускатиме один тест YCSB замість одного великого інстансу CE з 6 паралельними тестами. Таким чином, буде легше розрізнити затримки запитів Cloud Spanner та затримки, додані мережевим з'єднанням між Cloud Spanner та інстансом CE, на якому виконується тест.
Як Cloud Spanner справляється як OLAP?
Партіціонування?
Поділ даних на фізично та/або логічно незалежні сегменти, які називаються партіціями, є дуже популярною концепцією, властивою більшості механізмів OLAP. Партиції можуть значно покращити продуктивність запитів та підтримуваність бази даних. Подальше поглиблення у партиції випливло б в окрему статтю (статті), тому давайте просто згадаємо про важливість наявності схеми партиціонування та subпартіціонування. Можливість розбивати дані на партиції та навіть далі на підпартиції є ключем до продуктивності аналітичних запитів.
Cloud Spanner не підтримує партиції як такі. Він поділяє дані всередині так звані розкол-и з урахуванням діапазонів первинного ключа. Розділення виконується автоматично для балансування навантаження у кластері Cloud Spanner. Дуже зручна функція Cloud Spanner – це розбиття базового навантаження батьківської таблиці (таблиці, яка не чергується з іншою). Spanner автоматично визначає, чи містить розкол дані, які зчитуються частіше, ніж дані в інших розкол-ах, і може ухвалити рішення про подальший поділ. Таким чином, у запиті може бути задіяно більше вузлів, що також ефективно збільшує пропускну здатність.
Завантаження даних?
Спосіб Cloud Spanner для об'ємних даних такий самий, як і при звичайному завантаженні. Для досягнення максимальної продуктивності вам необхідно дотримуватися деяких рекомендацій, у тому числі:
- Сортуйте ваші дані за первинним ключем.
- Розділіть їх на 10*кількість вузлів окремих секцій.
- Створіть набір робочих завдань, які завантажують дані паралельно.
При завантаженні даних використовуються всі вузли Cloud Spanner.
Ми використовували робоче навантаження A YCSB для створення набору даних з 10M рядків.
* Навантажувальний тест виконувався на обчислювальному двигуні n1-standard-32 (32 vCPU, 120 ГБ пам'яті), і тестовий інстанс ніколи не був вузьким місцем у тестах.
** Налаштування з одного вузла не рекомендується для будь-якого виробничого навантаження.
Як згадувалося вище, Cloud Spanner автоматично обробляє split-и залежно від їхнього навантаження, тому результати покращуються після кількох послідовних повторів тесту. Результати, представлені тут, є найкращими результатами, які ми отримали. Дивлячись на цифри вище, ми можемо бачити, як Cloud Spanner (добре) масштабується зі збільшенням числа вузлів у кластері. Цифри, що виділяються, є надзвичайно низькими середніми затримками, які контрастують з результатами змішаних робочих навантажень (95% для читання та 5% для запису), як описано в розділі вище.
Масштабування?
Збільшення та зменшення кількості вузлів Cloud Spanner – це завдання, яке виконується одним кліком. Якщо ви хочете швидко завантажити дані, ви можете розглянути можливість бустингу інстансу до максимуму (у нашому випадку це було 25 вузлів у регіоні US-EAST), а потім зменшити кількість вузлів, що підходять для вашого звичайного завантаження, після того, як усі дані в базі даних , маючи на увазі обмеження 2 ТБ/вузол.
Нам нагадали про цю межу навіть із значно меншою базою даних. Після кількох прогонів тестів навантаження наша база даних мала розмір близько 155 ГБ, а при зменшенні до інстансу з 1 вузла ми отримали наступну помилку:
Нам вдалося зменшити масштаб із 25 до 2 інстансів, але ми застрягли на двох вузлах.
Збільшення та зменшення кількості вузлів у кластері Cloud Spanner можна автоматизувати за допомогою REST API. Це може бути особливо корисним для зменшення підвищеного навантаження на систему в години напруженої роботи.
Продуктивність OLAP запитів?
Спочатку ми планували приділити значний час нашої оцінки Spanner цієї частини. Після кількох SELECT COUNT ми відразу зрозуміли, що тестування буде коротким і що Spanner не буде відповідним для OLAP двигуном. Незалежно від кількості вузлів у кластері, простий вибір кількості рядків у таблиці з 10M рядків зайняв від 55 до 60 секунд. Крім того, будь-який запит, який вимагав більшого обсягу пам'яті для зберігання проміжних результатів, завершився помилкою OOM.
SELECT COUNT(DISTINCT(field0)) FROM usertable; — (10M distinct values)-> SpoolingHashAggregateIterator ran out of memory during new row.
Деякі цифри для TPC-H запитів можна знайти у статті Тодда Ліпкона , слайди 42 та 43. Ці цифри узгоджуються з нашими власними результатами (на жаль).
4. Наші висновки
Враховуючи поточний стан фіч Cloud Spanner, важко уявити його простою заміною існуючого рішення OLTP, особливо коли ваші потреби переростуть його. Потрібно було б витратити значну кількість часу на те, щоб збудувати рішення з урахуванням недоліків Cloud Spanner.
Коли ми почали оцінку Cloud Spanner, ми очікували, що його функції керування будуть на рівні або принаймні не так далеко від інших рішень Google SQL. Але ми були здивовані повною відсутністю резервних копій та дуже обмеженим контролем доступу до ресурсів. Не кажучи вже про відсутність уявлень, відсутність локального середовища розробки, послідовностей, що не підтримуються, JDBC без підтримки DML і DDL і так далі.
Отже, куди подітися тому, кому потрібно масштабувати транзакційну базу даних? Схоже, на ринку поки що немає єдиного рішення, яке б підходило для всіх варіантів використання. Існує безліч рішень із закритим та відкритим вихідним кодом (деякі з яких згадуються в цій статті), кожне з яких має свої сильні та слабкі сторони, але жодне з них не пропонує SaaS із SLA 99,999% та високим ступенем узгодженості. Якщо високий рівень SLA є вашою основною метою, і ви не схильні створювати власне рішення для кількох хмарних середовищ, Cloud Spanner може бути тим рішенням, яке ви шукаєте. Але ви повинні знати про всі його обмеження.
Заради справедливості слід зазначити, що Cloud Spanner була випущена для загального доступу лише навесні 2017 року, тому розумно очікувати, що деякі з його поточних недоліків можуть зникнути (сподіваюся), і коли це станеться, це може змінити гру. Зрештою, Cloud Spanner – це не просто сторонній проект для Google. Google використовує його як основу для інших продуктів Google. А коли Google нещодавно замінив Megastore на Google Cloud Storage на Cloud Spanner, це дозволило Google Cloud Storage стати строго узгодженим для списків об'єктів у світовому масштабі (що, як і раніше, не стосується ).
Отже, надія є... ми сподіваємося.
На цьому все. Як і автор статті, ми теж продовжуємо сподіватися, а що ви думаєте з цього приводу? Пишіть у коментарі
Усіх бажаючих запрошуємо відвідати наш в рамках якого докладно розповімо про курс від OTUS.
Джерело: habr.com