Сәлем, хабровиттер. Дәстүр бойынша біз жаңа курстардың басталу қарсаңында қызықты материалдармен бөлісуді жалғастырамыз. Бүгін, әсіресе сіз үшін, біз курстың басталуына орайластырылған Google Cloud Spanner туралы мақаланы аудардық. .
Бастапқыда жарияланған .
Дүние жүзіндегі бөлшек саудагерлер, рестораторлар және онлайн саудагерлер үшін бұлтқа негізделген POS шешімдерінің алуан түрін ұсынатын компания ретінде Lightspeed әртүрлі транзакциялық, аналитикалық және іздеуді пайдалану жағдайлары үшін дерекқор платформаларының бірнеше түрін пайдаланады. Осы дерекқор платформаларының әрқайсысының өзінің күшті және әлсіз жақтары бар.Сондықтан, Google Cloud Spanner-ді нарыққа ұсынғанда – реляциялық дерекқорлар әлемінде байқалмаған перспективалы мүмкіндіктер, мысалы, іс жүзінде шексіз көлденең масштабтау және 99,999% қызмет көрсету деңгейі келісімі (SLA) , Біз оның қолымызда болуы мүмкіндігін жіберіп алмадық!
Cloud Spanner-пен тәжірибемізге, сондай-ақ біз пайдаланған бағалау критерийлеріне толық шолу жасау үшін біз келесі тақырыптарды қарастырамыз:
- Біздің бағалау критерийлері
- Cloud Spanner қысқаша
- Біздің бағалауымыз
- Біздің қорытындылар
1. Біздің бағалау критерийлері
Cloud Spanner ерекшеліктеріне, оның нарықтағы басқа шешімдермен ұқсастықтары мен айырмашылықтарына кіріспес бұрын, алдымен Cloud Spanner-ті инфрақұрылымымызда қайда орналастыру керектігін қарастырған кезде негізгі пайдалану жағдайлары туралы сөйлесейік:
- (Үстем) дәстүрлі SQL дерекқор шешімін ауыстыру ретінде
- OLAP қосылған OLTP шешімі ретінде
Ескертпе: Салыстыруды жеңілдету үшін бұл мақалада Cloud Spanner GCP Cloud SQL және Amazon AWS RDS шешімдер тобының MySQL нұсқаларымен салыстырылады.
Cloud Spanner қолданбасын дәстүрлі SQL дерекқор шешімін ауыстыру ретінде пайдалану
Қоршаған ортада дәстүрлі дерекқор сұрауына жауап беру уақыты алдын ала анықталған қолданба шектеріне жақындағанда немесе тіпті асып кеткенде (ең алдымен пайдаланушылар және/немесе сұраулар санының артуына байланысты), жауап беру уақытын қолайлы деңгейге дейін қысқартудың бірнеше жолы бар. Дегенмен, бұл шешімдердің көпшілігі қолмен араласуды қамтиды.
Мысалы, бірінші орындалатын қадам өнімділікке қатысты әртүрлі дерекқор параметрлерін қарау және оларды қолданбаны пайдалану сценарий үлгілеріне ең жақсы сәйкестендіру үшін реттеу болып табылады. Бұл жеткіліксіз болса, дерекқорды тігінен немесе көлденеңінен масштабтауды таңдауға болады.
Қолданбаны масштабтау әдетте қосымша процессорларды/ядроларды, көбірек жедел жадты, жылдамырақ сақтауды және т.б. қосу арқылы сервер данасын жаңартуды талап етеді. Қосымша аппараттық ресурстарды қосу негізінен секундына транзакциялармен өлшенетін дерекқор өнімділігін арттырады және OLTP жүйелері үшін транзакция кідірісін береді. MySQL сияқты реляциялық дерекқор жүйелері (көп ағынды тәсілді қолданатын) тігінен жақсы масштабталады.
Бұл тәсілдің бірнеше кемшіліктері бар, бірақ ең айқыны нарықтағы сервердің максималды өлшемі болып табылады. Ең үлкен сервер данасы шегіне жеткенде, бір ғана жол қалады: масштабты кеңейту.
Масштабты кішірейту - бұл көбірек серверлер қосылған сайын өнімділікті сызықты түрде жоғарылату үшін кластерге көбірек серверлерді қосатын тәсіл. Көпшілік дәстүрлі дерекқор жүйелері жақсы масштабталмайды немесе мүлдем масштабталмайды. Мысалы, MySQL бағынышты оқырмандарды қосу арқылы оқу операцияларын кеңейте алады, бірақ жазу әрекеттері үшін масштабты кеңейте алмайды.
Екінші жағынан, табиғатына байланысты Cloud Spanner минималды араласумен көлденеңінен оңай масштабталады.
Толық сипатталған ДҚБЖ қызмет ретінде әртүрлі көзқарастармен бағалануы керек. Негіз ретінде біз бұлттағы ең танымал ДҚБЖ алдық - Google, GCP Cloud SQL және Amazon, AWS RDS үшін. Бағалау барысында біз келесі категорияларға назар аудардық:
- Мүмкіндіктерді салыстыру: SQL ауқымы, DDL, DML; қосылым кітапханалары/қосқыштары, транзакцияны қолдау және т.б.
- Дамытуды қолдау: әзірлеу және тестілеудің қарапайымдылығы.
- Әкімшілік қолдау: даналарды үлкейту/төмендету және жаңарту сияқты даналарды басқару; SLA, сақтық көшірме жасау және қалпына келтіру; қауіпсіздік/қолжетімділікті басқару.
Бұлтты кілтті OLAP қосылған OLTP шешімі ретінде пайдалану
Google Cloud Spanner аналитикаға арналғанын нақты айтпаса да, ол кейбір атрибуттарды OLAP жұмыс жүктемелеріне арналған Apache Impala & Kudu және YugaByte сияқты басқа қозғалтқыштармен бөліседі.
Cloud Spanner жүйесінде (артық немесе аз) қолдануға болатын OLAP мүмкіндіктері жиынтығы бар дәйекті кеңейтілетін HTAP (гибридті транзакциялық/аналитикалық өңдеу) қозғалтқышын қосу мүмкіндігі аз болса да, бұл біздің назарымызды аударады деп ойлаймыз.
Осыны ескере отырып, біз келесі категорияларды қарастырдық:
- Деректерді жүктеу, индекстер және бөлуді қолдау
- Сұрау өнімділігі және DML
2. Қысқаша Cloud Spanner
Google Spanner — Google өзінің бірнеше қызметтері үшін пайдаланатын кластерлік реляциялық дерекқорды басқару жүйесі (RDBMS). Google оны Google Cloud Platform пайдаланушыларына 2017 жылдың басында жалпыға қолжетімді етті.
Міне, Cloud Spanner атрибуттарының кейбірі:
- Жоғары дәйекті, масштабталатын RDBMS кластері: деректердің сәйкестігін қамтамасыз ету үшін аппараттық уақыт синхрондауды пайдаланады.
- Кесте аралық транзакцияны қолдау: транзакциялар бірнеше кестелерді қамтуы мүмкін - міндетті түрде бір кестемен шектелмейді (Apache HBase немесе Apache Kudu-дан айырмашылығы).
- Негізгі кілттерге негізделген кестелер: Барлық кестелерде бірнеше кесте бағандарынан тұруы мүмкін жарияланған Бастапқы кілт (ДК) болуы керек. Кестелік деректер ДК ретімен сақталады, бұл оны ДК іздеу үшін өте тиімді және жылдам етеді. Басқа компьютерге негізделген жүйелердегі сияқты, қол жеткізу үшін іске асыру алдын ала болжанған пайдалану жағдайларына қарсы үлгіленуі керек .
- Жолақты кестелер: кестелердің бір-біріне физикалық тәуелділіктері болуы мүмкін. Еншілес кестенің жолдарын ата-аналық кестенің жолдарымен сәйкестендіруге болады. Бұл тәсіл деректерді модельдеу сатысында анықтауға болатын қарым-қатынастарды іздеуді жылдамдатады, мысалы, тұтынушылар мен олардың шот-фактураларын бірге орналастыру кезінде.
- Индекстер: Cloud Spanner қосымша индекстерді қолдайды. Индекс индекстелген бағандардан және барлық ДК бағандарынан тұрады. Қажет болса, индексте басқа индекстелмеген бағандар да болуы мүмкін. Сұрауларды жылдамдату үшін индексті негізгі кестемен араластыруға болады. Индекстерде сақтауға болатын қосымша бағандардың ең көп саны сияқты индекстерге бірнеше шектеулер қолданылады. Сондай-ақ, индекстер арқылы сұраулар басқа RDBMS сияқты қарапайым болмауы мүмкін.
«Cloud Spanner сирек жағдайларда ғана индексті автоматты түрде таңдайды. Атап айтқанда, егер сұрау ішінде сақталмаған бағандарды сұраса, Cloud Spanner қосымша индексті автоматты түрде таңдамайды. «.
- Қызмет көрсету деңгейі туралы келісім (SLA): 99,99% SLA бар бір аймақты орналастыру; 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). Google ресми JDBC де қолдамайды.
"Драйверлер қазіргі уақытта DML немесе DDL мәлімдемелерін қолдамайды."
Spanner құжаттамасы
GCP консолімен жағдай жақсырақ емес - тек ТАҢДАУ сұрауларын жібере аласыз. Бақытымызға орай, қауымдастықтың, соның ішінде транзакциялардың DML және DDL қолдауы бар JDBC драйвері бар . Бұл драйвер өте пайдалы болғанымен, Google-дың жеке JDBC драйверінің жоқтығы таң қалдырады. Бақытымызға орай, Google (gRPC негізінде) өте кең клиенттік кітапхананы қолдауды ұсынады: C#, Go, Java, node.js, PHP, Python және Ruby.
Cloud Spanner реттелетін API интерфейстерін міндетті дерлік пайдалану (JDBC жүйесінде DDL және DML болмауына байланысты) қосылымды біріктіру немесе дерекқорды байланыстыру құрылымдары (мысалы, Spring MVC) сияқты кодтың қатысты аймақтары үшін кейбір шектеулерге әкеледі. Жалпы, JDBC пайдаланған кезде сынақтан өткен және жақсы жұмыс істейтін таңдаулы қосылым пулын (мысалы, HikariCP, DBCP, C3PO, т.б.) таңдауға болады. Пайдаланушы Spanner API интерфейстері жағдайында біз өзіміз жасаған фреймворктерге/байланыстыруға/сеанс пулдарына сенуіміз керек.
Бастапқы кілтке (ДК) бағытталған дизайн Cloud Spanner қолданбасына ДК арқылы деректерге қол жеткізу кезінде өте жылдам болуға мүмкіндік береді, сонымен қатар кейбір сұрау мәселелерін енгізеді.
- Бастапқы кілттің мәнін жаңарта алмайсыз; Алдымен компьютердің бастапқы жазбасын жойып, оны жаңа мәнмен қайта енгізу керек. (Бұл басқа компьютерге бағытталған дерекқор/сақтау қозғалтқыштарына ұқсас.)
- Кез келген UPDATE және DELETE операторлары ДК-ні WHERE параметрінде көрсетуі керек, сондықтан барлық операторларды DELETE бос болуы мүмкін емес - әрқашан ішкі сұрау болуы керек, мысалы: UPDATE 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 бір дана үшін ең көбі 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 данасын жасау өте қарапайым. Сізге тек көп аймақты немесе бір аймақтық дананы жасауды таңдау керек, аймақ(тар) мен түйіндер санын көрсетіңіз. Бір минуттан аз уақытта дана жұмыс істейді және жұмыс істейді.
Бірнеше қарапайым көрсеткіштер Google консоліндегі Spanner бетінде тікелей қолжетімді. Толығырақ көріністер Stackdriver арқылы қолжетімді, мұнда метрикалық шектерді және ескерту саясаттарын орнатуға болады.
Ресурстарға қол жеткізу?
MySQL кең және өте егжей-тегжейлі пайдаланушы рұқсат/рөл параметрлерін ұсынады. Белгілі бір кестеге немесе тіпті оның бағандарының ішкі жиынына кіруді оңай теңшеуге болады. Cloud Spanner Google Identity & Access Management (IAM) құралын пайдаланады, ол тек саясаттар мен рұқсаттарды өте жоғары деңгейде орнатуға мүмкіндік береді. Ең егжей-тегжейлі опция - дерекқор деңгейіндегі рұқсат, ол көптеген өндіріс жағдайларына сәйкес келмейді. Бұл шектеу Spanner ресурстарын рұқсатсыз пайдалануды болдырмау үшін кодыңызға, инфрақұрылымыңызға немесе екеуіне де қосымша қауіпсіздік шараларын қосуға мәжбүр етеді.
Сақтық көшірмелер?
Қарапайым тілмен айтқанда, Cloud Spanner қолданбасында сақтық көшірмелер жоқ. Google компаниясының жоғары SLA талаптары аппараттық құрал немесе дерекқор ақаулары, адам қателері, қолданба ақаулары және т.б. салдарынан ешқандай деректерді жоғалтпауыңызды қамтамасыз ете алады. Біз бәріміз ережені білеміз: жоғары қолжетімділік смарт сақтық көшірме жасау стратегиясын алмастыра алмайды. Қазіргі уақытта деректердің сақтық көшірмесін жасаудың жалғыз жолы - оларды дерекқордан бөлек сақтау ортасына бағдарламалық түрде ағынмен жіберу.
Сұрау өнімділігі?
Деректер мен сынақ сұрауларын жүктеу үшін Yahoo! Cloud Service Benchmark. Төмендегі кестеде 95% оқу мен 5% жазу қатынасы бар B YCSB жұмыс жүктемесі көрсетілген.
* Жүктеме сынағы n1-standart-32 Compute Engine (CE) (32 vCPU, 120 ГБ жад) жүйесінде орындалды және сынақ данасы ешқашан сынақтарда кедергі болған емес.
** Бір YCSB данасында ағындардың ең көп саны - 400. Барлығы 2400 ағынды алу үшін YCSB сынақтарының алты параллель данасын орындау керек болды.
Эталондық нәтижелерге, атап айтқанда CPU жүктемесі мен TPS комбинациясына қарап, біз Cloud Spanner өте жақсы масштабталатынын анық көреміз. Ағындардың көп санымен жасалған үлкен жүктеме Cloud Spanner кластеріндегі көптеген түйіндер санымен өтеледі. Кідіріс айтарлықтай жоғары болып көрінсе де, әсіресе 2400 ағынмен жұмыс істегенде, дәлірек сандарды алу үшін есептеу механизмінің 6 кіші данасымен қайта сынақтан өткізу қажет болуы мүмкін. Әрбір данада 6 параллель сынақтары бар бір үлкен CE данасы орнына бір YCSB сынағы орындалады. Бұл Cloud Spanner сұрауының кешігулері мен Cloud Spanner және сынақты жүргізетін CE данасы арасындағы желі қосылымы арқылы қосылған кідірістерді ажыратуды жеңілдетеді.
Cloud Spanner OLAP ретінде қалай жұмыс істейді?
Бөлу?
Деректерді бөлімдер деп аталатын физикалық және/немесе логикалық тәуелсіз сегменттерге бөлу OLAP қозғалтқыштарының көпшілігінде кездесетін өте танымал ұғым. Бөлімдер сұрау өнімділігін және дерекқорды қолдау мүмкіндігін айтарлықтай жақсарта алады. Бөлімге бөлуді одан әрі зерттеу жеке мақала(лар) болар еді, сондықтан бөлу схемасы мен қосалқы бөлімдердің болуының маңыздылығын атап өтейік. Деректерді бөлімдерге және одан әрі ішкі бөлімдерге бөлу мүмкіндігі аналитикалық сұрауларды орындаудың кілті болып табылады.
Cloud Spanner жеке бөлімдерді қолдамайды. Ол деректерді ішкі деп аталатындарға бөледі Сызат-s бастапқы кілт диапазондарына негізделген. Бөлу Cloud Spanner кластеріндегі жүктемені теңестіру үшін автоматты түрде орындалады. Cloud Spanner бағдарламасының өте ыңғайлы мүмкіндігі - негізгі кестенің негізгі жүктемесін бөлу (басқа кестемен араласпаған кесте). Spanner құрамында бар-жоғын автоматты түрде анықтайды Сызат басқа деректерге қарағанда жиі оқылатын деректер Сызат-ах, және одан әрі бөлу туралы шешім қабылдауы мүмкін. Осылайша, сұрауға көбірек түйіндер тартылуы мүмкін, бұл да өткізу қабілеттілігін тиімді арттырады.
Деректер жүктелуде ме?
Жаппай деректерге арналған Cloud Spanner әдісі әдеттегі жүктеп салумен бірдей. Максималды өнімділік үшін сіз кейбір нұсқауларды орындауыңыз керек, соның ішінде:
- Деректерді бастапқы кілт бойынша сұрыптаңыз.
- Оларды 10-ға бөліңіз*түйіндер саны жеке бөлімдер.
- Деректерді параллель жүктейтін жұмысшы тапсырмаларының жинағын жасаңыз.
Бұл деректер жүктемесі барлық Cloud Spanner түйіндерін пайдаланады.
Біз 10 миллион жолдық деректер жинағын жасау үшін A YCSB жұмыс жүктемесін қолдандық.
* Жүктеме сынағы n1-standart-32 есептеу қозғалтқышында (32 vCPU, 120 ГБ жад) орындалды және сынақ данасы ешқашан сынақтардағы кедергі болған емес.
** 1 түйінді орнату кез келген өндірістік жұмыс жүктемесі үшін ұсынылмайды.
Жоғарыда айтылғандай, Cloud Spanner сплиттерді олардың жүктемесіне байланысты автоматты түрде өңдейді, сондықтан сынақтың бірнеше қатарынан қайталануынан кейін нәтижелер жақсарады. Мұнда ұсынылған нәтижелер біз алған ең жақсы нәтижелер болып табылады. Жоғарыдағы сандарға қарап, кластердегі түйіндер саны артқан сайын Cloud Spanner қалай масштабталатынын (жақсы) көре аламыз. Жоғарыдағы бөлімде сипатталғандай аралас жұмыс жүктемелерінің (95% оқу және 5% жазу) нәтижелеріне қарама-қайшы келетін өте төмен орташа кідіріс.
Масштабтау?
Cloud Spanner түйіндерінің санын көбейту және азайту - бір рет басу арқылы орындалатын тапсырма. Деректерді жылдам жүктегіңіз келсе, дананы максимумға дейін арттыруды қарастырғыңыз келуі мүмкін (біздің жағдайда бұл АҚШ-ШЫҒЫС аймағындағы 25 түйін болды), содан кейін барлық деректерден кейін қалыпты жүктемеңізге сәйкес келетін түйіндер санын азайтыңыз. дерекқорда 2 ТБ/түйін шегін есте сақтай отырып.
Бұл шектеуді тіпті әлдеқайда аз дерекқормен де еске түсірдік. Бірнеше жүк сынауынан кейін біздің дерекқордың өлшемі шамамен 155 ГБ болды және 1 түйін данасына дейін кішірейтілгенде, біз келесі қатені алдық:
Біз 25-тен 2 данаға дейін кішірейте алдық, бірақ біз екі түйінде тұрып қалдық.
Cloud Spanner кластеріндегі түйіндер санын арттыру және азайтуды REST API арқылы автоматтандыруға болады. Бұл әсіресе бос емес уақытта жүйеге түсетін жүктемені азайту үшін пайдалы болуы мүмкін.
OLAP сұрауының өнімділігі?
Біз бастапқыда осы бөлігінде Спаннерді бағалауға көп уақыт бөлуді жоспарладық. Бірнеше ТАҢДАУ САНАУларынан кейін біз сынақтың қысқа болатынын және 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 шешімдерімен тең немесе кем дегенде олардан алыс емес деп күттік. Бірақ резервтік көшірмелердің толық болмауы және ресурстарға қол жеткізуді басқарудың өте шектеулі болуы бізді таң қалдырды. Көріністерді, жергілікті өңдеу ортасын, қолдау көрсетілмейтін тізбектерді, DML және DDL қолдауынсыз JDBC және т.б.
Сонымен, транзакциялық дерекқорды масштабтауды қажет ететін адамға қайда бару керек? Нарықта әлі барлық пайдалану жағдайларына сәйкес келетін жалғыз шешім жоқ сияқты. Көптеген жабық және ашық бастапқы шешімдер бар (олардың кейбіреулері осы мақалада айтылған), әрқайсысының күшті және әлсіз жақтары бар, бірақ олардың ешқайсысы 99,999% SLA және жоғары дәрежелі консистенциясы бар SaaS ұсынбайды. Егер жоғары SLA сіздің негізгі мақсатыңыз болса және сіз бірнеше бұлт үшін өз шешіміңізді құруға бейім болмасаңыз, Cloud Spanner сіз іздеген шешім болуы мүмкін. Бірақ сіз оның барлық шектеулерін білуіңіз керек.
Әділ болу үшін, Cloud Spanner көпшілікке 2017 жылдың көктемінде ғана шығарылды, сондықтан оның кейбір кемшіліктері ақырында жойылуы мүмкін (үміттенеміз) және ол жойылған кезде ол ойынды өзгерте алады деп күту орынды. Өйткені, Cloud Spanner Google үшін жай ғана қосалқы жоба емес. Google оны басқа Google өнімдері үшін негіз ретінде пайдаланады. Жақында Google Google Cloud Storage жүйесіндегі Megastore-ды Cloud Spanner-мен ауыстырған кезде, бұл Google Cloud Storage-ге жаһандық масштабтағы нысандар тізімдері үшін жоғары дәрежеде үйлесімді болуға мүмкіндік берді (бұл әлі де бірдей емес ).
Демек, әлі үміт бар... үміттенеміз.
Бар болғаны. Мақала авторы сияқты, біз де үміттенуді жалғастырамыз, бірақ бұл туралы не ойлайсыз? Түсініктемелерде жазыңыз
Барлығын қонаққа шақырамыз онда біз сізге курс туралы егжей-тегжейлі айтып береміз OTUS компаниясынан.
Ақпарат көзі: www.habr.com