Здравейте, жители на Хабровск. Както обикновено, продължаваме да споделяме интересни материали преди началото на новите курсове. Днес, специално за вас, публикувахме статия за 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 база данни
В околната среда традиционен бази данни, когато времето за отговор на заявката към базата данни се доближава или дори надвишава предварително зададените прагове на приложението (главно поради увеличаване на броя на потребителите и/или заявките), има няколко начина за намаляване на времето за отговор до приемливи нива. Повечето от тези решения обаче включват ръчна намеса.
Например, първата стъпка, която трябва да предприемете, е да разгледате различните параметри на базата данни, свързани с производителността, и да ги настроите така, че да съответстват най-добре на моделите на случаи на използване на приложението. Ако това не е достатъчно, можете да изберете да мащабирате базата данни вертикално или хоризонтално.
Вертикалното мащабиране на приложение включва надграждане на екземпляра на сървъра, обикновено чрез добавяне на повече процесори/ядра, повече RAM, по-бързо съхранение и т.н. Добавянето на повече хардуерни ресурси води до повишена производителност на базата данни, измерена предимно в транзакции в секунда, и латентност на транзакция за OLTP системи. Системите за релационни бази данни (които използват многонишков подход) като MySQL се мащабират добре вертикално.
Има няколко недостатъка на този подход, но най-очевидният е максималният размер на сървъра на пазара. След като бъде достигнат лимитът на най-голямото сървърно копие, остава само една опция: хоризонтално мащабиране.
Хоризонталното мащабиране е подход, при който към клъстер се добавят повече сървъри, като в идеалния случай производителността се увеличава линейно с добавянето на броя на сървърите. Мнозинство традиционен Системите с бази данни не се мащабират хоризонтално добре или изобщо не се мащабират. Например MySQL може да мащабира хоризонтално за операции за четене чрез добавяне на подчинени четци, но не може да мащабира хоризонтално за записи.
От друга страна, поради естеството си, 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 е клъстерна система за управление на релационни бази данни (RDBMS), която Google използва за няколко от собствените си услуги. Google го направи общодостъпен за потребителите на Google Cloud Platform в началото на 2017 г.
Ето някои от атрибутите на Cloud Spanner:
- Силно съгласуван мащабируем RDBMS клъстер: Използва хардуерна времева синхронизация, за да осигури съгласуваност на данните.
- Поддръжка на транзакции между таблици: Транзакциите могат да обхващат множество таблици - не е задължително да се ограничават до една таблица (за разлика от Apache HBase или Apache Kudu).
- Базирани на първичен ключ таблици: Всички таблици трябва да имат деклариран първичен ключ (PC), който може да се състои от множество колони в таблицата. Табличните данни се съхраняват в компютърен ред, което го прави много ефективно и бързо за компютърно търсене. Подобно на други компютърно-базирани системи, внедряването трябва да се моделира с предварително проектирани случаи на употреба, за да се постигне .
- Раирани маси: Таблиците могат да имат физически зависимости една от друга. Редове в дъщерна таблица могат да бъдат съпоставени с редове в родителска таблица. Този подход ускорява търсенето на връзки, които могат да бъдат идентифицирани по време на фазата на моделиране на данни, като съвместно намиране на клиенти и техните фактури.
- Индекси: Cloud Spanner поддържа вторични индекси. Индексът се състои от индексираните колони и всички PC колони. Ако желаете, индексът може да съдържа и други неиндексирани колони. Индексът може да се преплита с родителската таблица, за да се ускорят заявките. За индексите се прилагат няколко ограничения, като например максималния брой допълнителни колони, съхранявани в индекса. Освен това заявките чрез индекси може да не са толкова ясни, колкото в други RDBMS.
„Cloud Spanner избира индекс автоматично само в редки случаи. По-специално, Cloud Spanner не избира автоматично вторичен индекс, ако заявка изисква колони, които не се съхраняват в ".
- Споразумение за ниво на обслужване (SLA): Внедряване в един регион със SLA от 99,99%; мултирегионални внедрявания с 99,999% SLA. Въпреки че самото 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, ние трябва да разчитаме на рамки/обвързващи пулове/сесии, които сме създали сами.
Централният дизайн на първичния ключ (PC) позволява на Cloud Spanner да бъде много бърз при достъп до данни през компютър, но също така въвежда някои проблеми със заявките.
- Не можете да актуализирате стойността на първичния ключ; Първо трябва да изтриете записа от оригиналния компютър и да го поставите отново с новата стойност. (Това е подобно на други компютърно ориентирани машини за база данни/съхранение.)
- Всички оператори UPDATE и DELETE трябва да указват PC в WHERE, следователно не може да има празни оператори DELETE all - винаги трябва да има подзаявка, например: UPDATE xxx WHERE id IN (SELECT id FROM table1)
- Липса на опция за автоматично нарастване или нещо подобно, което задава последователността за полето PC. За да работи това, съответната стойност трябва да бъде създадена от страната на приложението.
Вторични индекси?
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 Console. По-подробни изгледи са достъпни чрез Stackdriver, където можете също да зададете прагове на показатели и правила за предупреждение.
Достъп до ресурси?
MySQL предлага обширни и много подробни настройки за потребителски права/роли. Можете лесно да конфигурирате достъпа до конкретна таблица или дори само до подмножество от нейните колони. Cloud Spanner използва инструмента на Google за управление на самоличността и достъпа (IAM), който ви позволява да задавате правила и разрешения само на много високо ниво. Най-подробната опция е разделителната способност на ниво база данни, която не се вписва в повечето случаи на производствена употреба. Това ограничение ви принуждава да добавите допълнителни мерки за сигурност към вашия код, инфраструктура или и двете, за да предотвратите неоторизирано използване на ресурсите на Spanner.
Архивиране?
Казано по-просто, в Cloud Spanner няма резервни копия. Въпреки че високите изисквания на Google за SLA могат да гарантират, че няма да загубите данни поради повреди в хардуера или базата данни, човешки грешки, дефекти на приложенията и т.н. Всички знаем правилото: високата достъпност не е заместител на надеждната стратегия за архивиране. Понастоящем единственият начин за архивиране на данни е програмното им предаване от база данни към отделна среда за съхранение.
Изпълнение на заявката?
Използвахме Yahoo! за зареждане на данни и тестване на заявки. Облачно обслужване Бенчмарк. Таблицата по-долу показва YCSB работно натоварване B със съотношение 95% четене към 5% запис.
* Тестът за натоварване беше проведен на n1-standard-32 Compute Engine (CE) (32 vCPU, 120 GB памет) и тестовият екземпляр никога не е бил тясно място в тестовете.
** Максималният брой нишки в един екземпляр на YCSB е 400. Трябваше да се изпълнят общо шест паралелни екземпляра на YCSB тестове, за да се получат общо 2400 нишки.
Разглеждайки резултатите от бенчмарка, особено комбинацията от натоварване на процесора и TPS, можем ясно да видим, че Cloud Spanner се мащабира доста добре. Голямото натоварване, създадено от големия брой нишки, се компенсира от големия брой възли в клъстера Cloud Spanner. Въпреки че латентността изглежда доста висока, особено при работа с 2400 нишки, може да се наложи повторно тестване с 6 по-малки екземпляра на изчислителната машина, за да получите по-точни числа. Всеки екземпляр ще изпълнява един YCSB тест вместо един голям CE екземпляр с 6 паралелни теста. По този начин ще бъде по-лесно да се направи разлика между латентността на заявката на Cloud Spanner и латентността, добавена от мрежовата връзка между Cloud Spanner и CE екземпляра, изпълняващ теста.
Как работи Cloud Spanner като OLAP?
Разделяне?
Разделянето на данни на физически и/или логически независими сегменти, наречени дялове, е много популярна концепция, която се среща в повечето OLAP машини. Разделенията могат значително да подобрят производителността на заявките и поддръжката на базата данни. Задълбочаването на разделянето би било отделна(и) статия(и), така че нека просто споменем важността на наличието на схема за разделяне и подразделяне. Способността да се разделят данните на дялове и дори по-нататък на подразделения е ключова за ефективността на аналитичните заявки.
Cloud Spanner не поддържа дялове като такива. Той разделя данните вътрешно на т.нар разделят-s въз основа на диапазони на първичен ключ. Разделянето се извършва автоматично, за да се балансира натоварването в клъстер Cloud Spanner. Много полезна функция на Cloud Spanner е разделянето на базовото натоварване на родителската таблица (таблица, която не се преплита с друга). Spanner автоматично разпознава дали съдържа разделят данни, които се четат по-често от данните в други разделят-а, и може да вземе решение за по-нататъшна раздяла. По този начин повече възли могат да бъдат включени в заявка, което също така ефективно увеличава пропускателната способност.
Зареждане на данни?
Методът Cloud Spanner за групови данни е същият като при нормално зареждане. За да постигнете максимална производителност, трябва да следвате някои насоки, включително:
- Сортирайте данните си по първичен ключ.
- Разделете ги на 10*брой възли отделни секции.
- Създайте набор от работни задачи, които зареждат данни паралелно.
Това зареждане на данни използва всички възли на Cloud Spanner.
Използвахме работно натоварване A на YCSB, за да генерираме набор от данни от 10 милиона реда.
* Тестът за натоварване беше проведен на n1-standard-32 compute engine (32 vCPU, 120 GB памет) и тестовият екземпляр никога не е бил тясно място в тестовете.
**Настройката на единичен възел не се препоръчва за производствено натоварване.
Както бе споменато по-горе, Cloud Spanner автоматично обработва разделянията въз основа на тяхното натоварване, така че резултатите се подобряват след няколко последователни повторения на теста. Представените тук резултати са най-добрите резултати, които получихме. Разглеждайки числата по-горе, можем да видим как Cloud Spanner се мащабира (добре) с увеличаването на броя на възлите в клъстера. Числата, които се открояват, са изключително ниските средни закъснения, които контрастират с резултатите за смесени натоварвания (95% четене и 5% запис), както е описано в раздела по-горе.
Мащабиране?
Увеличаването и намаляването на броя на възлите на Cloud Spanner е задача с едно щракване. Ако искате да заредите данни бързо, може да обмислите да увеличите своя екземпляр до максимум (в нашия случай това бяха 25 възли в региона US-EAST) и след това да намалите броя на възлите, отговарящи на условията за вашето нормално зареждане, след като всички данни са в базата данни, като се има предвид ограничението от 2TB/възел.
Беше ни напомнено за това ограничение дори с много по-малка база данни. След няколко изпълнения на тестове за натоварване нашата база данни беше с размер около 155 GB и когато беше намалена до екземпляр от 1 възел, получихме следната грешка:
Успяхме да намалим мащаба от 25 на 2 екземпляра, но останахме в два възела.
Увеличаването и намаляването на броя на възлите в клъстер Cloud Spanner може да се автоматизира с помощта на REST API. Това може да бъде особено полезно за намаляване на повишеното натоварване на системата по време на натоварени работни часове.
Изпълнение на OLAP заявки?
Първоначално планирахме да отделим значително време в нашата оценка на Spanner по тази част. След няколко SELECT COUNTs веднага осъзнахме, че тестването ще бъде кратко и че Spanner НЯМА да бъде подходящ двигател за OLAP. Независимо от броя на възлите в клъстера, простото избиране на броя редове в таблица с редове от 10 милиона отне между 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 с 99,999% SLA и висока последователност. Ако високото SLA е вашата основна цел и не сте склонни да изграждате персонализирано мулти-облачно решение, Cloud Spanner може да е решението, което търсите. Но трябва да сте наясно с всичките му ограничения.
За да бъда честен, Cloud Spanner беше пуснат за обществеността едва през пролетта на 2017 г., така че е разумно да се очаква, че някои от настоящите му недостатъци може в крайна сметка да изчезнат (да се надяваме), а когато това стане, това може да промени играта. В крайна сметка Cloud Spanner не е просто страничен проект за Google. Google го използва като основа за други продукти на Google. И когато Google наскоро замени Megastore в Google Cloud Storage с Cloud Spanner, това позволи на Google Cloud Storage да стане много последователен за списъци с обекти в глобален мащаб (което все още не е така за ).
Така че все още има надежда... надяваме се.
Това е всичко. Подобно на автора на статията, ние също продължаваме да се надяваме, но какво мислите вие за това? Пишете в коментарите
Каним всички да посетят нашата в рамките на който ще ви разкажем подробно за курса от OTUS.
Източник: www.habr.com