{"id":96465,"date":"2020-10-12T07:42:27","date_gmt":"2020-10-12T05:42:27","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/eta-baza-dannyh-v-ogne"},"modified":"2020-10-12T07:42:27","modified_gmt":"2020-10-12T05:42:27","slug":"eta-baza-dannyh-v-ogne","status":"publish","type":"post","link":"https:\/\/prohoster.info\/no\/blog\/administrirovanie\/eta-baza-dannyh-v-ogne","title":{"rendered":"Denne databasen er i brann\u2026","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Denne
\n
\nLa meg fortelle en teknisk historie.<\/p>\n

For mange \u00e5r siden utviklet jeg en applikasjon med innebygde samarbeidsfunksjoner. Det var en praktisk eksperimentell stabel, hvor hele potensialet til tidlig React og CouchDB ble utnyttet. Den synkroniserte data i sanntid via JSON. OT<\/a><\/noindex>. Den ble brukt i selskapets interne arbeid, men den brede anvendeligheten og potensialet i andre omr\u00e5der var \u00e5penbare.<\/p>\n

Da vi fors\u00f8kte \u00e5 selge denne teknologien til potensielle kunder, st\u00f8tte vi p\u00e5 en uventet hindring. I demonstrasjonsvideoen s\u00e5 teknologien v\u00e5r flott ut og fungerte perfekt, uten problemer. Videoen viste n\u00f8yaktig hvordan den fungerer, og ingenting ble simulert. Vi kom opp med og kodet et realistisk bruks-scenario for programvaren.
\n<\/a><\/noindex>
\n\"Denne
\nDet var faktisk dette som ble problemet. Demoen v\u00e5r fungerte akkurat slik som alle andre som simulerte funksjonaliteten til applikasjonene sine. Spesielt ble informasjonen umiddelbart overf\u00f8rt fra A til B, selv n\u00e5r det gjaldt store mediefiler. Etter innlogging s\u00e5 hver bruker nye oppf\u00f8ringer. Med applikasjonen kunne forskjellige brukere samarbeide presist om de samme prosjektene, selv n\u00e5r internettforbindelsen var ustabil et sted p\u00e5 landet. Det var implisitt underforst\u00e5tt i enhver videopresentasjon om produktet laget i After Effects.<\/p>\n

Selv om alle visste hva Refresh-knappen var til for, forsto ingen at nettapplikasjonene de ba oss om \u00e5 lage ofte hadde sine egne begrensninger. Og at hvis de ikke lenger var n\u00f8dvendige, ville brukeropplevelsen v\u00e6re helt annerledes. Hovedsakelig la de merke til at de kunne \"prate\" og legge igjen merknader til hverandre, s\u00e5 de begynte \u00e5 sp\u00f8rre hva som skiller dette fra for eksempel Slack. Uff!<\/p>\n

Design av daglig synchronisering<\/h2>\n

\nHvis du allerede har erfaring med programvareutvikling, m\u00e5 det irritere deg \u00e5 huske at de fleste mennesker ikke kan se p\u00e5 et bilde av grensesnittet og forst\u00e5 hva det vil gj\u00f8re ved interaksjon. For ikke \u00e5 snakke om hva som skjer innside selve programmet. \u00c5 vite at finne ut at brukeren har deaktivert animasjons-effektene og dermed ogs\u00e5 deaktivere ulike animasjonsmuligheter p\u00e5 nettsiden, for eksempel fjerne skjelvingseffekten p\u00e5 knapper som brukes for \u00e5 tiltrekke seg oppmerksomhet;<\/i> \u00e5 skje \u2014 er i stor grad et resultat av kunnskap om hva som ikke kan skje og hva som ikke b\u00f8r skje. Dette krever en mental modell<\/a><\/noindex> ikke bare av hva programvaren gj\u00f8r, men ogs\u00e5 av hvordan de enkelte delene er koordinert og kommuniserer med hverandre.<\/p>\n

Et klassisk eksempel p\u00e5 dette er en bruker som i l\u00f8pet av tjue minutter stirrer p\u00e5 spinner.gif<\/i>, og undrer seg over n\u00e5r arbeidet endelig vil bli fullf\u00f8rt. Utvikleren ville ha forst\u00e5tt at prosessen sannsynligvis har hengt seg opp, og at gif-en aldri vil forsvinne fra skjermen. Denne animasjonen imiterer arbeidsutf\u00f8relsen, men har ingen forbindelse med tilstanden til den. I slike tilfeller liker noen teknikere \u00e5 rulle med \u00f8ynene, fascinert av graden av misforst\u00e5else blant brukerne. Men legg merke til, hvem av dem peker p\u00e5 de roterende klokkene og sier at de faktisk st\u00e5r stille?<\/p>\n

\"Denne
\nDette er essensen av verdien av sanntid. I dag blir databaser for sanntid fortsatt brukt sv\u00e6rt lite, og mange ser p\u00e5 dem med mistillit. De fleste av disse databasene tenderer mot NoSQL-stil, noe som gj\u00f8r at man vanligvis bruker l\u00f8sninger basert p\u00e5 Mongo, som det er best \u00e5 glemme. Men for meg betyr dette komfort i arbeidet med CouchDB, samt \u00e5 l\u00e6re seg \u00e5 designe strukturer som ikke bare en eller annen byr\u00e5krat vil klare \u00e5 fylle med data. Jeg tror jeg bruker tiden min mer effektivt.<\/p>\n

Men den virkelige temaen for dette innlegget er det jeg bruker i dag. Ikke av min egen valg, men p\u00e5 grunn av en likegyldig og blindt anvendt bedrifts-politikk. Derfor vil jeg gi en Helt \u00c6rlig og Upartisk sammenligning av to n\u00e6rt beslektede produkter for arbeid med sanntids-databaser fra Google.<\/p>\n

\"Denne
\nI begge navn finnes ordet Fire. Det ene husker jeg med \u00f8mhet. Det andre for meg er en annen type ild. Jeg haster ikke med \u00e5 si navnene deres, fordi s\u00e5 snart jeg gj\u00f8r det, vil vi m\u00f8te det f\u00f8rste store problemet \u2014 navnene.<\/p>\n

Det f\u00f8rste kalles Firebase Real-Time Database<\/i>, og det andre \u2014 Firebase Cloud Firestore<\/i>. Begge er produkter fra Firebase suite<\/i> Google. Deres API-er kalles, henholdsvis, firebase.database(\u2026)<\/code> og firebase.firestore(\u2026)<\/code>.<\/p>\n

Det skjedde fordi Real-Time Database<\/i> \u2014 det er bare den opprinnelige Firebase<\/i> f\u00f8r det ble kj\u00f8pt av Google i 2014. Deretter bestemte Google seg for \u00e5 lage en kopi som et parallelt produkt<\/i> Firebase basert p\u00e5 big data fra selskapet, og de kalte det Firestore med skybasert lagring. Jeg h\u00e5per du ikke er blitt forvirret enn\u00e5. Hvis du er det, ikke bekymre deg, jeg skrev denne delen av artikkelen ti ganger.<\/p>\n

Fordi det er n\u00f8dvendig \u00e5 spesifisere Firebase<\/i> i sp\u00f8rsm\u00e5let om Firebase, og Firestore<\/i> i sp\u00f8rsm\u00e5let om Firebase, i det minste for at folk skulle forst\u00e5 deg for noen \u00e5r siden p\u00e5 Stack Overflow.<\/p>\n

Hvis det fantes en pris for d\u00e5rligst navngiving av programvareprodukter, ville dette definitivt v\u00e6rt en seri\u00f8s kandidat. Hamming-avstanden mellom disse navnene er s\u00e5 liten at det forvirrer selv erfarne ingeni\u00f8rer, som skriver ett navn selv om tankene deres tenker p\u00e5 et annet. Dette er mislykkede planer, oppfunnet med de beste intensjoner; de oppfyller profetien om at databasen skulle brenne. Jeg tuller ikke. Personen som fant p\u00e5 et slikt navngivningssystem, har for\u00e5rsaket blod, svette og t\u00e5rer.<\/p>\n

\"Denne<\/p>\n

Pyrrhussseier<\/h2>\n

\nMan skulle tro at Firestore er en erstatning<\/i> for Firebase, dens etterf\u00f8lger av neste generasjon, men det ville v\u00e6rt en misforst\u00e5else. Firestore kan absolutt ikke betraktes som en erstatning for Firebase. Det ser ut til at noen har kuttet ut alt det interessante fra det, og forvirret det meste av det som er igjen p\u00e5 forskjellige m\u00e5ter.<\/p>\n

Men et raskt blikk p\u00e5 de to produktene kan forvirre deg: det ser ut til at de gj\u00f8r det samme, gjennom stort sett de samme API-ene og til og med i den samme datasettet. Forskjellene er subtile og oppdages kun ved n\u00f8ye sammenligning av den omfattende dokumentasjonen. Eller n\u00e5r du pr\u00f8ver \u00e5 portere perfekt fungerende kode fra Firebase for \u00e5 f\u00e5 det til \u00e5 fungere med Firestore. Allerede da oppdager du at databasegrensesnittet lyser opp s\u00e5 snart du pr\u00f8ver \u00e5 gj\u00f8re drag-and-drop i sanntid med musa. Jeg gjentar, jeg tuller ikke.<\/p>\n

Firebase-klienten er vennlig i den forstand at den bufferer endringer og utf\u00f8rer automatiske gjentakelsesfors\u00f8k p\u00e5 oppdateringer, der den gir prioritet til den sist utf\u00f8rte skriveoperasjonen. Imidlertid har Firestore en begrensning p\u00e5 1 skriveoperasjon per dokument per bruker per sekund, og denne begrensningen h\u00e5ndheves av serveren. N\u00e5r du jobber med det, m\u00e5 du selv finne en m\u00e5te \u00e5 omg\u00e5 dette p\u00e5 og implementere en hastighetsbegrensning for oppdateringer, selv n\u00e5r du bare pr\u00f8ver \u00e5 lage applikasjonen din. Med andre ord er Firestore en sanntidsdatabase uten en sanntidsklient, som forkles som en selv med API.<\/p>\n

Her begynner vi \u00e5 se de f\u00f8rste tegnene p\u00e5 meningen med Firestore. Kanskje tar jeg feil, men jeg mistenker at noen h\u00f8yt oppe i ledelsen hos Google etter oppkj\u00f8pet s\u00e5 p\u00e5 Firebase og bare sa: \u00abNei, Gud nei. Dette er uakseptabelt. Ikke under min ledelse.\u00bb<\/p>\n

\"Denne
\nHan kom ut fra sine kammer og proklamerte:<\/p>\n

\u00ab\u00c9n stor JSON-dokument? Nei. Du m\u00e5 dele opp dataene i separate dokumenter, hver med en st\u00f8rrelse p\u00e5 ikke mer enn 1 megabyte.\u00bb<\/i><\/p>\n

Det virker som en slik begrensning ikke vil overleve f\u00f8rste m\u00f8te med en hvilken som helst tilstrekkelig motivert brukerbase. Du vet at det er sant. Hos oss p\u00e5 jobben, for eksempel, har vi over 1500 presentasjoner, og det er helt normalt.<\/p>\n

Med en slik begrensning m\u00e5 du akseptere at ett \u00abdokument\u00bb i databasen ikke vil ligne noe objekt som brukeren m\u00e5tte kalle et dokument.<\/p>\n

\u00abArrays av arrays, som kan inneholde andre elementer rekursivt? Nei. Arrays vil bare inneholde objekter eller tall med fast lengde, som opprinnelig ment av Skaperen.\u00bb<\/i><\/p>\n

S\u00e5 hvis du h\u00e5pet \u00e5 plassere GeoJSON i din Firestore, vil du oppdage at det er umulig. Det er ikke tillatt \u00e5 ha noe ikke-en-dimensjonalt. Jeg h\u00e5per du liker Base64 og\/eller JSON inne i JSON.<\/p>\n

\u00abImport og eksport av JSON via HTTP, kommandolinjeverkt\u00f8y eller administrasjonspanel? Nei. Du kan bare eksportere og importere data i Google Cloud Storage. S\u00e5nn ser det ut for \u00f8yeblikket. Og n\u00e5r jeg sier 'du', mener jeg bare de som har myndighet som Project Owner. Alle andre kan g\u00e5 og opprette billetter.\u00bb<\/i><\/p>\n

Som du kan se, er Firebase-datamodellen lett \u00e5 beskrive. Den inneholder ett stort JSON-dokument som kobler JSON-n\u00f8kler med URL-stier. Hvis du skriver inn ved hjelp av HTTP PUT<\/code> i \/<\/code> Firebase f\u00f8lgende:<\/p>\n

{\n  \"hello\": \"verden\"\n}<\/code><\/pre>\n
\nDa GET \/hello<\/code> vil returnere \"verden\"<\/code>. Generelt fungerer dette akkurat som du forventer. Firebase-samlingen av objekter \/my-collection\/:id<\/code> er ekvivalent med et JSON-ordbok {\"my-collection\": {...}}<\/code> i roten, innholdet som er tilgjengelig i \/my-collection<\/code>:<\/p>\n
{\n  \"id1\": {...object},\n  \"id2\": {...object},\n  \"id3\": {...object},\n  \/\/ ...\n}<\/code><\/pre>\n
\nDette fungerer utmerket hvis hver innsats har ID-er uten kollisjoner, noe systemet har en standardl\u00f8sning for.<\/p>\n
Med andre ord er databasen 100 % kompatibel med JSON (*) og fungerer utmerket med HTTP, for eksempel med CouchDB. Men hovedsakelig bruker du den gjennom et sanntids-API som abstraherer websockets, autorisering og abonnementer. Administrasjonspanelet har begge muligheter, som lar deg redigere i sanntid og importere\/eksportere JSON. Hvis du holder deg til det samme i koden din, vil du bli overrasket over hvor mye spesialisert kode som forsvinner n\u00e5r du forst\u00e5r at patch og diff JSON l\u00f8ser 90 % av de rutinemessige oppgavene knyttet til h\u00e5ndtering av permanent tilstand.<\/p>\n
Firestore-datamodellen ligner p\u00e5 JSON, men avviker fra den i noen kritiske aspekter. Jeg har allerede nevnt frav\u00e6ret av arrays inne i arrays. Sub-collections-modellen er slik at de er f\u00f8rstklassige konsepter, adskilt fra det inneholdende JSON-dokumentet. Siden det ikke finnes noen klar serialisering for dette, kreves det en spesialisert kodekj\u00f8ring for \u00e5 hente og skrive data. For \u00e5 h\u00e5ndtere egne samlinger m\u00e5 det skrives egne skripter og verkt\u00f8y. Administrasjonspanelet lar deg bare gj\u00f8re sm\u00e5 endringer ett felt om gangen, og har ingen import-\/eksportfunksjoner.<\/p>\n
De tok en sanntids NoSQL-database og gjorde den til en sakte ikke-SQL med automatisk sammensl\u00e5ing og en separat kolonne for ikke-JSON. Noe i stil med GraftQL<\/i>.<\/p>\n
\"Denne<\/p>\n
Hot Java<\/h2>\n
\nHvis Firestore skulle bli mer p\u00e5litelig og skalerbart, er ironien at den gjennomsnittlige utvikleren f\u00e5r en mindre p\u00e5litelig l\u00f8sning enn ved \u00e5 velge FireBase \"rett ut av boksen\". Programvaren som den Pirkete Databasesjefen trenger, krever et slikt niv\u00e5 av innsats og kaliber av spesialister, at det rett og slett ikke er realistisk for nisjen der det antas at et godt produkt skal v\u00e6re. Det er litt som at HTML5 Canvas absolutt ikke er en erstatning for Flash, hvis det ikke finnes utviklingsverkt\u00f8y og avspillere. Dessuten er Firestore d\u00f8mt til \u00e5 streve for datarenslighet og steril validering, noe som rett og slett ikke samsvarer med hvordan den gjennomsnittlige bedriftsbrukeren liker \u00e5 arbeide<\/i>: fordi for ham er alt valgfritt, ettersom alt er et utkast helt til slutten.<\/p>\n
Den st\u00f8rste begrensningen med FireBase er at klienten ble laget flere \u00e5r f\u00f8r sin tid, lenge f\u00f8r de fleste webutviklere visste om immutabilitet. P\u00e5 grunn av dette antar FireBase at du vil endre data, og dermed utnytter ikke fordelene ved brukerskapt immutabilitet. I tillegg bruker den ikke dataene p\u00e5 nytt i sendte snapshots til brukeren, noe som gj\u00f8r diff-utf\u00f8relse mye vanskeligere. For store dokumenter er dens transaksjonsmekanisme basert p\u00e5 endrede diffs helt utilstrekkelig. Folkens, vi har allerede WeakMap<\/code> det i JavaScript. Det er praktisk.<\/p>\n
Hvis man former dataene p\u00e5 riktig m\u00e5te og ikke lager tr\u00e6rne for omfattende, kan man omg\u00e5 dette problemet. Men jeg er nysgjerrig p\u00e5 om FireBase ville blitt mye mer interessant dersom utviklerne hadde gitt ut et virkelig godt klient-API som bruker immutabilitet i kombinasjon med seri\u00f8se praktiske r\u00e5d om databasens struktur. I stedet ser det ut til at de har pr\u00f8vd \u00e5 fikse noe som ikke er \u00f8delagt, og det har blitt verre.<\/p>\n
Jeg kjenner ikke all logikk som l\u00e5 til grunn for opprettelsen av Firestore. Resonnementene rundt motivene som oppst\u00e5r inne i en svart boks - det er ogs\u00e5 en del av underholdningen. En slik sammenligning av to ekstremt like, men uimotst\u00e5elige databaser oppst\u00e5r ganske sjelden. Som om noen tenkte: \"Firebase er bare en funksjon som vi kan emulere i Google Cloud\"<\/i>, men har enn\u00e5 ikke oppdaget konseptet med \u00e5 definere krav fra den virkelige verden eller \u00e5 lage nyttige l\u00f8sninger som oppfyller alle disse kravene. \u00abLa utviklerne tenke p\u00e5 det. Bare gj\u00f8r UI-en vakker... Kan vi legge til mer fyr?\u00bb<\/i><\/p>\n
Jeg forst\u00e5r et par ting om datakonstruksjoner. Jeg ser helt klart at konseptet med \u00abalt i ett stort JSON-tre\u00bb er et fors\u00f8k p\u00e5 \u00e5 abstrahere enhver f\u00f8lelse av stor-skala-struktur fra databasen. \u00c5 forvente at programvaren bare skal h\u00e5ndtere hvilken som helst tvilsom fraktal av datakonstruksjoner er bare galskap. Jeg trenger ikke engang \u00e5 forestille meg hvor ille det kan v\u00e6re; jeg har gjennomf\u00f8rt strenge kodeauditter og sett ting som dere mennesker ikke engang kan dr\u00f8mme om.<\/i>. Men jeg vet ogs\u00e5 hvordan gode strukturer ser ut, hvordan man bruker dem,<\/a><\/noindex> og hvorfor det er n\u00f8dvendig \u00e5 gj\u00f8re det.<\/a><\/noindex>Jeg kan forestille meg en verden der Firestore ville virke helt logisk, og menneskene som laget den ville trodd at de hadde gjort en god jobb. Men vi lever ikke i denne verden.<\/p>\n
St\u00f8tten for \u00e5 bygge foresp\u00f8rselen i FireBase er d\u00e5rlig etter enhver standard; den eksisterer s\u00e5 og si ikke. Den trenger absolutt forbedring, eller i det minste en revisjon. Men Firestore er ikke mye bedre, siden den er begrenset av de samme en-dimensjonale indeksene som finnes i enkel SQL. Hvis du trenger foresp\u00f8rslene som folk gj\u00f8r med kaotiske data, s\u00e5 kreves det fullteksts\u00f8k, filtre p\u00e5 flere omr\u00e5der og vilk\u00e5rlig rekkef\u00f8lge direkte av brukeren. N\u00e5r man ser n\u00f8ye p\u00e5 den enkle SQL-funksjonen, er den i seg selv for begrenset. I tillegg er de eneste SQL-foresp\u00f8rslene som folk kan utf\u00f8re i produksjon, raske foresp\u00f8rslene. Du vil trenge en spesialdesignet l\u00f8sning for indeksering med gjennomtenkte datakonstruksjoner. For alt annet, b\u00f8r det i det minste v\u00e6re inkrementell map-reduce eller noe lignende.<\/p>\n
Hvis du leter etter informasjon om dette i Googles dokumenter, h\u00e5per jeg du blir peket i retning av noe som BigTable og BigQuery. Men alle disse l\u00f8sningene er akkompagnert av en mengde tett salgsspr\u00e5k, slik at du raskt vil g\u00e5 tilbake og begynne \u00e5 lete etter noe annet.<\/p>\n
Det siste du trenger i tilfelle en sanntidsdatabase, er noe skapt av mennesker og for mennesker som jobber p\u00e5 en l\u00f8nnsskala for ledere.<\/p>\n
(*) Dette er en sp\u00f8k, det finnes ikke et begrep som kompatibilitet med JSON p\u00e5 100%<\/a><\/noindex>.<\/i><\/p>\n
<\/p>\n
Advertising<\/h4>\n
\nSer du etter \u2014  virtuell dedikert server.<\/a><\/noindex> en server for debugging av prosjekter og hosting? Da er du virkelig v\u00e5r kunde \ud83d\ude42 Daglig betaling for servere i forskjellige konfigurasjoner, antiDDoS og Windows-lisenser er allerede inkludert i prisen.<\/p>\n
\"Denne<\/a><\/noindex>
\n
Kilde: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
\u041f\u043e\u0437\u0432\u043e\u043b\u044c\u0442\u0435 \u043c\u043d\u0435 \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u0442\u044c \u0442\u0435\u0445\u043d\u0438\u0447\u0435\u0441\u043a\u0443\u044e \u0438\u0441\u0442\u043e\u0440\u0438\u044e. \u041c\u043d\u043e\u0433\u043e \u043b\u0435\u0442 \u043d\u0430\u0437\u0430\u0434 \u044f \u0440\u0430\u0437\u0440\u0430\u0431\u0430\u0442\u044b\u0432\u0430\u043b \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0435 \u0441\u043e \u0432\u0441\u0442\u0440\u043e\u0435\u043d\u043d\u044b\u043c\u0438 \u0432 \u043d\u0435\u0433\u043e \u0444\u0443\u043d\u043a\u0446\u0438\u044f\u043c\u0438 \u0441\u043e\u0432\u043c\u0435\u0441\u0442\u043d\u043e\u0439 \u0440\u0430\u0431\u043e\u0442\u044b. \u042d\u0442\u043e \u0431\u044b\u043b \u0443\u0434\u043e\u0431\u043d\u044b\u0439 \u044d\u043a\u0441\u043f\u0435\u0440\u0438\u043c\u0435\u043d\u0442\u0430\u043b\u044c\u043d\u044b\u0439 \u0441\u0442\u0435\u043a, \u0432 \u043a\u043e\u0442\u043e\u0440\u043e\u043c \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043b\u0441\u044f \u043f\u043e\u043b\u043d\u044b\u0439 \u043f\u043e\u0442\u0435\u043d\u0446\u0438\u0430\u043b \u0440\u0430\u043d\u043d\u0435\u0433\u043e React \u0438 CouchDB. \u041e\u043d \u0432 \u0440\u0435\u0430\u043b\u044c\u043d\u043e\u043c \u0432\u0440\u0435\u043c\u0435\u043d\u0438 \u0441\u0438\u043d\u0445\u0440\u043e\u043d\u0438\u0437\u0438\u0440\u043e\u0432\u0430\u043b \u0434\u0430\u043d\u043d\u044b\u0435 \u043f\u043e JSON OT. \u0415\u0433\u043e \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043b\u0438 \u0432\u043e \u0432\u043d\u0443\u0442\u0440\u0435\u043d\u043d\u0435\u0439 \u0440\u0430\u0431\u043e\u0442\u0435 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438, \u043e\u0434\u043d\u0430\u043a\u043e \u0448\u0438\u0440\u043e\u043a\u0430\u044f \u043f\u0440\u0438\u043c\u0435\u043d\u0438\u043c\u043e\u0441\u0442\u044c \u0438 \u043f\u043e\u0442\u0435\u043d\u0446\u0438\u0430\u043b \u0432 \u0434\u0440\u0443\u0433\u0438\u0445 \u0441\u0444\u0435\u0440\u0430\u0445 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":96466,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-96465","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Denne databasen st\u00e5r i brand\u2026 | ProHoster","description":"La meg fortelle en teknisk historie. Mange \u00e5r.","canonical_url":"https:\/\/prohoster.info\/no\/blog\/administrirovanie\/eta-baza-dannyh-v-ogne","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\udd47\u042d\u0442\u0430 \u0431\u0430\u0437\u0430 \u0434\u0430\u043d\u043d\u044b\u0445 \u0432 \u043e\u0433\u043d\u0435\u2026 | ProHoster","og:description":"\u041f\u043e\u0437\u0432\u043e\u043b\u044c\u0442\u0435 \u043c\u043d\u0435 \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u0442\u044c \u0442\u0435\u0445\u043d\u0438\u0447\u0435\u0441\u043a\u0443\u044e \u0438\u0441\u0442\u043e\u0440\u0438\u044e. \u041c\u043d\u043e\u0433\u043e \u043b\u0435\u0442.","og:url":"https:\/\/prohoster.info\/no\/blog\/administrirovanie\/eta-baza-dannyh-v-ogne","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-10-12T05:42:27+00:00","article:modified_time":"2020-10-12T05:42:27+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"96465","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 10:42:30","updated":"2022-09-29 13:02:04","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\/96465","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=96465"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/posts\/96465\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/media\/96466"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/media?parent=96465"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/categories?post=96465"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/tags?post=96465"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}