{"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\/da\/blog\/administrirovanie\/google-cloud-spanner-horoshij-plohoj-zloj","title":{"rendered":"Google Cloud Spanner: god, d\u00e5rlig, ond","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><b><i>Hej, Habrovtjane. Traditionelt forts\u00e6tter vi med at dele interessant materiale i takt med starten p\u00e5 nye kurser. I dag har vi for jer oversat en artikel om Google Cloud Spanner, i forbindelse med lanceringen af kurset. <noindex><a rel=\"nofollow\" href=\"https:\/\/otus.pw\/eoP2\/\">\u00abAWS for udviklere\u00bb<\/a><\/noindex>.<\/i><\/b><\/p>\n<p><img decoding=\"async\" alt=\"Google Cloud Spanner: god, d\u00e5rlig, ond\" src=\"\/wp-content\/uploads\/2020\/02\/b27b8a09543d10b078480c317553ca46.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<i>Oprindeligt offentliggjort i <noindex><a rel=\"nofollow\" href=\"https:\/\/www.lightspeedhq.com\/blog\/\">bloggen Lightspeed HQ<\/a><\/noindex>.<\/i><\/p>\n<p>Som en virksomhed, der tilbyder en r\u00e6kke cloud-baserede POS-l\u00f8sninger til detailhandlere, restaurantfolk og online-s\u00e6lgere verden over, bruger Lightspeed flere forskellige typer databaseplatforme til mange transaktionelle, analytiske og s\u00f8gekoncepter. Hver af disse databaseplatforme har sine egne styrker og svagheder. Derfor, da Google introducerede Cloud Spanner p\u00e5 markedet - med lovende funktioner, der ikke er set i verden af relationelle databaser, s\u00e5som praktisk talt ubegribelig horisontal skalerbarhed og en SLA p\u00e5 99,999% - kunne vi ikke lade denne mulighed g\u00e5 os forbi!<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\nFor at give en omfattende oversigt over vores erfaring med Cloud Spanner samt de evalueringskriterier, vi har brugt, vil vi se p\u00e5 f\u00f8lgende emner:<\/p>\n<ol>\n<li>Vores evalueringskriterier<\/li>\n<li>Cloud Spanner i korte tr\u00e6k<\/li>\n<li>Vurdering<\/li>\n<li>Vores konklusioner<\/li>\n<\/ol>\n<p>\n<img decoding=\"async\" alt=\"Google Cloud Spanner: god, d\u00e5rlig, ond\" src=\"\/wp-content\/uploads\/2020\/02\/29ed599362fb189283faa9215c18297a.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>1. Vores evalueringskriterier<\/h2>\n<p>\nF\u00f8r vi dykker ned i funktionerne i Cloud Spanner, dens ligheder og forskelle med andre l\u00f8sninger p\u00e5 markedet, lad os f\u00f8rst tale om de vigtigste use cases, vi havde i tankerne, da vi overvejede, hvor vi skulle implementere Cloud Spanner i vores infrastruktur:<\/p>\n<ul>\n<li>Som en erstatning for (det dominerende) traditionelle SQL-database l\u00f8sning<\/li>\n<li>Som OLTP-l\u00f8sning med OLAP-support<\/li>\n<\/ul>\n<p><\/p>\n<blockquote><p><i><b>Bem\u00e6rk:<\/b> For enkelhedens skyld sammenligner denne artikel Cloud Spanner med MySQL-varianter af GCP Cloud SQL og Amazon AWS RDS.<\/i><\/p><\/blockquote>\n<p><\/p>\n<h4>Brugen af Cloud Spanner som erstatning for traditionelle SQL-database l\u00f8sninger<\/h4>\n<p>\nI et milj\u00f8 <i>af traditionelle <\/i>databaser, n\u00e5r svartiden for databaseanmodninger n\u00e6rmer sig eller endda overstiger forh\u00e5ndsdefinerede t\u00e6rskelv\u00e6rdier for applikationen (for det meste p\u00e5 grund af stigende antal brugere og\/eller anmodninger), er der flere metoder til at reducere svartiden til acceptable niveauer. Dog kr\u00e6ver de fleste af disse l\u00f8sninger manuel indgriben.<\/p>\n<p>For eksempel er det f\u00f8rste skridt, man skal tage, at se p\u00e5 forskellige databaserelaterede parametre, der vedr\u00f8rer ydeevne, og justere dem, s\u00e5 de bedst muligt passer til brugsm\u00f8nstrene for applikationer. Hvis dette ikke er tilstr\u00e6kkeligt, kan man v\u00e6lge at skalere databasen vertikalt eller horisontalt.<\/p>\n<p>Vertikal skalering af en applikation indeb\u00e6rer at opgradere serverinstansen, vanligvis ved at tilf\u00f8je flere processorer\/kerner, mere RAM, hurtigere lager osv. Tilf\u00f8jelse af flere hardware-ressourcer f\u00f8rer til en forbedring af databasens ydeevne, m\u00e5lt i hovedsageligt transaktioner pr. sekund og transaktioners forsinkelse for OLTP-systemer. Relationelle databasesystemer (som bruger en multitr\u00e5det tilgang), s\u00e5som MySQL, skalerer godt vertikalt.<\/p>\n<p>Denne tilgang har nogle ulemper, men den mest \u00e5benlyse er den maksimale st\u00f8rrelse af servere p\u00e5 markedet. N\u00e5r man n\u00e5r gr\u00e6nsen for den st\u00f8rste serverinstans, er der kun \u00e9n vej tilbage: horisontal skalering.<\/p>\n<p>Horisontal skalering er en tilgang, hvor der tilf\u00f8jes flere servere til klyngen for ideelt set at \u00f8ge ydeevnen line\u00e6rt med antallet af tilf\u00f8jede servere. De fleste <i>af traditionelle <\/i>databasesystemer skalerer d\u00e5rligt horisontalt eller slet ikke. For eksempel kan MySQL skaleres horisontalt til l\u00e6seoperationer ved at tilf\u00f8je slave-l\u00e6sere, men kan ikke skaleres horisontalt til skriveoperationer.<\/p>\n<p>Derimod, p\u00e5 grund af sin natur kan Cloud Spanner let skaleres horisontalt med minimal indblanding.<\/p>\n<p>Fuldfunktions-<i> DBMS som en service<\/i> skal vurderes fra flere vinkler. Som grundlag har vi taget den mest popul\u00e6re DBMS i skyen \u2014 for Google, GCP Cloud SQL, og for Amazon, AWS RDS. I vores vurdering har vi fokuseret p\u00e5 f\u00f8lgende kategorier:<\/p>\n<ul>\n<li>Sammenligning af funktioner: SQL, DDL, DML; forbindelsesbiblioteker\/connectorer, support for transaktioner osv.<\/li>\n<li>Udviklingssupport: lethed ved udvikling og test.<\/li>\n<li>Administration Support: management of instances \u2013 for example, scaling up\/down and upgrading instances; SLA, backup and restoration; security\/access control.<\/li>\n<\/ul>\n<p><\/p>\n<h4>Using Cloud Spanner as an OLTP solution with OLAP support<\/h4>\n<p>\nAlthough Google does not explicitly state that Cloud Spanner is intended for analytical processing, it shares some attributes with other mechanisms, such as Apache Impala &amp; Kudu and YugaByte, which are designed for OLAP workloads.<\/p>\n<p>Even if there were only a slight chance that Cloud Spanner included a horizontally scalable HTAP (Hybrid Transactional\/Analytical Processing) engine with a (more or less) usable set of OLAP features, we believe it would deserve our attention.<\/p>\n<p>With this in mind, we looked at the following categories:<\/p>\n<ul>\n<li>Data loading, indexes, and partitioning support<\/li>\n<li>Query performance and DML<\/li>\n<\/ul>\n<p><\/p>\n<h2>2. Cloud Spanner in Brief<\/h2>\n<p>\nGoogle Spanner is a clustered relational database management system (RDBMS) that Google uses for several of its own services. Google made it publicly available for users of Google Cloud Platform in early 2017.<\/p>\n<p>Here are some of the attributes of Cloud Spanner:<\/p>\n<ul>\n<li>Strongly consistent scalable cluster RDBMS: uses hardware time synchronization to ensure data consistency.<\/li>\n<li>Support for cross-table transactions: transactions can span multiple tables \u2013 not necessarily limited to a single table (unlike Apache HBase or Apache Kudu).<\/li>\n<li>Primary key-based tables: all tables must have a declared primary key (PK), which can consist of multiple columns of the table. Tabular data is stored in PK order, making it very efficient and fast for searching by PK. Like other primary key-based systems, the implementation must be modeled with careful consideration of well-thought-out use cases to achieve <noindex><a rel=\"nofollow\" href=\"https:\/\/cloud.google.com\/spanner\/docs\/schema-and-data-model\">optimal performance.<\/a><\/noindex>.<\/li>\n<li>Skiftende tabeller: tabeller kan have fysiske afh\u00e6ngigheder af hinanden. R\u00e6kkerne i den underordnede tabel kan matches med r\u00e6kkerne i den overordnede tabel. Denne tilgang fremskynder s\u00f8gningen efter relationer, der kan defineres p\u00e5 datamodelleringsstadiet, for eksempel ved at sammenl\u00e6gge kunder og deres fakturaer.<\/li>\n<li>Indekser: Cloud Spanner underst\u00f8tter sekund\u00e6re indekser. Et indeks best\u00e5r af de indekserede kolonner og alle kolonner af prim\u00e6rn\u00f8gle. Hvis \u00f8nskes, kan indekset ogs\u00e5 inkludere andre ikke-indekserede kolonner. Indekset kan defineres sammen med den overordnede tabel for at fremskynde foresp\u00f8rgsler. Der g\u00e6lder flere begr\u00e6nsninger for indekser, s\u00e5som det maksimale antal ekstra kolonner, der kan gemmes i indekset. Ogs\u00e5 foresp\u00f8rgsler gennem indekser kan v\u00e6re mindre ligetil end i andre RDBMS.<\/li>\n<\/ul>\n<p>\n<i>Cloud Spanner v\u00e6lger kun indekset automatisk i sj\u00e6ldne tilf\u00e6lde. Is\u00e6r v\u00e6lger Cloud Spanner ikke automatisk et sekund\u00e6rt indeks, hvis foresp\u00f8rgslen anmoder om nogen kolonner, der ikke er gemt i <noindex><a rel=\"nofollow\" href=\"https:\/\/cloud.google.com\/spanner\/docs\/secondary-indexes\">indekset <\/a><\/noindex>\u00bb.<\/i><\/p>\n<ul>\n<li>Service Level Agreement (SLA): implementering i \u00e9n region med SLA p\u00e5 99,99%; multiregionale implementeringer med SLA p\u00e5 99,999%. Selvom selve service level agreement blot er en aftale og ikke en garanti, mener jeg, at Google-medarbejdere faktisk har nogle pr\u00e6cise data til at lave s\u00e5danne alvorlige udsagn. (Til reference betyder 99,999% 26,3 sekunder utilg\u00e6ngelighed af tjenesten om m\u00e5neden.)<\/li>\n<li>Mere: <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>Bem\u00e6rk:<\/b> Apache Tephra-projektet tilf\u00f8jer udvidet support til transaktioner i Apache HBase (som nu ogs\u00e5 implementeres i Apache Phoenix i beta-version).<\/i><\/p><\/blockquote>\n<p><\/p>\n<h2>3. Vores vurdering<\/h2>\n<p>\nS\u00e5 vi har alle l\u00e6st Googles p\u00e5stande om fordelene ved Cloud Spanner \u2013 stort set ubegribelig horisontal skalering samtidig med h\u00f8j konsistens og meget h\u00f8j SLA. Selvom disse krav i alle tilf\u00e6lde er ekstremt sv\u00e6re at opn\u00e5, var vores m\u00e5l ikke at modbevise dem. I stedet lad os fokusere p\u00e5 andre aspekter, der bekymrer de fleste databasebrugere: enkelhed og brugervenlighed.<\/p>\n<h4>Vi har vurderet Cloud Spanner som en erstatning for Sharded MySQL<\/h4>\n<p>\nGoogle Cloud SQL og Amazon AWS RDS, de to mest popul\u00e6re OLTP-databaser p\u00e5 cloud-markedet, har et meget stort funktionss\u00e6t. For at skalere disse databaser ud over st\u00f8rrelsen af en enkelt node, skal du imidlertid opdeles applikationer. Denne tilgang skaber yderligere kompleksitet b\u00e5de for applikationer og administration. Vi har set p\u00e5, hvordan Spanner passer ind i scenariet for at kombinere flere segmenter til \u00e9n instans, og hvilke funktioner (hvis de findes), man m\u00e5ske m\u00e5 give afkald p\u00e5.<\/p>\n<h4>Underst\u00f8ttelse af SQL, DML og DDL samt en connector og biblioteker?<\/h4>\n<p>\nFor det f\u00f8rste, n\u00e5r man arbejder med en hvilken som helst database, er det n\u00f8dvendigt at oprette en datamodel. Hvis du tror, at du kan koble JDBC Spanner til dit foretrukne SQL-v\u00e6rkt\u00f8j, vil du opdage, at du kan foresp\u00f8rge dine data med det, men ikke kan bruge det til at oprette tabeller eller \u00e6ndringer (DDL) eller nogen inds\u00e6ttelses-\/opdaterings-\/sletningsoperationer (DML). Googles officielle JDBC underst\u00f8tter hverken det ene eller det andet.<\/p>\n<blockquote><p><i>\u00abI \u00f8jeblikket underst\u00f8tter driverne ikke DML- eller DDL-kommandoer\u00bb.<\/i><br \/>\nSpanner-dokumentation<\/p><\/blockquote>\n<p>\nMed GCP-konsollen er situationen ikke bedre \u2013 du kan kun sende SELECT-foresp\u00f8rgsler. Heldigvis findes der en JDBC-driver med st\u00f8tte til DML og DDL fra f\u00e6llesskabet, herunder transaktioner. <noindex><a rel=\"nofollow\" href=\"http:\/\/github.com\/olavloite\/spanner-jdbc\">github.com\/olavloite\/spanner-jdbc<\/a><\/noindex>. Selvom denne driver er ekstremt nyttig, v\u00e6kker manglen p\u00e5 en egen JDBC-driver fra Google undren. Heldigvis tilbyder Google en ret omfattende underst\u00f8ttelse af klientbiblioteker (baseret p\u00e5 gRPC): C#, Go, Java, node.js, PHP, Python og Ruby.<\/p>\n<p>Det n\u00e6sten obligatoriske brug af brugerdefinerede API'er for Cloud Spanner (p\u00e5 grund af manglen p\u00e5 DDL og DML i JDBC) medf\u00f8rer nogle begr\u00e6nsninger for relaterede kodeomr\u00e5der, s\u00e5som forbindelsespuljer eller databinding frameworks (f.eks. Spring MVC). Generelt kan du med JDBC frit v\u00e6lge den foretrukne forbindelsespulje (f.eks. HikariCP, DBCP, C3PO m.fl.), som er testet og fungerer godt. I tilf\u00e6lde af brugerdefinerede Spanner-API'er m\u00e5 vi stole p\u00e5 de frameworks\/puljer\/SESSIONER, som vi selv har oprettet.<\/p>\n<p>Den prim\u00e6re n\u00f8gle-fokuserede konstruktion (PK) g\u00f8r det muligt for Cloud Spanner at v\u00e6re utroligt hurtig til at tilg\u00e5 data via PK, men det medf\u00f8rer ogs\u00e5 nogle udfordringer for foresp\u00f8rgsler.<\/p>\n<ul>\n<li>Du kan ikke opdatere v\u00e6rdien af prim\u00e6rn\u00f8glen; du skal f\u00f8rst slette posten med den originale PK og inds\u00e6tte den igen med den nye v\u00e6rdi. (Dette ligner andre PK-orienterede databaser\/lager mekanismer.)<\/li>\n<li>Alle UPDATE- og DELETE-udtryk skal angive PK i WHERE, derfor kan der ikke v\u00e6re tomme DELETE all-udtryk \u2014 der skal altid v\u00e6re en underforesp\u00f8rgsel, for eksempel: UPDATE xxx WHERE id IN (SELECT id FROM table1)<\/li>\n<li>Mangel p\u00e5 auto-increment mulighed eller noget der ligner, der angiver sekvensen for PK-feltet. For at dette kan fungere, skal det tilsvarende v\u00e6rdi oprettes p\u00e5 applikationssiden.<\/li>\n<\/ul>\n<p><\/p>\n<h4>Sekund\u00e6re indekser?<\/h4>\n<p>\nGoogle Cloud Spanner har indbygget support til sekund\u00e6re indekser. Dette er en meget god funktion, som ikke altid er til stede i andre teknologier. Apache Kudu underst\u00f8tter pt. ikke sekund\u00e6re indekser overhovedet, og Apache HBase underst\u00f8tter indekser ikke direkte, men kan tilf\u00f8je dem gennem Apache Phoenix.<\/p>\n<p>Indekser i Kudu og HBase kan modelleres som en separat tabel med en anden sammens\u00e6tning af prim\u00e6re n\u00f8gler, men atomariteten for operationerne udf\u00f8rt med for\u00e6ldretabellen og de tilknyttede indeks-tabeller skal sikres p\u00e5 applikationsniveau og er ikke trivielt i en korrekt implementering.<\/p>\n<p>Som n\u00e6vnt i oversigten over Cloud Spanner, kan dens indekser adskille sig fra MySQL-indekser. Derfor skal man v\u00e6re s\u00e6rlig forsigtig ved opbygningen af foresp\u00f8rgsler og profilering for at sikre, at den rigtige indeks anvendes, hvor det er n\u00f8dvendigt.<\/p>\n<h4>Visninger?<\/h4>\n<p>\nEn meget popul\u00e6r og nyttig objekt i databasen er visninger. De kan v\u00e6re nyttige til mange forskellige brugsscenarier; mine to favoritter er logisk abstraheringsniveau og sikkerhedsniveau. Desv\u00e6rre underst\u00f8tter Cloud Spanner IKKE visninger. Men det begr\u00e6nser os kun delvist, da der ikke er detaljeret adgang til kolonneniveau, hvor visninger kan v\u00e6re en acceptabel l\u00f8sning.<\/p>\n<p>I dokumentationen for Cloud Spanner er der et afsnit, der beskriver kvoter og begr\u00e6nsninger (<noindex><a rel=\"nofollow\" href=\"https:\/\/cloud.google.com\/spanner\/quotas\">spanner\/quotas<\/a><\/noindex>), er der is\u00e6r en, der kan v\u00e6re problematisk for nogle applikationer: Cloud Spanner har en standardbegr\u00e6nsning p\u00e5 maksimum 100 databaser pr. instans. Det er tydeligt, at dette kan blive en alvorlig hindring for en database, der er designet til at skalere til mere end 100 databaser. Heldigvis, efter at have talt med vores tekniske repr\u00e6sentant fra Google, fandt vi ud af, at denne gr\u00e6nse kan \u00f8ges til n\u00e6sten enhver v\u00e6rdi via Google Support.<\/p>\n<h4>Underst\u00f8tter udvikling?<\/h4>\n<p>\nCloud Spanner tilbyder ganske anst\u00e6ndig support til programmeringssprog, der arbejder med dens API. Officielt underst\u00f8ttede biblioteker inkluderer C#, Go, Java, node.js, PHP, Python og Ruby. Dokumentationen er ret detaljeret, men ligesom med andre avancerede teknologier er samfundet ret lille sammenlignet med de mest popul\u00e6re database teknologier, hvilket kan f\u00f8re til l\u00e6ngere tid brugt p\u00e5 at l\u00f8se mindre almindelige anvendelsestilf\u00e6lde eller problemer.<\/p>\n<h4>Hvad med support til lokal udvikling?<\/h4>\n<p>\nVi fandt ikke en m\u00e5de at oprette en Cloud Spanner instans i et lokalt milj\u00f8. Det t\u00e6tteste, vi kom, var et Docker-billede. <noindex><a rel=\"nofollow\" href=\"https:\/\/hub.docker.com\/r\/cockroachdb\/cockroach\">CockroachDB<\/a><\/noindex>, som i princippet ligner, men i praksis adskiller sig meget. For eksempel kan CockroachDB bruge PostgreSQL JDBC. Da udviklingsmilj\u00f8et skal v\u00e6re s\u00e5 t\u00e6t som muligt p\u00e5 produktionsmilj\u00f8et, er Cloud Spanner ikke ideelt, da man skal stole p\u00e5 en fuld Spanner instans. For at spare omkostninger kan du v\u00e6lge en instans i \u00e9t region.<\/p>\n<h4>Underst\u00f8ttelse af administration?<\/h4>\n<p>\nDet er meget enkelt at oprette en Cloud Spanner instans. Du skal blot v\u00e6lge mellem at oprette en multiregion eller en instans i \u00e9n region, angive region(er) og antal noder. P\u00e5 mindre end et minut vil instansen v\u00e6re startet og klar til brug.<\/p>\n<p>Flere grundl\u00e6ggende metrikker er direkte tilg\u00e6ngelige p\u00e5 Spanner-siden i Google Console. Mere detaljerede visninger er tilg\u00e6ngelige via Stackdriver, hvor du ogs\u00e5 kan indstille t\u00e6rskelv\u00e6rdier for metrikker og alarmpolitikker.<\/p>\n<h4>Adgang til ressourcer?<\/h4>\n<p>\nMySQL tilbyder omfattende og meget detaljerede indstillinger for brugerrettigheder\/roller. Det er nemt at konfigurere adgang til en bestemt tabel eller endda blot et delm\u00e6ngde af dens kolonner. Cloud Spanner bruger Google Identity &amp; Access Management (IAM) v\u00e6rkt\u00f8jet, som g\u00f8r det muligt at fasts\u00e6tte politikker og tilladelser kun p\u00e5 et meget h\u00f8jt niveau. Den mest detaljerede mulighed er database-niveau tilladelse, som ikke passer ind i de fleste produktionsscenarier. Denne begr\u00e6nsning tvinger dig til at tilf\u00f8je ekstra sikkerhedsforanstaltninger i din kode, infrastruktur eller begge dele for at forhindre uautoriseret brug af Spanner-ressourcer.<\/p>\n<h4>Backups?<\/h4>\n<p>\nFor at sige det simpelt, findes der ingen backups i Cloud Spanner. Selvom Googles h\u00f8je SLA-krav kan garantere, at du ikke mister data p\u00e5 grund af hardware- eller databasefejl, g\u00e6lder det ikke ved menneskelige fejl, applikationsfejl osv. Vi kender alle reglen: h\u00f8j tilg\u00e6ngelighed er ikke en erstatning for en fornuftig backup-strategi. Lige nu er den eneste m\u00e5de at lave backups p\u00e5 at streame dataene fra databasen til et separat lagringsmilj\u00f8.<\/p>\n<h4>Foresp\u00f8rgselsydelse?<\/h4>\n<p>\nTil dataloading og test af foresp\u00f8rgsler anvendte vi Yahoo! Cloud Serving Benchmark. Tabellen nedenfor viser B YCSB arbejdsbyrden med et l\u00e6seforhold p\u00e5 95% og et skriveforhold p\u00e5 5%.<\/p>\n<p><img decoding=\"async\" alt=\"Google Cloud Spanner: god, d\u00e5rlig, ond\" src=\"\/wp-content\/uploads\/2020\/02\/8fca14875af33c8ed3cd04b602c52b78.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<i>* Belastningstesten blev udf\u00f8rt p\u00e5 Compute Engine (CE) n1-standard-32 (32 vCPU, 120 GB RAM), og testinstansen var aldrig flaskehalsen i testene.<\/i><br \/>\n<i>** Det maksimale antal tr\u00e5de i en enkelt YCSB-instans er 400. Det var n\u00f8dvendigt at k\u00f8re seks parallelle instanser af YCSB-testene for at opn\u00e5 i alt 2400 tr\u00e5de.<\/i><\/p>\n<p>N\u00e5r vi ser p\u00e5 testresultaterne, is\u00e6r kombinationen af CPU-belastning og TPS, kan vi tydeligt se, at Cloud Spanner skalerer ret godt. Den store belastning, der skabes af mange tr\u00e5de, kompenseres af det store antal noder i Cloud Spanner-klassen. Selvom forsinkelsen ser ret h\u00f8j ud, is\u00e6r n\u00e5r der arbejdes med 2400 tr\u00e5de, kan gentagne tests med 6 mindre instanser af beregningsmotoren v\u00e6re n\u00f8dvendige for at f\u00e5 mere pr\u00e6cise tal. Hver instans vil k\u00f8re \u00e9n YCSB-test i stedet for \u00e9n stor CE-instans med 6 parallelle tests. Dette vil g\u00f8re det lettere at skelne mellem Cloud Spanner-foresp\u00f8rgselers forsinkelse og forsinkelsen tilf\u00f8jet af netv\u00e6rksforbindelsen mellem Cloud Spanner og CE-instansen, hvor testen k\u00f8rer.<\/p>\n<h3>Hvordan performer Cloud Spanner som OLAP?<\/h3>\n<p><\/p>\n<h4>Partitionering?<\/h4>\n<p>\nOpdelingen af data i fysisk og\/eller logisk uafh\u00e6ngige segmenter, kaldet partitioner, er et meget popul\u00e6rt koncept, der er karakteristisk for de fleste OLAP-mekanismer. Partitioner kan betydeligt forbedre foresp\u00f8rgselsydelsen og vedligeholdelsen af databasen. En dybereg\u00e5ende analyse af partitioner ville kr\u00e6ve en separat artikel, s\u00e5 lad os blot n\u00e6vne vigtigheden af at have en partitionerings- og sub-partitioneringsskema. Muligheden for at opdele data i partitioner og endda videre til sub-partitioner er n\u00f8glen til ydeevnen af analytiske foresp\u00f8rgsler.<\/p>\n<p>Cloud Spanner underst\u00f8tter ikke partitioner som s\u00e5dan. Den opdeler data internt i s\u00e5kaldte <i>split<\/i>-ter baseret p\u00e5 intervallet af den prim\u00e6re n\u00f8gle. Opdelingen sker automatisk for at balancere belastningen i Cloud Spanner-klassen. En meget praktisk funktion ved Cloud Spanner er opdelingen af den grundl\u00e6ggende belastning fra for\u00e6ldretabellen (den tabel, der ikke overlapper med en anden). Spanner bestemmer automatisk, om <i>split <\/i>dataene l\u00e6ses oftere end dataene i andre <i>split<\/i>-ter, og kan tr\u00e6ffe beslutning om yderligere opdeling. P\u00e5 denne m\u00e5de kan flere noder involveres i foresp\u00f8rgslen, hvilket ogs\u00e5 effektivt \u00f8ger b\u00e5ndbredden.<\/p>\n<h4>Indl\u00e6sning af data?<\/h4>\n<p>\nCloud Spanner-metoden til store data er den samme som ved almindelig indl\u00e6sning. For at opn\u00e5 den bedste ydeevne skal du f\u00f8lge nogle anbefalinger, herunder:<\/p>\n<ul>\n<li>Sorter dine data efter prim\u00e6rn\u00f8glen.<\/li>\n<li>Del dem op i 10*<i>antal noder<\/i> separate sektioner.<\/li>\n<li>Opret et s\u00e6t arbejdsopgaver, der indl\u00e6ser data parallelt.<\/li>\n<\/ul>\n<p>\nVed s\u00e5dan datal\u00e6sning bruges alle noder i Cloud Spanner.<\/p>\n<p>Vi brugte arbejdsbelastningen A YCSB til at generere et datas\u00e6t p\u00e5 10M r\u00e6kker.<\/p>\n<p><img decoding=\"async\" alt=\"Google Cloud Spanner: god, d\u00e5rlig, ond\" src=\"\/wp-content\/uploads\/2020\/02\/89b9c0353716be2d389b3e8da82781ad.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<i>* Belastningstesten blev udf\u00f8rt p\u00e5 compute engine n1-standard-32 (32 vCPU, 120 GB hukommelse), og testinstansen var aldrig et flaskehals i testene.<br \/>\n** Konfiguration med 1 node anbefales ikke til nogen produktionsbelastning.<\/i><\/p>\n<p>Som n\u00e6vnt tidligere h\u00e5ndterer Cloud Spanner automatisk delinger afh\u00e6ngigt af deres belastning, s\u00e5 resultaterne forbedres efter flere p\u00e5 hinanden f\u00f8lgende test. Resultaterne pr\u00e6senteret her er de bedste resultater, vi fik. Ved at se p\u00e5 tallene ovenfor kan vi se, hvordan Cloud Spanner (godt) skalerer med et stigende antal noder i klyngen. Tallene, der fremh\u00e6ves, repr\u00e6senterer ekstremt lave gennemsnitlige latenser, som st\u00e5r i kontrast til resultaterne fra blandede arbejdsbelastninger (95% til l\u00e6sning og 5% til skrivning), som beskrevet i afsnittet ovenfor.<\/p>\n<h4>Skalering?<\/h4>\n<p>\nAt \u00f8ge og mindske antallet af Cloud Spanner-noder er en opgave, der udf\u00f8res med \u00e9t klik. Hvis du hurtigt vil indl\u00e6se data, kan du overveje at booste instansen til maksimum (i vores tilf\u00e6lde var det 25 noder i regionen US-EAST), og derefter mindske antallet af noder til det, der passer til din s\u00e6dvanlige belastning, efter at alle data er i databasen, og med det i mente gr\u00e6nsen p\u00e5 2 TB\/node.<\/p>\n<p>Vi blev mindet om denne gr\u00e6nse selv med en meget mindre database. Efter flere k\u00f8rsel af belastningstest havde vores database en st\u00f8rrelse p\u00e5 omkring 155 GB, og ved at nedskalere til en instans med 1 node fik vi f\u00f8lgende fejl:<\/p>\n<p><img decoding=\"async\" alt=\"Google Cloud Spanner: god, d\u00e5rlig, ond\" src=\"\/wp-content\/uploads\/2020\/02\/4a46c97e7943b5105bf178316dc67433.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nVi kunne mindske skalaen fra 25 til 2 instanser, men vi sad fast p\u00e5 to noder.<\/p>\n<p>Automatisering af op- og nedskalering af antallet af noder i Cloud Spanner-klyngen kan udf\u00f8res ved hj\u00e6lp af REST API. Dette kan v\u00e6re s\u00e6rligt nyttigt til at mindske den \u00f8gede belastning p\u00e5 systemet i travle perioder.<\/p>\n<h4>Ydelse af OLAP foresp\u00f8rgsler?<\/h4>\n<p>\nOprindeligt havde vi planlagt at bruge betydelig tid p\u00e5 vores evaluering af Spanner i denne del. Efter flere SELECT COUNT inds\u00e5 vi hurtigt, at testningen ville v\u00e6re kortvarig, og at Spanner IKKE ville v\u00e6re en passende OLAP-motor. Uanset antallet af noder i klyngen tog en simpel foresp\u00f8rgsel om antallet af r\u00e6kker i en tabel med 10M r\u00e6kker mellem 55 og 60 sekunder. Derudover resulterede enhver foresp\u00f8rgsel, der kr\u00e6vede mere hukommelse til at gemme mellemliggende resultater, i en OOM-fejl.<\/p>\n<p><code>SELECT COUNT(DISTINCT(field0)) FROM usertable; \u2014 (10M distinkte v\u00e6rdier)-&gt; SpoolingHashAggregateIterator l\u00f8b t\u00f8r for hukommelse under ny r\u00e6kke.<\/code><\/p>\n<p>Nogle tal for TPC-H foresp\u00f8rgsler kan findes i artiklen af Todd Lipkone <noindex><a rel=\"nofollow\" href=\"https:\/\/kudu.apache.org\/2017\/10\/23\/nosql-kudu-spanner-slides.html\">Nosql-kudu-spanner-slides.html<\/a><\/noindex>, slides 42 og 43. Disse tal stemmer overens med vores egne resultater (desv\u00e6rre).<\/p>\n<p><img decoding=\"async\" alt=\"Google Cloud Spanner: god, d\u00e5rlig, ond\" src=\"\/wp-content\/uploads\/2020\/02\/d070c839bbc62b1ba1bebbaf64127e93.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h4>4. Vores konklusioner<\/h4>\n<p>\nI betragtning af den nuv\u00e6rende tilstand af funktionerne i Cloud Spanner er det sv\u00e6rt at forestille sig, at det vil kunne erstatte eksisterende OLTP-l\u00f8sninger, is\u00e6r n\u00e5r dine behov overstiger det. Det ville kr\u00e6ve betydelig tid at opbygge en l\u00f8sning, der tager h\u00f8jde for manglerne i Cloud Spanner.<\/p>\n<p>Da vi begyndte at evaluere Cloud Spanner, forventede vi, at dets administrationsfunktioner ville v\u00e6re p\u00e5 niveau eller i det mindste ikke s\u00e5 langt fra andre Google SQL-l\u00f8sninger. Men vi blev overrasket over den fuldst\u00e6ndige mangel p\u00e5 sikkerhedskopier og den meget begr\u00e6nsede kontrol over ressourcerne. Ikke at tale om frav\u00e6ret af visninger, manglen p\u00e5 en lokal udviklingsmilj\u00f8, ikke-underst\u00f8ttede sekvenser, JDBC uden st\u00f8tte for DML og DDL og s\u00e5 videre.<\/p>\n<p>S\u00e5, hvor skal man g\u00e5 hen, n\u00e5r man skal skalere en transaktionsdatabase? Det ser ud til, at der endnu ikke findes \u00e9n enkelt l\u00f8sning p\u00e5 markedet, der passer til alle anvendelsesscenarier. Der er mange l\u00f8sninger med b\u00e5de lukket og \u00e5bent kildekode (nogle af dem n\u00e6vnes i denne artikel), hver med sine egne styrker og svagheder, men ingen af dem tilbyder SaaS med SLA p\u00e5 99,999% og h\u00f8j konsistens. Hvis et h\u00f8jt niveau af 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 det, du leder efter. Men du skal v\u00e6re klar over alle dets begr\u00e6nsninger.<\/p>\n<p>For retf\u00e6rdighedens skyld b\u00f8r det n\u00e6vnes, at Cloud Spanner f\u00f8rst blev offentlig tilg\u00e6ngelig i for\u00e5ret 2017, s\u00e5 det er rimeligt at forvente, at nogle af de nuv\u00e6rende mangler i sidste ende kan forsvinde (forh\u00e5bentlig), og n\u00e5r det sker, kan det \u00e6ndre spillet. I sidste ende er Cloud Spanner ikke bare et tredjepartsprojekt for Google. Google bruger det som grundlag for andre Google-produkter. Og da Google for nylig erstattede Megastore i Google Cloud Storage med Cloud Spanner, gjorde det Google Cloud Storage strengt konsistent for objektlister globalt (hvilket 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<\/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... vi h\u00e5ber.<\/p>\n<p>Det var alt. Ligesom artikelens forfatter forts\u00e6tter vi ogs\u00e5 med at h\u00e5be, hvad mener du om det? Skriv dine tanker i kommentarerne.<\/p>\n<p><b>Alle interesserede er inviteret til at bes\u00f8ge vores <noindex><a rel=\"nofollow\" href=\"https:\/\/otus.pw\/eoP2\/\">et gratis webinar<\/a><\/noindex> hvor vi vil fort\u00e6lle om kurset i detaljer<noindex><a rel=\"nofollow\" href=\"https:\/\/otus.pw\/eoP2\/\"> \u00abAWS for udviklere\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.3 - 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\/da\/blog\/administrirovanie\/google-cloud-spanner-horoshij-plohoj-zloj\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"da_DK\" \/>\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\/da\/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: den gode, den d\u00e5rlige, den grusomme | ProHoster","description":"Hej, habrovchany. Traditionelt forts\u00e6tter vi med at dele interessant materiale i forkant af starten af de nye kurser.","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/google-cloud-spanner-horoshij-plohoj-zloj","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","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\/da\/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\/da\/wp-json\/wp\/v2\/posts\/69568","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=69568"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/69568\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media\/69569"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=69568"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=69568"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=69568"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}