{"id":69568,"date":"2020-02-20T15:24:23","date_gmt":"2020-02-20T12:24:23","guid":{"rendered":"https:\/\/prohoster.info\/blog\/google-cloud-spanner-horoshij-plohoj-zloj"},"modified":"2020-03-03T16:14:50","modified_gmt":"2020-03-03T13:14:50","slug":"google-cloud-spanner-horoshij-plohoj-zloj","status":"publish","type":"post","link":"https:\/\/prohoster.info\/no\/blog\/administrirovanie\/google-cloud-spanner-horoshij-plohoj-zloj","title":{"rendered":"Google Cloud Spanner: bra, vond, stygg","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><b><i>Hei, Habr-folk. Vi fortsetter tradisjonen med \u00e5 dele interessant materiell i forkant av starten av nye kurs. I dag har vi spesialtilpasset en artikkel om Google Cloud Spanner, tilknyttet lanseringen av kurset. <noindex><a rel=\"nofollow\" href=\"https:\/\/otus.pw\/eoP2\/\">\u00abAWS for utviklere\u00bb<\/a><\/noindex>.<\/i><\/b><\/p>\n<p><img decoding=\"async\" alt=\"Google Cloud Spanner: bra, vond, stygg\" src=\"\/wp-content\/uploads\/2020\/02\/b27b8a09543d10b078480c317553ca46.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<i>Opprinnelig publisert i <noindex><a rel=\"nofollow\" href=\"https:\/\/www.lightspeedhq.com\/blog\/\">bloggen til Lightspeed HQ<\/a><\/noindex>.<\/i><\/p>\n<p>Som et selskap som tilbyr en rekke skybaserte POS-l\u00f8sninger for detaljhandel, restauranter og nettbutikker over hele verden, bruker Lightspeed flere forskjellige typer databaser for mange transaksjons-, analyse- og s\u00f8kesaker. Hver av disse databaseplattformene har sine egne styrker og svakheter. Derfor, n\u00e5r Google introduserte Cloud Spanner p\u00e5 markedet \u2014 lovende funksjoner aldri sett f\u00f8r innen relasjonsdatabaser, som praktisk talt ubegrenset horisontal skalerbarhet og 99,999% tjenesteniv\u00e5avtale (SLA) \u2014 kunne vi ikke g\u00e5 glipp av sjansen til \u00e5 f\u00e5 tak i det!<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\nFor \u00e5 gi en omfattende oversikt over v\u00e5r erfaring med Cloud Spanner, samt vurderingskriteriene vi brukte, vil vi se p\u00e5 f\u00f8lgende emner:<\/p>\n<ol>\n<li>V\u00e5re vurderingskriterier<\/li>\n<li>Cloud Spanner i korte trekk<\/li>\n<li>V\u00e5r vurdering<\/li>\n<li>V\u00e5re konklusjoner<\/li>\n<\/ol>\n<p>\n<img decoding=\"async\" alt=\"Google Cloud Spanner: bra, vond, stygg\" src=\"\/wp-content\/uploads\/2020\/02\/29ed599362fb189283faa9215c18297a.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>1. V\u00e5re vurderingskriterier<\/h2>\n<p>\nF\u00f8r vi dykker inn i funksjonene til Cloud Spanner, dens likheter og forskjeller med andre l\u00f8sninger p\u00e5 markedet, la oss f\u00f8rst snakke om de grunnleggende bruksomr\u00e5dene vi hadde i tankene da vi vurderte hvor vi skulle implementere Cloud Spanner i v\u00e5r infrastruktur:<\/p>\n<ul>\n<li>Som en erstatning for (dominerende) tradisjonelle SQL-database l\u00f8sninger<\/li>\n<li>Som en OLTP-l\u00f8sning med OLAP-st\u00f8tte<\/li>\n<\/ul>\n<p><\/p>\n<blockquote><p><i><b>Merk:<\/b> For enkelhets skyld sammenligner denne artikkelen Cloud Spanner med MySQL-varianter fra GCP Cloud SQL-familien og Amazon AWS RDS.<\/i><\/p><\/blockquote>\n<p><\/p>\n<h4>Bruk av Cloud Spanner som en erstatning for tradisjonelle SQL-database l\u00f8sninger<\/h4>\n<p>\nI et milj\u00f8 <i>av tradisjonelle <\/i>databaser, n\u00e5r responstiden for sp\u00f8rringer til databasen n\u00e6rmer seg eller til og med overskrider forh\u00e5ndsdefinerte terskler for applikasjonen (hovedsakelig p\u00e5 grunn av \u00f8kt antall brukere og\/eller foresp\u00f8rseler), finnes det flere m\u00e5ter \u00e5 redusere responstiden til akseptable niv\u00e5er. Imidlertid inneb\u00e6rer de fleste av disse l\u00f8sningene manuell inngripen.<\/p>\n<p>For example, the first step to take is to look at the various database parameters related to performance and configure them to best match application usage patterns. If this is insufficient, one can opt for vertical or horizontal database scaling.<\/p>\n<p>Vertical scaling of an application involves upgrading the server instance, typically by adding more processors\/cores, more RAM, faster storage, etc. Adding more hardware resources results in increased database performance, primarily measured in transactions per second and transaction latency for OLTP systems. Relational database systems (which use a multithreaded approach), like MySQL, scale well vertically.<\/p>\n<p>This approach has several drawbacks, but the most obvious one is the maximum server size on the market. Once the limit of the largest server instance is reached, there is only one way left: horizontal scaling.<\/p>\n<p>Horizontal scaling is an approach where more servers are added to the cluster, ideally linearly increasing performance with the addition of more servers. Most <i>av tradisjonelle <\/i>database systems scale poorly horizontally or do not scale at all. For example, MySQL can horizontally scale for read operations by adding slave readers, but it cannot horizontally scale for write operations.<\/p>\n<p>On the other hand, due to its nature, Cloud Spanner can easily scale horizontally with minimal intervention.<\/p>\n<p>Full-fledged<i> DBMS as a service<\/i> should be evaluated from different angles. As a basis, we took the most popular cloud DBMS \u2014 Google's GCP Cloud SQL and Amazon's AWS RDS. In our evaluation, we focused on the following categories:<\/p>\n<ul>\n<li>Feature comparisons: SQL extent, DDL, DML; connection libraries\/connectors, transaction support, and so on.<\/li>\n<li>Development support: ease of development and testing.<\/li>\n<li>Administrasjonsst\u00f8tte: h\u00e5ndtering av instanser \u2014 for eksempel opp- og nedskaleringsh\u00e5ndtering og oppgradering av instanser; SLA, sikkerhetskopiering og gjenoppretting; sikkerhet\/tilgangskontroll.<\/li>\n<\/ul>\n<p><\/p>\n<h4>Bruk av Cloud Spanner som en OLTP-l\u00f8sning med OLAP-st\u00f8tte.<\/h4>\n<p>\nSelv om Google ikke eksplisitt sier at Cloud Spanner er laget for analytisk behandling, deler det noen attributter med andre motorer som Apache Impala &amp; Kudu og YugaByte, som er laget for OLAP-arbeidsbelastninger.<\/p>\n<p>Selv om det kun ville v\u00e6rt en liten sjanse for at Cloud Spanner inkluderte en konsistent horisontalt skalerbar HTAP-motor (hybrid transaksjons\/analytisk prosessering) med (mer eller mindre) et brukbart sett med OLAP-funksjoner, mener vi at det ville fortjent v\u00e5r oppmerksomhet.<\/p>\n<p>Med dette i tankene, har vi vurdert f\u00f8lgende kategorier:<\/p>\n<ul>\n<li>Datainntak, indekser og st\u00f8tte for partisjonering.<\/li>\n<li>Sp\u00f8rringsytelse og DML.<\/li>\n<\/ul>\n<p><\/p>\n<h2>2. Cloud Spanner p\u00e5 en setning.<\/h2>\n<p>\nGoogle Spanner er et klyngebasert system for administrasjon av relasjonsdatabaser (RDBMS) som Google bruker for flere av sine egne tjenester. Google gjorde det tilgjengelig for brukere av Google Cloud Platform tidlig i 2017.<\/p>\n<p>Her er noen av attributtene til Cloud Spanner:<\/p>\n<ul>\n<li>Sv\u00e6rt konsistent skalerbar RDBMS-klynge: bruker maskinvare-tidsynkronisering for \u00e5 sikre datakonsistens.<\/li>\n<li>St\u00f8tte for tverr-tabelltransaksjoner: transaksjoner kan dekke flere tabeller \u2014 ikke n\u00f8dvendigvis begrenset til \u00e9n tabel (i motsetning til Apache HBase eller Apache Kudu).<\/li>\n<li>Tabeller basert p\u00e5 prim\u00e6rn\u00f8kkel: alle tabeller m\u00e5 ha en deklarert prim\u00e6rn\u00f8kkel (PK), som kan best\u00e5 av flere kolonner i tabellen. Tabelldata lagres i PK-rekkef\u00f8lge, noe som gj\u00f8r dem sv\u00e6rt effektive og raske \u00e5 s\u00f8ke etter p\u00e5 PK. Som andre systemer basert p\u00e5 PK, m\u00e5 implementeringen v\u00e6re modellert med tanke p\u00e5 n\u00f8ye gjennomtenkte bruksomr\u00e5der for \u00e5 oppn\u00e5 <noindex><a rel=\"nofollow\" href=\"https:\/\/cloud.google.com\/spanner\/docs\/schema-and-data-model\">den beste ytelsen.<\/a><\/noindex>.<\/li>\n<li>Vekslende tabeller: tabeller kan ha fysiske avhengigheter til hverandre. Rader i underliggende tabeller kan knyttes til rader i overordnede tabeller. Denne tiln\u00e6rmingen akselererer s\u00f8ket etter relasjoner, som kan defineres i datamodelleringsfasen, for eksempel n\u00e5r kunder og deres fakturaer plasseres sammen.<\/li>\n<li>Indekser: Cloud Spanner st\u00f8tter sekund\u00e6re indekser. En indeks best\u00e5r av indekserte kolonner og alle kolonnene i prim\u00e6rn\u00f8kkelen. Indeksen kan ogs\u00e5 inneholde andre ikke-indekserte kolonner. Indeksen kan vekslende sammen med den overordnede tabellen for \u00e5 akselerere foresp\u00f8rslene. Det gjelder flere restriksjoner for indekser, for eksempel maksimalt antall ekstra kolonner som lagres i indekser. Foresp\u00f8rslene via indekser kan ogs\u00e5 v\u00e6re mindre direkte enn i andre RDBMS.<\/li>\n<\/ul>\n<p>\n<i>\u00abCloud Spanner velger automatisk indekser kun i sjeldne tilfeller. Spesielt velger Cloud Spanner ikke sekund\u00e6re indekser automatisk hvis foresp\u00f8rselen ber om noen kolonner som ikke er lagret i <noindex><a rel=\"nofollow\" href=\"https:\/\/cloud.google.com\/spanner\/docs\/secondary-indexes\">indeksen <\/a><\/noindex>\u00bb.<\/i><\/p>\n<ul>\n<li>Service Level Agreement (SLA): distribusjon i \u00e9n region med SLA p\u00e5 99,99%; multiregionale distribusjoner med 99,999% SLA. Selv om selve SLA-en bare er en avtale og ingen garanti, tror jeg at Google-ansatte virkelig har noen n\u00f8yaktige data for \u00e5 gj\u00f8re en s\u00e5 alvorlig uttalelse. (Til referanse betyr 99,999% 26,3 sekunder uverdig tilgjengelighet per m\u00e5ned.)<\/li>\n<li>Mer: <noindex><a rel=\"nofollow\" href=\"https:\/\/cloud.google.com\/spanner\/\">https:\/\/cloud.google.com\/spanner\/<\/a><\/noindex><\/li>\n<\/ul>\n<p><\/p>\n<blockquote><p><i><b>Merk:<\/b> Apache Tephra-prosjektet legger til utvidet st\u00f8tte for transaksjoner i Apache HBase (n\u00e5 ogs\u00e5 implementert i Apache Phoenix i beta).<\/i><\/p><\/blockquote>\n<p><\/p>\n<h2>3. V\u00e5r vurdering<\/h2>\n<p>\nS\u00e5 vi har alle lest Googles p\u00e5stander om fordelene med Cloud Spanner \u2014 praktisk talt ubegrenset horisontal skalerbarhet med h\u00f8y konsistens og sv\u00e6rt h\u00f8y SLA. Selv om det er ekstremt vanskelig \u00e5 oppn\u00e5 disse kravene, var v\u00e5r hensikt ikke \u00e5 motbevise dem. I stedet skal vi fokusere p\u00e5 andre ting som bekymrer de fleste databasebrukere: klarhet og brukervennlighet.<\/p>\n<h4>Vi vurderte Cloud Spanner som en erstatning for Sharded MySQL<\/h4>\n<p>\nGoogle Cloud SQL og Amazon AWS RDS, to av de mest popul\u00e6re OLTP-databasene p\u00e5 skymarkedet, har et omfattende sett med funksjoner. Imidlertid, for \u00e5 skalere disse databasene utover st\u00f8rrelsen p\u00e5 en enkelt node, m\u00e5 du implementere applikasjonsdeltakelse. Denne tiln\u00e6rmingen skaper ekstra kompleksitet b\u00e5de for applikasjonene og for administrasjonen. Vi har sett p\u00e5 hvordan Spanner passer inn i scenariet for \u00e5 kombinere flere segmenter til \u00e9n instans, og hvilke funksjoner (hvis noen) som kanskje m\u00e5 ofres.<\/p>\n<h4>St\u00f8tte for SQL, DML og DDL, samt koblinger og biblioteker?<\/h4>\n<p>\nFor det f\u00f8rste, n\u00e5r du arbeider med en database, m\u00e5 du lage en datamodell. Hvis du tror at du kan koble JDBC Spanner til ditt favoritt SQL-verkt\u00f8y, vil du oppdage at du kan bruke det til \u00e5 foresp\u00f8rre dataene dine, men ikke for \u00e5 opprette tabeller eller endre (DDL) eller utf\u00f8re noen innsettings-\/oppdaterings-\/slettingsoperasjoner (DML). Googles offisielle JDBC st\u00f8tter verken det ene eller det andre.<\/p>\n<blockquote><p><i>\u00abFor tiden st\u00f8tter ikke driverne DML- eller DDL-operasjoner\u00bb.<\/i><br \/>\nSpanner-dokumentasjon<\/p><\/blockquote>\n<p>\nSituasjonen med GCP-konsollen er ikke bedre \u2014 du kan kun sende SELECT-sp\u00f8rsm\u00e5l. Heldigvis finnes det en JDBC-driver med st\u00f8tte for DML og DDL fra fellesskapet, inkludert transaksjoner. <noindex><a rel=\"nofollow\" href=\"http:\/\/github.com\/olavloite\/spanner-jdbc\">github.com\/olavloite\/spanner-jdbc<\/a><\/noindex>. Selv om denne driveren er ekstremt nyttig, er det overraskende at Google ikke har en egen JDBC-driver. Heldigvis tilbyr Google ganske omfattende st\u00f8tte for klientbiblioteker (basert p\u00e5 gRPC): C#, Go, Java, node.js, PHP, Python og Ruby.<\/p>\n<p>Det praktisk talt obligatoriske bruken av tilpassede API-grensesnitt for Cloud Spanner (p\u00e5 grunn av mangel p\u00e5 DDL og DML i JDBC) f\u00f8rer til visse begrensninger for relaterte kodeomr\u00e5der, som tilkoblingspuljer eller databindingsrammeverk (for eksempel Spring MVC). Generelt, n\u00e5r du bruker JDBC, kan du fritt velge favoritt tilkoblingspuljen (f.eks. HikariCP, DBCP, C3PO osv.) som er testet og fungerer bra. N\u00e5r det gjelder tilpassede Spanner-API-er, m\u00e5 vi stole p\u00e5 rammeverk\/puljer for binding\/\u00f8kter som vi har utviklet selv.<\/p>\n<p>Konstruksjonen som er orientert mot prim\u00e6rn\u00f8kkelen (PK), gj\u00f8r at Cloud Spanner er sv\u00e6rt rask n\u00e5r det gjelder datatilgang gjennom PK, men det f\u00f8rer ogs\u00e5 til visse problemer med sp\u00f8rringer.<\/p>\n<ul>\n<li>Du kan ikke oppdatere verdien av prim\u00e6rn\u00f8kkelen; du m\u00e5 f\u00f8rst slette posten med den originale PK-en og sette inn en ny med den nye verdien. (Dette ligner p\u00e5 andre PK-orienterte databaser\/lagringsmekanismer.)<\/li>\n<li>Alle UPDATE- og DELETE-operat\u00f8rer m\u00e5 spesifisere PK i WHERE, og derfor kan det ikke v\u00e6re tomme DELETE all-operat\u00f8rer \u2014 det m\u00e5 alltid v\u00e6re en underforesp\u00f8rsel, for eksempel: UPDATE xxx WHERE id IN (SELECT id FROM table1)<\/li>\n<li>Mangelen p\u00e5 en autoinkrementalternativ eller noe lignende som setter sekvensen for PK-feltet. For at dette skal fungere, m\u00e5 den aktuelle verdien opprettes p\u00e5 applikasjonssiden.<\/li>\n<\/ul>\n<p><\/p>\n<h4>Sekund\u00e6re indekser?<\/h4>\n<p>\nGoogle Cloud Spanner har innebygd st\u00f8tte for sekund\u00e6re indekser. Dette er en veldig fin funksjon som ikke alltid er tilgjengelig i andre teknologier. Apache Kudu st\u00f8tter for \u00f8yeblikket ikke sekund\u00e6re indekser i det hele tatt, mens Apache HBase ikke st\u00f8tter indekser direkte, men kan legge dem til via Apache Phoenix.<\/p>\n<p>Indekser i Kudu og HBase kan modelleres som en egen tabell med forskjellige prim\u00e6rn\u00f8kkelkombinasjoner, men atomisiteten til operasjonene som utf\u00f8res p\u00e5 foreldretabellen og de relaterte indekstabellene m\u00e5 h\u00e5ndteres p\u00e5 applikasjonsniv\u00e5 og er ikke trivielt i en riktig implementering.<\/p>\n<p>Som nevnt i gjennomgangen av Cloud Spanner, kan dets indekser skille seg fra indekser i MySQL. Derfor m\u00e5 man v\u00e6re spesielt forsiktig n\u00e5r man bygger sp\u00f8rringer og profilerer for \u00e5 sikre riktig bruk av indeksen der den er n\u00f8dvendig.<\/p>\n<h4>Visninger?<\/h4>\n<p>\nEt veldig popul\u00e6rt og nyttig objekt i databasen er visninger. De kan v\u00e6re nyttige for mange bruksomr\u00e5der; mine to favoritter er logisk abstraksjon og sikkerhetsniv\u00e5. Dessverre st\u00f8tter Cloud Spanner IKKE visninger. Men dette begrenser oss bare delvis, da det ikke er detaljering p\u00e5 kolonneniv\u00e5 for tilgangstillatelser der visninger kan v\u00e6re en akseptabel l\u00f8sning.<\/p>\n<p>I dokumentasjonen for Cloud Spanner, i delen som detaljerer kvoter og begrensninger (<noindex><a rel=\"nofollow\" href=\"https:\/\/cloud.google.com\/spanner\/quotas\">spanner\/quotas<\/a><\/noindex>), er det spesielt \u00e9n som kan v\u00e6re problematisk for noen applikasjoner: Cloud Spanner har som standard en begrensning p\u00e5 maksimalt 100 databaser per instans. Dette kan tydeligvis utgj\u00f8re en alvorlig hindring for en database som er ment for skalering utover 100 databaser. Heldigvis, etter \u00e5 ha snakket med v\u00e5r tekniske representant hos Google, fant vi ut at denne grensen kan \u00f8kes n\u00e6rmest til hvilket som helst tall gjennom Googles kundest\u00f8tte.<\/p>\n<h4>St\u00f8tte for utvikling?<\/h4>\n<p>\nCloud Spanner tilbyr ganske god st\u00f8tte for programmeringsspr\u00e5k som jobber med API-et. Offisielt st\u00f8ttede biblioteker finnes for C#, Go, Java, node.js, PHP, Python og Ruby. Dokumentasjonen er relativt detaljert, men som med andre banebrytende teknologier er fellesskapet ganske lite sammenlignet med de mest popul\u00e6re databasteknologiene, noe som kan f\u00f8re til \u00f8kt tid brukt p\u00e5 \u00e5 l\u00f8se mindre vanlige bruksomr\u00e5der eller problemer.<\/p>\n<h4>S\u00e5 hva med st\u00f8tte for lokal utvikling?<\/h4>\n<p>\nVi fant ingen m\u00e5te \u00e5 opprette en Cloud Spanner-instans i et lokalt milj\u00f8. Det n\u00e6rmeste vi kom var et Docker-bilde, <noindex><a rel=\"nofollow\" href=\"https:\/\/hub.docker.com\/r\/cockroachdb\/cockroach\">CockroachDB<\/a><\/noindex>, som i prinsippet ligner, men i praksis er ganske forskjellig. For eksempel kan CockroachDB bruke PostgreSQL JDBC. Ettersom utviklingsmilj\u00f8et b\u00f8r v\u00e6re s\u00e5 n\u00e6rt som mulig det produktive milj\u00f8et, er Cloud Spanner ikke ideelt, da man m\u00e5 stole p\u00e5 en full instans av Spanner. For \u00e5 spare kostnader kan du velge en instans for \u00e9n region.<\/p>\n<h4>St\u00f8tte for administrasjon?<\/h4>\n<p>\n\u00c5 opprette en Cloud Spanner-instans er veldig enkelt. Du m\u00e5 bare velge mellom \u00e5 opprette en multiregional eller en instans for \u00e9n region, angi region(er) og antall noder. Mindre enn ett minutt senere vil instansen v\u00e6re oppe og klar til bruk.<\/p>\n<p>Flere grunnleggende m\u00e5linger er direkte tilgjengelige p\u00e5 Spanner-siden i Google Console. Mer detaljerte visninger er tilgjengelige via Stackdriver, hvor du ogs\u00e5 kan sette opp terskelverdier for m\u00e5linger og varsler.<\/p>\n<h4>Tilgang til ressurser?<\/h4>\n<p>\nMySQL tilbyr omfattende og sv\u00e6rt detaljerte innstillinger for tillatelser\/bruksroller for brukere. Det er enkelt \u00e5 konfigurere tilgang til en bestemt tabell eller til og med bare til en undergruppe av kolonnene. Cloud Spanner bruker Google Identity &amp; Access Management (IAM), som lar deg sette politikker og tillatelser p\u00e5 et sv\u00e6rt h\u00f8yt niv\u00e5. Det mest detaljerte alternativet er database-niv\u00e5 tillatelse, som ikke passer inn i de fleste produksjons-scenarier. Denne begrensningen tvinger deg til \u00e5 legge til ekstra sikkerhetstiltak i koden din, infrastrukturen din, eller begge deler for \u00e5 forhindre uautorisert tilgang til Spanner-ressursene.<\/p>\n<h4>Sikkerhetskopier?<\/h4>\n<p>\nKort sagt, sikkerhetskopier finnes ikke i Cloud Spanner. Selv om de h\u00f8ye kravene fra Googles SLA kan garantere at du ikke mister data p\u00e5 grunn av maskinvare- eller databasefeil, kan menneskelige feil, programvarefeil osv. skje. Vi vet alle regelen: h\u00f8y tilgjengelighet erstatter ikke en fornuftig sikkerhetskopistrategi. Per n\u00e5 er den eneste m\u00e5ten \u00e5 sikkerhetskopiere data p\u00e5, \u00e5 str\u00f8mme dem programmatisk fra databasen til et separat lagringsmilj\u00f8.<\/p>\n<h4>Sp\u00f8rringsytelse?<\/h4>\n<p>\nFor \u00e5 laste opp data og teste sp\u00f8rringer brukte vi Yahoo! Cloud Serving Benchmark. Tabellen nedenfor viser arbeidsbelastningen B YCSB med et lese-forhold p\u00e5 95 % og skriving p\u00e5 5 %.<\/p>\n<p><img decoding=\"async\" alt=\"Google Cloud Spanner: bra, vond, stygg\" src=\"\/wp-content\/uploads\/2020\/02\/8fca14875af33c8ed3cd04b602c52b78.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<i>* Belastningstesten ble utf\u00f8rt p\u00e5 databehandlingsmotoren (CE) n1-standard-32 (32 vCPU, 120 GB RAM), og testinstansen var aldri flaskehalsen i testene.<\/i><br \/>\n<i>** Maksimalt antall tr\u00e5der i \u00e9n YCSB-instans er 400. Det var n\u00f8dvendig \u00e5 kj\u00f8re seks parallelle YCSB-testinstanser for \u00e5 oppn\u00e5 totalt 2400 tr\u00e5der.<\/i><\/p>\n<p>N\u00e5r vi ser p\u00e5 testresultatene, spesielt kombinasjonen av prosessorbelastning og TPS, ser vi tydelig at Cloud Spanner skalerer ganske bra. Den h\u00f8ye belastningen fra mange tr\u00e5der kompenseres av det store antallet noder i Cloud Spanner-klyngen. Selv om forsinkelsen ser ganske h\u00f8y ut, spesielt med 2400 tr\u00e5der, kan det v\u00e6re n\u00f8dvendig med ny testing med 6 mindre instanser av databehandlingsmotoren for \u00e5 f\u00e5 mer n\u00f8yaktige tall. Hver instans vil kj\u00f8re en YCSB-test i stedet for en stor CE-instans med 6 parallelle tester. Dermed blir det lettere \u00e5 skille mellom forsinkelsene i Cloud Spanner-foresp\u00f8rslene og forsinkelsene lagt til av nettverksforbindelsen mellom Cloud Spanner og CE-instansen der testen kj\u00f8rer.<\/p>\n<h3>Hvordan presterer Cloud Spanner som OLAP?<\/h3>\n<p><\/p>\n<h4>Partisjonering?<\/h4>\n<p>\n\u00c5 dele opp data i fysiske og\/eller logisk uavhengige segmenter kalt partitioner er et veldig popul\u00e6rt konsept som finnes i de fleste OLAP-motorer. Partisjoner kan betydelig forbedre ytelsen til foresp\u00f8rslene og vedlikeholdbarheten av databasen. En videreg\u00e5ende unders\u00f8kelse av partisjoner ville f\u00f8rt til en egen artikkel(e), s\u00e5 la oss bare nevne viktigheten av \u00e5 ha en partisjonerings- og sub-partisjoneringsskjema. Muligheten til \u00e5 dele opp data i partisjoner og enda videre i sub-partisjoner er n\u00f8kkelen til ytelsen til analytiske foresp\u00f8rsel.<\/p>\n<p>Cloud Spanner st\u00f8tter ikke partisjoner som s\u00e5dan. Den deler data internt i s\u00e5kalte <i>split<\/i>-er basert p\u00e5 rekkevidden av prim\u00e6re n\u00f8kler. Delingen skjer automatisk for \u00e5 balansere lasten i Cloud Spanner-klyngen. En sv\u00e6rt nyttig funksjon ved Cloud Spanner er delingen av den grunnleggende lasten fra foreldertabellen (tabellen som ikke vekselvirker med en annen). Spanner bestemmer automatisk om den inneholder <i>split <\/i>data som leses oftere enn data i andre <i>split<\/i>-er, og kan ta beslutning om videre deling. Dermed kan flere noder bli involvert i foresp\u00f8rselen, noe som ogs\u00e5 effektivt \u00f8ker b\u00e5ndbredden.<\/p>\n<h4>Datainnhenting?<\/h4>\n<p>\nCloud Spanner-metoden for store datamengder er den samme som ved vanlig opplasting. For \u00e5 oppn\u00e5 maksimal ytelse m\u00e5 du f\u00f8lge noen anbefalinger, inkludert:<\/p>\n<ul>\n<li>Sorter dataene dine etter prim\u00e6rn\u00f8kkel.<\/li>\n<li>Del dem i 10*<i>antall noder<\/i> separate seksjoner.<\/li>\n<li>Opprett et sett med arbeidsoppgaver som laster data parallelt.<\/li>\n<\/ul>\n<p>\nN\u00e5r dataene lastes inn p\u00e5 denne m\u00e5ten, brukes alle nodene i Cloud Spanner.<\/p>\n<p>Vi brukte arbeidsbelastningen A YCSB for \u00e5 generere et datasett med 10 millioner rader.<\/p>\n<p><img decoding=\"async\" alt=\"Google Cloud Spanner: bra, vond, stygg\" src=\"\/wp-content\/uploads\/2020\/02\/89b9c0353716be2d389b3e8da82781ad.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<i>* Belastningstesten ble utf\u00f8rt p\u00e5 beregningsmotoren n1-standard-32 (32 vCPU, 120 GB minne), og testinstansen var aldri en flaskehals i testene.<br \/>\n** En- noders oppsett anbefales ikke for noen produksjonsbelastning.<\/i><\/p>\n<p>Som nevnt tidligere h\u00e5ndterer Cloud Spanner automatisk oppsplitting avhengig av belastningen, s\u00e5 resultatene forbedres etter flere p\u00e5f\u00f8lgende testgjentakelser. Resultatene som presenteres her, er de beste resultatene vi oppn\u00e5dde. Ser vi p\u00e5 tallene ovenfor, kan vi se hvordan Cloud Spanner (godt) skaleres med \u00f8kt antall noder i klyngen. Tallene som skiller seg ut, representerer ekstremt lave gjennomsnittlige forsinkelser som st\u00e5r i kontrast til resultatene fra blandede arbeidsbelastninger (95% for lesing og 5% for skriving), som beskrevet i avsnittet ovenfor.<\/p>\n<h4>Skalering?<\/h4>\n<p>\n\u00d8ke og redusere antall noder i Cloud Spanner er en oppgave som gj\u00f8res med ett klikk. Hvis du \u00f8nsker \u00e5 laste opp data raskt, kan du vurdere \u00e5 maksimere instansen (i v\u00e5rt tilfelle var dette 25 noder i regionen US-EAST), og deretter redusere antallet noder til et passende antall for din vanlige belastning etter at alle dataene er lagt inn i databasen, med tanke p\u00e5 grensen p\u00e5 2 TB\/nod.<\/p>\n<p>Vi ble minnet p\u00e5 denne grensen selv med en mye mindre database. Etter flere kj\u00f8ringer av belastningstestene hadde databasen v\u00e5r en st\u00f8rrelse p\u00e5 ca. 155 GB, og ved \u00e5 redusere til en en-nodes instans fikk vi f\u00f8lgende feil:<\/p>\n<p><img decoding=\"async\" alt=\"Google Cloud Spanner: bra, vond, stygg\" src=\"\/wp-content\/uploads\/2020\/02\/4a46c97e7943b5105bf178316dc67433.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nVi klarte \u00e5 redusere skalaen fra 25 til 2 instanser, men vi satt fast p\u00e5 to noder.<\/p>\n<p>Automatisering av \u00f8kning og reduksjon av antall noder i Cloud Spanner-klyngen kan oppn\u00e5s via REST API. Dette kan v\u00e6re spesielt nyttig for \u00e5 redusere \u00f8kt belastning p\u00e5 systemet i travle perioder.<\/p>\n<h4>Ytelsen til OLAP-sp\u00f8rsm\u00e5l?<\/h4>\n<p>\nVi planla opprinnelig \u00e5 bruke betydelig tid p\u00e5 v\u00e5r evaluering av Spanner for denne delen. Etter flere SELECT COUNT forsto vi umiddelbart at testing ville bli kortvarig, og at Spanner IKKE ville v\u00e6re egnet som OLAP-motor. Uansett antall noder i klyngen tok en enkel henting av antall rader i tabellen med 10M rader mellom 55 og 60 sekunder. Dessuten f\u00f8rte enhver foresp\u00f8rsel som krevde mer minne til \u00e5 lagre mellomliggende resultater til OOM-feil.<\/p>\n<p><code>SELECT COUNT(DISTINCT(field0)) FROM usertable; \u2014 (10M distinkt verdier)-&gt; SpoolingHashAggregateIterator gikk tom for minne under ny rad.<\/code><\/p>\n<p>Noen tall for TPC-H-sp\u00f8rsm\u00e5l kan finnes i artikkelen til Todd Lipkon <noindex><a rel=\"nofollow\" href=\"https:\/\/kudu.apache.org\/2017\/10\/23\/nosql-kudu-spanner-slides.html\">Nosql-kudu-spanner-slides.html<\/a><\/noindex>, lysbilder 42 og 43. Disse tallene stemmer overens med v\u00e5re egne resultater (dessverre).<\/p>\n<p><img decoding=\"async\" alt=\"Google Cloud Spanner: bra, vond, stygg\" src=\"\/wp-content\/uploads\/2020\/02\/d070c839bbc62b1ba1bebbaf64127e93.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h4>4. V\u00e5re funn<\/h4>\n<p>\nGitt den n\u00e5v\u00e6rende tilstanden til funksjonene i Cloud Spanner, er det vanskelig \u00e5 se for seg at det kan erstatte eksisterende OLTP-l\u00f8sninger, spesielt n\u00e5r behovene dine vokser utover det. Det ville kreve betydelig tid \u00e5 bygge en l\u00f8sning med hensyn til svakhetene i Cloud Spanner.<\/p>\n<p>Da vi begynte vurderingen av Cloud Spanner, forventet vi at administrasjonsfunksjonene ville v\u00e6re p\u00e5 niv\u00e5 eller i det minste ikke s\u00e5 langt unna andre Google SQL-l\u00f8sninger. Men vi var overrasket over det totale frav\u00e6ret av sikkerhetskopier og veldig begrenset tilgangskontroll til ressurser. For ikke \u00e5 nevne mangel p\u00e5 visninger, frav\u00e6r av lokal utviklingsmilj\u00f8, ikke-underbygde sekvenser, JDBC uten st\u00f8tte for DML og DDL og s\u00e5 videre.<\/p>\n<p>S\u00e5, hvor skal man henvende sig, hvis man skal skalere en transaktionsdatabase? Det ser ud til, at der p\u00e5 markedet ikke er en enkelt l\u00f8sning, der passer til alle brugsomr\u00e5der. Der findes mange l\u00f8sninger med b\u00e5de lukket og \u00e5bent kildekode (nogle af dem n\u00e6vnes i denne artikel), hver med sine styrker og svagheder, men ingen af dem tilbyder en SaaS med en SLA p\u00e5 99,999% og h\u00f8j grad af konsistens. Hvis en h\u00f8j SLA er dit prim\u00e6re m\u00e5l, og du ikke har lyst til at bygge din egen l\u00f8sning til flere cloud-milj\u00f8er, kan Cloud Spanner v\u00e6re den l\u00f8sning, du leder efter. Men du skal v\u00e6re opm\u00e6rksom p\u00e5 alle dens begr\u00e6nsninger.<\/p>\n<p>Retf\u00e6rdigvis skal det n\u00e6vnes, at Cloud Spanner f\u00f8rst blev frigivet til offentligheden i for\u00e5ret 2017, s\u00e5 det er rimeligt at forvente, at nogle af dens nuv\u00e6rende mangler m\u00e5ske i sidste ende forsvinder (forh\u00e5bentlig), og n\u00e5r det sker, kan det \u00e6ndre spillet. I sidste ende er Cloud Spanner ikke bare et projekt fra Google. Google bruger det som grundlag for andre produkter. Og da Google for nylig udskiftede Megastore i Google Cloud Storage med Cloud Spanner, gjorde det, at Google Cloud Storage blev strengt konsistent for objektlister p\u00e5 verdensplan (som stadig ikke g\u00e6lder for <noindex><a rel=\"nofollow\" href=\"https:\/\/cloudplatform.googleblog.com\/2018\/02\/how-Google-Cloud-Storage-offers-strongly-consistent-object-listing-thanks-to-Spanner.html\">Amazon\u2019s<\/a><\/noindex> <noindex><a rel=\"nofollow\" href=\"https:\/\/cloudplatform.googleblog.com\/2018\/02\/how-Google-Cloud-Storage-offers-strongly-consistent-object-listing-thanks-to-Spanner.html\">S3<\/a><\/noindex>).<\/p>\n<p>S\u00e5 der er stadig h\u00e5b\u2026 vi h\u00e5ber.<\/p>\n<p>Det var alt. Ligesom forfatteren af artiklen forts\u00e6tter vi ogs\u00e5 med at h\u00e5be, hvad mener du om dette? Skriv din mening i kommentarerne<\/p>\n<p><b>Vi inviterer alle interesserede til at deltage i vores <noindex><a rel=\"nofollow\" href=\"https:\/\/otus.pw\/eoP2\/\">gratis webinar<\/a><\/noindex> hvor vi grundigt vil tale om kurset<noindex><a rel=\"nofollow\" href=\"https:\/\/otus.pw\/eoP2\/\"> \u00abAWS for utviklere\u00bb<\/a><\/noindex> fra OTUS.<\/b><br \/>\n<br \/>Kilde: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/otus\/blog\/489012\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041f\u0440\u0438\u0432\u0435\u0442, \u0445\u0430\u0431\u0440\u043e\u0432\u0447\u0430\u043d\u0435. \u0422\u0440\u0430\u0434\u0438\u0446\u0438\u043e\u043d\u043d\u043e \u043f\u0440\u043e\u0434\u043e\u043b\u0436\u0430\u0435\u043c \u0434\u0435\u043b\u0438\u0442\u044c\u0441\u044f \u0438\u043d\u0442\u0435\u0440\u0435\u0441\u043d\u044b\u043c \u043c\u0430\u0442\u0435\u0440\u0438\u0430\u043b\u043e\u043c \u0432 \u043f\u0440\u0435\u0434\u0434\u0432\u0435\u0440\u0438\u0438 \u0441\u0442\u0430\u0440\u0442\u0430 \u043d\u043e\u0432\u044b\u0445 \u043a\u0443\u0440\u0441\u043e\u0432. \u0421\u0435\u0433\u043e\u0434\u043d\u044f \u0441\u043f\u0435\u0446\u0438\u0430\u043b\u044c\u043d\u043e \u0434\u043b\u044f \u0432\u0430\u0441 \u043c\u044b \u043f\u0440\u0435\u0432\u0435\u043b\u0438 \u0441\u0442\u0430\u0442\u044c\u044e \u043e Google Cloud Spanner, \u043f\u0440\u0438\u0443\u0440\u043e\u0447\u0438\u0432 \u0435\u0435 \u043a \u0437\u0430\u043f\u0443\u0441\u043a\u0443 \u043a\u0443\u0440\u0441\u0430 \u00abAWS \u0434\u043b\u044f \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u043e\u0432\u00bb. \u041f\u0435\u0440\u0432\u043e\u043d\u0430\u0447\u0430\u043b\u044c\u043d\u043e \u043e\u043f\u0443\u0431\u043b\u0438\u043a\u043e\u0432\u0430\u043d\u043e \u0432 \u0431\u043b\u043e\u0433\u0435 Lightspeed HQ. \u041a\u0430\u043a \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u044f, \u043a\u043e\u0442\u043e\u0440\u0430\u044f \u043f\u0440\u0435\u0434\u043b\u0430\u0433\u0430\u0435\u0442 \u043c\u043d\u043e\u0436\u0435\u0441\u0442\u0432\u043e \u043e\u0431\u043b\u0430\u0447\u043d\u044b\u0445 POS-\u0440\u0435\u0448\u0435\u043d\u0438\u0439 \u0434\u043b\u044f \u0440\u043e\u0437\u043d\u0438\u0447\u043d\u044b\u0445 \u0442\u043e\u0440\u0433\u043e\u0432\u0446\u0435\u0432, \u0440\u0435\u0441\u0442\u043e\u0440\u0430\u0442\u043e\u0440\u043e\u0432 \u0438 \u043e\u043d\u043b\u0430\u0439\u043d-\u043f\u0440\u043e\u0434\u0430\u0432\u0446\u043e\u0432 \u043f\u043e \u0432\u0441\u0435\u043c\u0443 \u043c\u0438\u0440\u0443, Lightspeed \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u0442 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":69569,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-69568","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.5 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041f\u0440\u0438\u0432\u0435\u0442, \u0445\u0430\u0431\u0440\u043e\u0432\u0447\u0430\u043d\u0435. \u0422\u0440\u0430\u0434\u0438\u0446\u0438\u043e\u043d\u043d\u043e \u043f\u0440\u043e\u0434\u043e\u043b\u0436\u0430\u0435\u043c \u0434\u0435\u043b\u0438\u0442\u044c\u0441\u044f \u0438\u043d\u0442\u0435\u0440\u0435\u0441\u043d\u044b\u043c \u043c\u0430\u0442\u0435\u0440\u0438\u0430\u043b\u043e\u043c \u0432 \u043f\u0440\u0435\u0434\u0434\u0432\u0435\u0440\u0438\u0438 \u0441\u0442\u0430\u0440\u0442\u0430 \u043d\u043e\u0432\u044b\u0445 \u043a\u0443\u0440\u0441\u043e\u0432.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/no\/blog\/administrirovanie\/google-cloud-spanner-horoshij-plohoj-zloj\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.5\" \/>\n\t\t<meta property=\"og:locale\" content=\"nn_NO\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47Google Cloud Spanner: \u0445\u043e\u0440\u043e\u0448\u0438\u0439, \u043f\u043b\u043e\u0445\u043e\u0439, \u0437\u043b\u043e\u0439 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041f\u0440\u0438\u0432\u0435\u0442, \u0445\u0430\u0431\u0440\u043e\u0432\u0447\u0430\u043d\u0435. \u0422\u0440\u0430\u0434\u0438\u0446\u0438\u043e\u043d\u043d\u043e \u043f\u0440\u043e\u0434\u043e\u043b\u0436\u0430\u0435\u043c \u0434\u0435\u043b\u0438\u0442\u044c\u0441\u044f \u0438\u043d\u0442\u0435\u0440\u0435\u0441\u043d\u044b\u043c \u043c\u0430\u0442\u0435\u0440\u0438\u0430\u043b\u043e\u043c \u0432 \u043f\u0440\u0435\u0434\u0434\u0432\u0435\u0440\u0438\u0438 \u0441\u0442\u0430\u0440\u0442\u0430 \u043d\u043e\u0432\u044b\u0445 \u043a\u0443\u0440\u0441\u043e\u0432.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/no\/blog\/administrirovanie\/google-cloud-spanner-horoshij-plohoj-zloj\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-02-20T12:24:23+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-03-03T13:14:50+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Google Cloud Spanner: god, d\u00e5rlig, grim | ProHoster","description":"Hej, Habr-deltagere. Som s\u00e6dvanligt forts\u00e6tter vi med at dele interessant materiale i forkant af starten p\u00e5 nye kurser.","canonical_url":"https:\/\/prohoster.info\/no\/blog\/administrirovanie\/google-cloud-spanner-horoshij-plohoj-zloj","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"nn_NO","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47Google Cloud Spanner: \u0445\u043e\u0440\u043e\u0448\u0438\u0439, \u043f\u043b\u043e\u0445\u043e\u0439, \u0437\u043b\u043e\u0439 | ProHoster","og:description":"\u041f\u0440\u0438\u0432\u0435\u0442, \u0445\u0430\u0431\u0440\u043e\u0432\u0447\u0430\u043d\u0435. \u0422\u0440\u0430\u0434\u0438\u0446\u0438\u043e\u043d\u043d\u043e \u043f\u0440\u043e\u0434\u043e\u043b\u0436\u0430\u0435\u043c \u0434\u0435\u043b\u0438\u0442\u044c\u0441\u044f \u0438\u043d\u0442\u0435\u0440\u0435\u0441\u043d\u044b\u043c \u043c\u0430\u0442\u0435\u0440\u0438\u0430\u043b\u043e\u043c \u0432 \u043f\u0440\u0435\u0434\u0434\u0432\u0435\u0440\u0438\u0438 \u0441\u0442\u0430\u0440\u0442\u0430 \u043d\u043e\u0432\u044b\u0445 \u043a\u0443\u0440\u0441\u043e\u0432.","og:url":"https:\/\/prohoster.info\/no\/blog\/administrirovanie\/google-cloud-spanner-horoshij-plohoj-zloj","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-02-20T12:24:23+00:00","article:modified_time":"2020-03-03T13:14:50+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"69568","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 19:20:25","updated":"2022-09-30 15:10:07","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/posts\/69568","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/comments?post=69568"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/posts\/69568\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/media\/69569"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/media?parent=69568"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/categories?post=69568"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/tags?post=69568"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}