Здравейте, хора от Хабра. Традиционно продължаваме да споделяме интересни материали в навечерието на старта на нови курсове. Днес специално за вас сме превели статия за 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%; многорегионални внедрения с SLA от 99,999%. Въпреки че самото споразумение за ниво на обслужване е просто споразумение и не представлява гаранция, вярвам, че колегите от 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 WHERE id IN (SELECT id FROM table1)
- Липса на опция за автоинкремент или нещо подобно, което задава последователност за полето ПК. За да работи това, съответната стойност трябва да бъде създадена от приложението.
Вторични индекси?
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 GB памет), и тестовият инстанс никога не представляваше тясно място в тестовете.
** Максималният брой потоци в един инстанс на YCSB е 400. Необходимо беше да се стартират шест паралелни инстанса на тестовете YCSB, за да се получи общо 2400 потока.
Гледайки резултатите от тестовете, в частност съчетанието на натоварването на процесора и TPS, ясно виждаме, че Cloud Spanner се мащабира доста добре. Голямото натоварване, генерирано от многобройни нишки, се компенсира от голямото количество възли в кластерa Cloud Spanner. Въпреки че закъснението изглежда доста високо, особено при работа с 2400 нишки, за получаване на по-точни числа може да се наложи повторно тестване с 6 по-малки екземпляра на изчислителния двигател. Всеки екземпляр ще стартира един тест YCSB вместо един голям инстанс CE с 6 паралелни теста. По този начин ще бъде по-лесно да се различат закъсненията на заявките на Cloud Spanner и закъсненията, добавени от мрежовото свързване между Cloud Spanner и инстанса CE, на който се извършва теста.
Как Cloud Spanner се справя като OLAP?
Партициониране?
Разделянето на данни на физически и/или логически независими сегменти, наричани партиции, е много популярна концепция, присъща за повечето механизми на OLAP. Партициите могат значително да подобрят производителността на заявките и поддръжката на базата данни. По-дълбокото разглеждане на партициите би излязло в отделна статия (статии), затова нека просто споменем важността на наличието на схема за партициониране и sub-партициониране. Способността да се разделят данните на партиции и дори по-нататък на подпартиции е ключова за производителността на аналитичните заявки.
Cloud Spanner не поддържа партиции като такива. Той разделя данните вътре на така наречените split-и на база диапазони на първичния ключ. Разделянето се извършва автоматично за балансиране на натоварването в кластерa Cloud Spanner. Много удобна функция на Cloud Spanner е разбирането на базовото натоварване на родителската таблица (таблицата, която не се редува с друга). Spanner автоматично определя дали split данните, които се четат по-често, отколкото данните в други split-и, и може да вземе решение за допълнително разделяне. По този начин, в заявката могат да бъдат включени повече възли, което също ефективно увеличава капацитета.
Зареждане на данни?
Метод Cloud Spanner за обемни данни е същият, както при обичайната зареждане. За да постигнете максимална производителност, трябва да следвате някои препоръки, включително:
- Сортирайте вашите данни по основния ключ.
- Разделете ги на 10*брой възли отделни секции.
- Създайте набор от работни задачи, които зареждат данни паралелно.
При такова зареждане на данни се използват всички възли на Cloud Spanner.
Използвахме работното натоварване A YCSB, за да генерираме набор от данни от 10M реда.
* Нагрузочното тестване беше извършено на изчислителния двигател n1-standard-32 (32 vCPU, 120 GB RAM), и тестовият инстанс никога не беше тясното място в тестовете.
** Настройката с 1 възел не се препоръчва за каквото и да е производствено натоварване.
Както беше споменато по-горе, Cloud Spanner автоматично обработва сплитовете в зависимост от товара им, така че резултатите се подобряват след няколко последователни повторения на теста. Резултатите, представени тук, са най-добрите, които получихме. Гледайки на числата по-горе, можем да видим как Cloud Spanner (добре) мащабира с увеличаването на броя възли в клъстера. Числата, които се открояват, представляват изключително ниски средни закъснения, които контрастират с резултатите от смесени работни товари (95% за четене и 5% за запис), както е описано в раздела по-горе.
Мащабиране?
Увеличаването и намаляването на броя на възлите Cloud Spanner е задача, изпълнявана с едно щракване. Ако искате бързо да заредите данни, можете да обмислите увеличаване на инстанса до максимума (в нашия случай това беше 25 възли в региона US-EAST), а след това да намалите броя на възлите, подходящи за вашето обичайно натоварване, след като всички данни са в базата данни, имайки предвид ограничението от 2 TB/възел.
Напомниха ни за това ограничение дори с много по-малка база данни. След няколко пробега на натоварващи тестове нашата база данни беше с размер около 155 GB, а при намаляване до инстанс с 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
