Здраво, жители на Хабровск. Како и обично, продолжуваме да споделуваме интересни материјали пред почетокот на новите курсеви. Денес, специјално за вас, објавивме статија за 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, побрзо складирање итн. Системи за релациони бази на податоци (кои користат пристап со повеќе нишки) како што е MySQL добро вертикално се скалира.
Има неколку недостатоци на овој пристап, но најочигледна е максималната големина на серверот на пазарот. Откако ќе се достигне лимитот на примерот на најголемиот сервер, останува само една опција: хоризонтално скалирање.
Хоризонталното скалирање е пристап каде што повеќе сервери се додаваат во кластерот, идеално зголемувајќи ги перформансите линеарно како што се додава бројот на сервери. Мнозинството традиционален Системите за бази на податоци не се скалираат добро хоризонтално или воопшто не се скалираат. На пример, MySQL може да се скалира хоризонтално за операциите за читање со додавање slave читачи, но не може хоризонтално да се скалира за запишување.
Од друга страна, поради својата природа, Cloud Spanner лесно може да се скалира хоризонтално со минимална интервенција.
Целосно опремен DBMS како услуга мора да се процени од различни агли. Како основа, ги зедовме најпопуларните DBMS во облакот - за 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 поддржува секундарни индекси. Индексот се состои од индексирани колони и сите колони за компјутер. Доколку сакате, индексот може да содржи и други неиндексирани колони. Индексот може да се поврзе со матичната табела за да се забрзаат барањата. За индексите се применуваат неколку ограничувања, како што е максималниот број на дополнителни колони складирани во индексот. Исто така, барањата преку индекси можеби не се толку едноставни како во другите 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 DBMS на пазарот на облак, имаат многу голем сет на функции. Меѓутоа, за да ги размерите овие бази на податоци надвор од големината на еден јазол, треба да извршите партиционирање на апликациите. Овој пристап создава дополнителна сложеност и за апликациите и за администрацијата. Разгледавме како Spanner се вклопува во сценариото за комбинирање на повеќе парчиња во еден примерок и кои карактеристики (ако ги има) можеби ќе треба да се жртвуваат.
Поддршка за SQL, DML и DDL, како и конектор и библиотеки?
Прво, кога започнувате со која било база на податоци, треба да креирате модел на податоци. Ако мислите дека можете да го поврзете JDBC Spanner со вашата омилена алатка SQL, ќе откриете дека можете да ги побарате вашите податоци со неа, но не можете да го користите за да креирате табела или да менувате (DDL) или било какво вметнување/ажурирање/бришење операции (DML). Официјалниот JDBC на Google не поддржува ниту едно од овие.
„Возачите моментално не поддржуваат изјави за DML или DDL.
Документација за клуч
Ситуацијата не е подобра со 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, итн.) кој е тестиран и работи добро. Во случај на приспособени Spanner API, мора да се потпреме на рамки/обврзувачки базени/сесии што самите сме ги создале.
Дизајнот во центарот на примарниот клуч (PC) му овозможува на Cloud Spanner да биде многу брз при пристап до податоци преку компјутер, но исто така воведува и некои проблеми со барањето.
- Не можете да ја ажурирате вредноста на примарниот клуч; Прво мора да го избришете записот од оригиналниот компјутер и повторно да го вметнете со новата вредност. (Ова е слично на другите компјутерски ориентирани бази на податоци/мотори за складирање.)
- Сите изјави за ажурирање и бришење мора да го наведат компјутерот во WHERE, затоа не може да има празни DELETE сите изјави - секогаш мора да има подпрашање, на пример: АЖУРИРАЈ xxx WHERE id IN (ИЗБЕРИ ИД ОД табела1)
- Недостаток на опција за автоматско зголемување или нешто слично што ја поставува низата за полето за компјутер. За ова да функционира, соодветната вредност мора да се креира на страната на апликацијата.
Секундарни индекси?
Google Cloud Spanner има вградена поддршка за секундарни индекси. Ова е многу убава карактеристика што не е секогаш присутна кај другите технологии. Apache Kudu моментално воопшто не поддржува секундарни индекси, а Apache HBase не поддржува директно индекси, но може да ги додаде преку Apache Phoenix.
Индексите во Kudu и HBase може да се моделираат како посебна табела со различен состав на примарни клучеви, но атомичноста на операциите извршени на матичната табела и поврзаните индексни табели мора да се прават на ниво на апликација и не е тривијално правилно да се имплементира.
Како што беше споменато во прегледот на Cloud Spanner, неговите индекси може да се разликуваат од индексите на MySQL. Затоа, треба да се води посебна грижа при конструирање на прашања и профилирање за да се осигура дека правилниот индекс се користи онаму каде што е потребно.
Застапеност?
Многу популарен и корисен објект во базата на податоци е прегледите. Тие можат да бидат корисни за голем број случаи на употреба; моите два омилени се слојот за логичка апстракција и безбедносниот слој. За жал, Cloud Spanner НЕ поддржува прегледи. Сепак, ова само делумно нè ограничува бидејќи нема грануларност за дозволите за пристап на ниво на колона каде што прегледите може да бидат остварливо решение.
Видете ја документацијата Cloud Spanner за дел кој детално ги прикажува квотите и ограничувањата (), особено постои еден што може да биде проблематичен за некои апликации: Cloud Spanner out of the box има ограничување од максимум 100 бази на податоци по пример. Очигледно, ова може да биде големо тесно грло за базата на податоци што е дизајнирана да се размери на преку 100 бази на податоци. За среќа, откако разговаравме со нашиот технички претставник на Google, дознавме дека оваа граница може да се зголеми на речиси секоја вредност преку Поддршка на Google.
Развојна поддршка?
Cloud Spanner нуди прилично пристојна поддршка за програмски јазик за работа со својот API. Официјално поддржаните библиотеки се во областите C#, Go, Java, node.js, PHP, Python и Ruby. Документацијата е доста детална, но како и кај другите напредни технологии, заедницата е прилично мала во споредба со најпопуларните технологии за бази на податоци, што може да доведе до повеќе време потрошено за решавање на случаи или проблеми со поретко користење.
Што е со поддршката на локалниот развој?
Не најдовме начин да создадеме примерок на Cloud Spanner во просториите. Најблиску нешто што го добивме беше слика на Докер. , што е слично во принцип, но многу различно во пракса. На пример, CockroachDB може да користи PostgreSQL JDBC. Бидејќи развојната средина треба да биде што е можно поблиску до производствената средина, Cloud Spanner не е идеален бидејќи мора да се потпира на целосен примерок на Spanner. За да заштедите трошоци, можете да изберете примерок од еден регион.
Административна поддршка?
Создавањето пример на Cloud Spanner е многу едноставно. Треба само да изберете помеѓу создавање на пример од повеќе региони или еден регион, да го наведете регионот(ите) и бројот на јазли. За помалку од една минута, вашиот пример ќе биде во функција.
Неколку рудиментирани метрики се директно достапни од страницата Spanner во Google Console. Подетални прикази се достапни преку Stackdriver, каде што исто така можете да поставите метрички прагови и политики за предупредување.
Пристап до ресурси?
MySQL нуди обемни и многу грануларни поставки за кориснички дозволи/улоги. Можете лесно да го конфигурирате пристапот до одредена табела, па дури и само подмножество од нејзините колони. Cloud Spanner ја користи алатката за управување со идентитет и пристап (IAM) на Google, која ви дозволува само да поставувате политики и дозволи на многу високо ниво. Најгрануларна опција е резолуцијата на ниво на база на податоци, која не се вклопува во повеќето случаи на употреба во производството. Ова ограничување ве принудува да додадете дополнителни безбедносни мерки на вашиот код, инфраструктура или и двете за да спречите неовластено користење на ресурсите на Spanner.
Бекап?
Едноставно кажано, нема резервни копии во Cloud Spanner. Иако високите барања за SLA на Google можат да гарантираат дека нема да изгубите никакви податоци поради дефекти на хардверот или базата на податоци, човечки грешки, дефекти на апликацијата итн. Сите го знаеме правилото: високата достапност не е замена за стратегија за звучна резервна копија. Во моментов, единствениот начин да се направи резервна копија на податоците е програмски да се проследи од базата на податоци во посебна средина за складирање.
Прашајте ги перформансите?
Го користевме Yahoo! за вчитување податоци и тестирање прашања. Репер за сервирање во облак. Табелата подолу го прикажува обемот на работа на YCSB B со сооднос од 95% читање до 5% запишување.
* Тестот за оптоварување беше извршен на n1-стандард-32 компјутерски мотор (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 не поддржува партиции како такви. Ги дели податоците внатрешно на т.н се подели-и базирани на опсези на примарни клучеви. Поделбата се врши автоматски за да се балансира оптоварувањето во кластерот Cloud Spanner. Многу корисна карактеристика на Cloud Spanner е поделбата на основното оптоварување на матичната табела (табела што не е испреплетена со друга). Клучот автоматски открива дали содржи се подели податоци кои се читаат почесто од податоците во други се подели-ах, и може да одлучи за понатамошна разделба. На овој начин, повеќе јазли можат да бидат вклучени во барањето, што исто така ефикасно ја зголемува пропусната моќ.
Се вчитуваат податоци?
Методот Cloud Spanner за масовни податоци е ист како и за нормално вчитување. За да постигнете максимални перформанси, треба да следите некои упатства, вклучувајќи:
- Подредете ги вашите податоци по примарен клуч.
- Поделете ги со 10*број на јазли посебни делови.
- Направете збир на работни задачи кои паралелно вчитуваат податоци.
Ова вчитување податоци ги користи сите јазли на Cloud Spanner.
Го користевме обемот на работа на YCSB А за да генерираме база на податоци од 10 милиони редови.
* Тестот за оптоварување беше извршен на компјутерскиот мотор n1-стандард-32 (32 vCPU, 120 GB меморија) и примерокот за тестирање никогаш не беше тесно грло во тестовите.
**Поставувањето на еден јазол не се препорачува за какво било оптоварување на производството.
Како што споменавме погоре, Cloud Spanner автоматски ги обработува поделбите врз основа на нивното оптоварување, така што резултатите се подобруваат по неколку последователни повторувања на тестот. Резултатите презентирани овде се најдобрите резултати што ги добивме. Гледајќи ги горенаведените броеви, можеме да видиме како Cloud Spanner се скалира (добро) како што се зголемува бројот на јазли во кластерот. Бројките што се издвојуваат се екстремно ниските просечни латенции, кои се во спротивност со резултатите за мешани оптоварувања (95% читање и 5% пишување) како што е опишано во делот погоре.
Скалирање?
Зголемувањето и намалувањето на бројот на јазли на Cloud Spanner е задача со еден клик. Ако сакате брзо да ги вчитате податоците, може да размислите да го зголемите вашиот пример до максимум (во нашиот случај тоа беше 25 јазли во регионот САД-ИСТОК) и потоа да го намалите бројот на јазли што ги исполнуваат условите за вашето нормално оптоварување штом сите податоци ќе бидат внесени базата на податоци , повикувајќи се на границата од 2TB/јазол.
Се потсетивме на оваа граница дури и со многу помала база на податоци. По неколку тестирања на оптоварување, нашата база на податоци беше со големина од околу 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 со 99,999% SLA и висока конзистентност. Ако високата SLA е вашата главна цел и не сте склони да изградите приспособено решение за повеќе облаци, Cloud Spanner можеби е решението што го барате. Но, треба да бидете свесни за сите негови ограничувања.
Да бидеме фер, Cloud Spanner беше објавен во јавноста само во пролетта 2017 година, па разумно е да се очекува дека некои од неговите моментални недостатоци на крајот може да исчезнат (се надеваме), а кога ќе го направат тоа, тоа би можело да ја промени играта. На крајот на краиштата, Cloud Spanner не е само спореден проект за Google. Google го користи како основа за други производи на Google. И кога Google неодамна го замени Megastore во Google Cloud Storage со Cloud Spanner, му дозволи на Google Cloud Storage да стане многу конзистентен за списоци на објекти на глобално ниво (што сè уште не е случај за ).
Значи, има уште надеж... се надеваме.
Тоа е се. Како и авторот на статијата, ние исто така продолжуваме да се надеваме, но што мислите за ова? Напишете во коментарите
Ги покануваме сите да ја посетат нашата во чии рамки ќе ви кажеме детално за курсот од ОТУС.
Извор: www.habr.com