Прывітанне, хабраўчане. Традыцыйна працягваем дзяліцца цікавым матэрыялам напярэдадні старту новых курсаў. Сёння спецыяльна для вас мы перавялі артыкул аб 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. Усяго трэба было запусціць 2400 паралельных экзэмпляраў YCSB тэстаў, каб атрымаць у агульнай складанасці XNUMX патокаў.
Гледзячы на вынікі тэстаў, у прыватнасці спалучэнне нагрузкі на працэсар і 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 ГБ памяці), і тэставы інстанс ніколі не быў вузкім месцам у тэстах.
** Настройка з 1 вузла не рэкамендуецца для любой вытворчай нагрузкі.
Як згадвалася вышэй, 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