{"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\/da\/blog\/administrirovanie\/eta-baza-dannyh-v-ogne","title":{"rendered":"Denne database er i brand\u2026","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Denne
\n
\nLad mig fort\u00e6lle en teknisk historie.<\/p>\n

For mange \u00e5r siden udviklede jeg en applikation med indbyggede samarbejdsfunktioner. Det var et praktisk eksperimentelt stack, der udnyttede det fulde potentiale af tidlig React og CouchDB. Den synkroniserede data i realtid via JSON. OT<\/a><\/noindex>. Den blev brugt i virksomhedens interne arbejde, men den brede anvendelighed og potentiale i andre omr\u00e5der var \u00e5benlyse.<\/p>\n

Da vi fors\u00f8gte at s\u00e6lge denne teknologi til potentielle kunder, st\u00f8dte vi p\u00e5 en uventet forhindring. I demo-videoen s\u00e5 vores teknologi fremragende ud og fungerede perfekt, der var ingen problemer. Videoen viste pr\u00e6cist, hvordan det fungerer, og der blev ikke imiteret noget. Vi designede og kodede et realistisk anvendelsesscenario for programmet.
\n<\/a><\/noindex>
\n\"Denne
\nFaktisk blev det et problem. Vores demo fungerede pr\u00e6cist som de andre applikationer imiterede. Konkret blev informationer \u00f8jeblikkeligt overf\u00f8rt fra A til B, selvom det var store mediefiler. Efter login s\u00e5 hver bruger nye indl\u00e6g. Ved hj\u00e6lp af applikationen kunne forskellige brugere arbejde pr\u00e6cist sammen om de samme projekter, selv i tilf\u00e6lde af en ustabil internetforbindelse et eller andet sted i landsbyen. Dette var implicit i enhver klippet After Effects video om produktet.<\/p>\n

Selvom alle vidste, hvad knappen Opdatering skulle bruges til, forstod ingen overhovedet, at de webapplikationer, de bad os om at skabe, oftest var begr\u00e6nsede. Og at hvis de ikke l\u00e6ngere var n\u00f8dvendige, ville brugeroplevelsen v\u00e6re helt anderledes. I det store hele bem\u00e6rkede de, at de kunne 'chattere' ved at efterlade noter til hinanden, s\u00e5 de sp\u00f8rgte sig selv, hvad der adskilte det fra for eksempel Slack. Uff!<\/p>\n

Design af daglig synkronisering<\/h2>\n

\nHvis du allerede har erfaring med softwareudvikling, s\u00e5 m\u00e5 det irritere dig, at du skal huske, at de fleste mennesker ikke kan kaste et blik p\u00e5 en gr\u00e6nseflade og forst\u00e5, hvad den vil g\u00f8re, n\u00e5r de interagerer med den. Slet ikke at n\u00e6vne hvad der sker inde i selve programmet. Viden om, hvad kan<\/i> der kan ske \u2014 er i h\u00f8j grad et resultat af viden om, hvad der ikke kan ske, og hvad der ikke b\u00f8r ske. Det kr\u00e6ver mentalt model<\/a><\/noindex> ikke kun hvad softwaren g\u00f8r, men ogs\u00e5 hvordan dens dele er koordineret og kommunikere med hinanden.<\/p>\n

Et klassisk eksempel p\u00e5 dette er en bruger, der i tyve minutter ser p\u00e5 spinner.gif<\/i>, og g\u00e6tter p\u00e5, hvorn\u00e5r arbejdet endelig slutter. Udvikleren ville forst\u00e5, at processen sandsynligvis er l\u00e5st, og at gif'en aldrig vil forsvinde fra sk\u00e6rmen. Denne animation imiterer udf\u00f8relsen af arbejdet, men har ikke noget at g\u00f8re med dets tilstand. I s\u00e5danne tilf\u00e6lde elsker nogle teknikere at rulle med \u00f8jnene over, hvor fuldst\u00e6ndig brugerne tager fejl. Men bem\u00e6rk, hvem af dem peger p\u00e5 de roterende ure og siger, at de faktisk er immobile?<\/p>\n

\"Denne
\nDette er essensen af v\u00e6rdien af realtid. I dag anvendes realtidsdatabaser stadig meget sj\u00e6ldent, og mange har en mist\u00e6nksom holdning til dem. De fleste af disse databaser er st\u00e6rkt tilb\u00f8jelige til NoSQL-stilen, hvilket normalt f\u00f8rer til brug af l\u00f8sninger baseret p\u00e5 Mongo, som det er bedst at glemme. Men for mig betyder det komforten ved at arbejde med CouchDB samt studerende i design af strukturer, der ikke kun kan fyldes af en eller anden bureaukrat. Jeg mener, at jeg bruger min tid mere optimalt.<\/p>\n

Men det egentlige emne for dette indl\u00e6g er, hvad jeg bruger i dag. Ikke efter eget valg, men p\u00e5 grund af den ligegyldige og blindt anvendte virksomhedspolitik. Derfor vil jeg give en Helt \u00c6rlig og Upartisk sammenligning af to t\u00e6t relaterede produkter til at arbejde med realtidsdatabaser fra Google.<\/p>\n

\"Denne
\nBegge har ordet Fire i deres navne. Det ene husker jeg med \u00f8mhed. Det andet er for mig en anden form for ild. Jeg skyndte mig ikke med at n\u00e6vne deres navne, fordi s\u00e5 snart jeg g\u00f8r det, m\u00f8der vi det f\u00f8rste store problem - med navnene.<\/p>\n

Den f\u00f8rste hedder Firebase Real-Time Database<\/i>, og den anden - Firebase Cloud Firestore<\/i>. Begge er produkter fra Firebase suite<\/i> Google. Deres API'er kaldes henholdsvis firebase.database(\u2026)<\/code> og firebase.firestore(\u2026)<\/code>.<\/p>\n

Det skete, fordi Real-Time Database<\/i> simpelthen er den oprindelige Firebase<\/i> f\u00f8r Google k\u00f8bte det i 2014. Derefter besluttede Google at skabe en parallelt produkt baseret p\u00e5 big data fra virksomheden - og kaldte den Firestore with a cloud. Jeg h\u00e5ber, du ikke er blevet forvirret endnu. Hvis du alligevel er blevet forvirret, skal du ikke bekymre dig, jeg har selv skrevet dette afsnit ti gange om. Fordi det er n\u00f8dvendigt at angive<\/i> Firebase, der er baseret p\u00e5 virksomhedens big data, og de kaldte det Firestore with a cloud. Jeg h\u00e5ber, du ikke er blevet forvirret. Hvis du stadig er forvirret, s\u00e5 beh\u00f8ver du ikke bekymre dig, jeg har selv skrevet denne del af artiklen ti gange.<\/p>\n

Fordi det er n\u00f8dvendigt at angive Firebase<\/i> i sp\u00f8rgsm\u00e5let om Firebase, og Firestore<\/i> i sp\u00f8rgsm\u00e5let om Firebase, i det mindste for at du kunne blive forst\u00e5et for flere \u00e5r siden p\u00e5 Stack Overflow.<\/p>\n

Hvis der fandtes en pris for det d\u00e5rligste navngivning af softwareprodukter, ville dette tilf\u00e6lde helt sikkert blive en af \u200b\u200bde nominerede. Hamming-afstanden mellem disse navne er s\u00e5 lille, at den forvirrer erfarne ingeni\u00f8rer, hvis fingre skriver et navn, selvom hovedet t\u00e6nker p\u00e5 et andet. Dette er elendigt mislykkede planer, skabt med de bedste intentioner; de har opfyldt profetien om, at databasen ville g\u00e5 op i flammer. Og jeg sp\u00f8ger ikke. Manden, der fandt p\u00e5 s\u00e5dan et navngivningssystem, har for\u00e5rsaget blod, sved og t\u00e5rer.<\/p>\n

\"Denne<\/p>\n

Pyrrhussejr<\/h2>\n

\nMan kunne tro, at Firestore er en erstatning<\/i> for Firebase, dens n\u00e6ste generation, men det ville v\u00e6re en misforst\u00e5else. Firestore passer bestemt ikke som en erstatning for Firebase. Det virker som om, nogen har sk\u00e5ret alt det interessante ud af den, og forvirret det meste af det resterende p\u00e5 forskellige m\u00e5der.<\/p>\n

Men et hurtigt blik p\u00e5 de to produkter kan forvirre dig: det ser ud til, at de g\u00f8r pr\u00e6cis det samme, gennem stort set de samme API'er og endda i den samme databasesession. Forskellene er subtile og opdages kun ved en grundig komparativ gennemgang af den omfattende dokumentation. Eller n\u00e5r du pr\u00f8ver at portere kode, der fungerer perfekt p\u00e5 Firebase, s\u00e5 det fungerer med Firestore. Allerede da finder du ud af, at databasegr\u00e6nsefladen lyser op, s\u00e5 snart du fors\u00f8ger at tr\u00e6kke og slippe med musen i realtid. Jeg gentager, jeg sp\u00f8ger ikke.<\/p>\n

Firebase-klienten er venlig p\u00e5 den m\u00e5de, at den buffer \u00e6ndringer og udf\u00f8rer automatisk genfors\u00f8g p\u00e5 opdateringer, hvor den prioriterer den seneste skriveoperation. Men Firestore har en gr\u00e6nse p\u00e5 1 skriveoperation pr. dokument pr. bruger pr. sekund, og denne gr\u00e6nse p\u00e5l\u00e6gges af serveren. N\u00e5r du arbejder med det, skal du selv finde en m\u00e5de at omg\u00e5 det p\u00e5 og implementere en hastighedsgr\u00e6nser for opdateringer, selv n\u00e5r du bare pr\u00f8ver at bygge din applikation. Det vil sige, Firestore er en realtidsdatabase uden en realtidsklient, som camoufleres som en ved hj\u00e6lp af API.<\/p>\n

Her begynder vi at se de f\u00f8rste tegn p\u00e5 meningen med Firestore. M\u00e5ske tager jeg fejl, men jeg har en mistanke om, at nogen h\u00f8jt oppe i Googles ledelse s\u00e5 p\u00e5 Firebase efter opk\u00f8bet og sagde: \u201eNej, gud nej, det er uacceptabelt. Kun ikke under mit lederskab.\u201c<\/p>\n

\"Denne
\nHan tr\u00e5dte frem fra sine gemakker og proklamerede:<\/p>\n

\u201e\u00c9n stor JSON-dokument? Nej. Du skal opdele dataene i separate dokumenter, hver af dem m\u00e5 ikke overstige 1 megabyte.\u201c<\/i><\/p>\n

Det ser ud til, at en s\u00e5dan begr\u00e6nsning ikke vil overleve f\u00f8rste m\u00f8de med en hvilken som helst tilstr\u00e6kkeligt motiveret brugerbase. Du ved, det er sandt. Hos os p\u00e5 arbejdet, for eksempel, har vi over 1500 pr\u00e6sentationer, og det er helt normalt.<\/p>\n

Med en s\u00e5dan begr\u00e6nsning bliver du n\u00f8dt til at acceptere, at \u00e9t \u201edokument\u201c i databasen ikke vil ligne nogen objekter, som brugeren kunne kalde et dokument.<\/p>\n

\u201eArrays af arrays, som kan indeholde andre elementer rekursivt? Nej. Arrays vil kun indeholde objekter eller tal af fast l\u00e6ngde, som Herren tilelskede det.\u201c<\/i><\/p>\n

S\u00e5 hvis du h\u00e5bede p\u00e5 at placere din Firestore GeoJSON, vil du opdage, at det er umuligt. Intet dimensionelt er tilladt. H\u00e5ber du elsker Base64 og\/eller JSON inden for JSON.<\/p>\n

\u201eImport og eksport af JSON via HTTP, kommandolinjev\u00e6rkt\u00f8jer eller administrationspanelet? Nej. Du kan kun eksportere og importere data til Google Cloud Storage. S\u00e5dan ser det i \u00f8jeblikket ud. Og n\u00e5r jeg siger \u201edu\u201c, refererer jeg kun til de, der har bef\u00f8jelser som Project Owner. Alle andre kan g\u00e5 og oprette sager.\u201c<\/i><\/p>\n

Som du kan se, er det let at beskrive FireBase datamodel. Den indeholder et stort JSON-dokument, der forbinder JSON-n\u00f8gler med URL-stier. Hvis du registrerer med HTTP PUT<\/code> i \/<\/code> FireBase f\u00f8lgende:<\/p>\n

{\n  \"hello\": \"verden\"\n}<\/code><\/pre>\n
\nS\u00e5 GET \/hello<\/code> vil returnere \"verden\"<\/code>. Generelt fungerer det lige s\u00e5dan, som du forventer. Samlingen af objekter i FireBase \/my-collection\/:id<\/code> t svarer til en JSON-ordbog {\"my-collection\": {...}}<\/code> i roden, hvis indhold er tilg\u00e6ngeligt i \/my-collection<\/code>:<\/p>\n
{\n  \"id1\": {...object},\n  \"id2\": {...object},\n  \"id3\": {...object},\n  \/\/ ...\n}<\/code><\/pre>\n
\nDet fungerer glimrende, hvis hver inds\u00e6ttelse har ID'er uden kollisioner, hvilket der findes en standardl\u00f8sning til i systemet.<\/p>\n
Med andre ord er databasen 100 % kompatibel med JSON (*) og fungerer fremragende med HTTP, som for eksempel CouchDB. Men i det v\u00e6sentlige bruger man den gennem et realtids-API, som abstraherer websockets, godkendelse og abonnementer. Adminpanelet har begge muligheder, hvilket g\u00f8r det muligt at redigere i realtid og at importere\/eksportere JSON. Hvis du holder dig til det i din kode, vil du blive overrasket over, hvor meget specialiseret kode der forsvinder, n\u00e5r du indser, at patch og diff JSON kan l\u00f8se 90 % af de rutinem\u00e6ssige opgaver inden for vedvarende tilstand.<\/p>\n
Firestore's datamodel ligner JSON, men adskiller sig fra den p\u00e5 nogle kritisk vigtige punkter. Jeg har allerede n\u00e6vnt manglen p\u00e5 arrays inden for arrays. Id\u00e9en med sub-samlinger er, at de er f\u00f8rste klasses koncepter, adskilt fra det overordnede JSON-dokument. Da der ikke er nogen klar serialisering til dette, kr\u00e6ver det en specialiseret kodeudf\u00f8relse for at hente og skrive data. For at h\u00e5ndtere egne samlinger skal der skrives egne scripts og v\u00e6rkt\u00f8jer. Adminpanelet tillader kun sm\u00e5 \u00e6ndringer \u00e9t felt ad gangen og har ikke import\/eksportmuligheder.<\/p>\n
De tog en realtids NoSQL-database og gjorde den til en langsom ikke-SQL med auto-sammenslutning og en separat kolonne for ikke-JSON. Noget i stil med GraftQL<\/i>.<\/p>\n
\"Denne<\/p>\n
Hot Java<\/h2>\n
\nHvis Firestore skulle blive mere p\u00e5lidelig og skalerbar, er ironien, at den gennemsnitlige udvikler f\u00e5r en mindre p\u00e5lidelig l\u00f8sning end hvis de havde valgt FireBase 'out-of-the-box'. Den software, som den Grumpy Database Administrator har brug for, kr\u00e6ver et s\u00e5dant niveau af indsats og specialister, at det simpelthen er urealistisk for den niche, hvor der formodentlig skulle v\u00e6re et godt produkt. Det minder om, hvordan HTML5 Canvas slet ikke er en erstatning for Flash, hvis der ikke er udviklingsv\u00e6rkt\u00f8jer og en afspiller. Desuden er Firestore sunket i str\u00e6ben efter datarenshed og steril validering, som blot ikke stemmer overens med, hvordan den gennemsnitlige forretningsbruger gerne arbejder<\/i>: for ham er intet n\u00f8dvendigt, fordi alt til slut er et udkast.<\/p>\n
Den prim\u00e6re ulempe ved FireBase er, at klienten blev oprettet flere \u00e5r f\u00f8r sin tid, endnu f\u00f8r de fleste webudviklere blev klar over immutabilitet. P\u00e5 grund af dette antager FireBase, at du vil \u00e6ndre data, og derfor udnytter den ikke fordelene ved brugergenereret immutabilitet. Desuden genbruger den ikke data i de snapshots, der gives til brugeren, hvilket g\u00f8r det meget vanskeligere at udf\u00f8re diff. For store dokumenter er dens transaktionsmekanisme baseret p\u00e5 \u00e6ndrede diff simpelthen utilstr\u00e6kkelig. Folk, vi har jo allerede WeakMap<\/code> i JavaScript. Det er praktisk.<\/p>\n
Hvis man giver dataene den rette form og ikke g\u00f8r tr\u00e6erne for store, kan man omg\u00e5 dette problem. Men jeg er nysgerrig, ville FireBase v\u00e6re meget mere interessant, hvis udviklerne havde udgivet et virkelig godt klient-API, der bruger immutabilitet i kombination med alvorlige praktiske r\u00e5d vedr\u00f8rende databasedesign. I stedet ser det ud til, at de har fors\u00f8gt at reparere noget, der ikke var i stykker, og det er blevet v\u00e6rre.<\/p>\n
Jeg kender ikke hele logikken, der l\u00e5 til grund for oprettelsen af Firestore. At r\u00e6sonnere om motiverne, der opst\u00e5r inden for en sort boks, er ogs\u00e5 en del af underholdningen. S\u00e5dan en opposition mellem to ekstremt lignende men uforenelige databaser er ret sj\u00e6lden. Som om nogen t\u00e6nkte: \u00abFirebase er bare en funktion, som vi kan emulere i Google Cloud\u00bb<\/i>, men p\u00e5 samme tid endnu ikke har opdaget konceptet med at definere virkelige verdens krav eller skabe nyttige l\u00f8sninger, der im\u00f8dekommer alle disse krav. \u00abLad os lade udviklerne t\u00e6nke over det. Bare g\u00f8r UI'en smuk... Kan vi tilf\u00f8je mere ild?\u00bb<\/i><\/p>\n
Jeg forst\u00e5r et par ting om datastrukturer. Jeg kan tydeligt se, at konceptet \"alt i et stort JSON-tr\u00e6\" er et fors\u00f8g p\u00e5 at abstrahere enhver f\u00f8lelse af storskala struktur fra databasen. At forvente, at softwaren bare kan h\u00e5ndtere enhver tvivlsom fraktal af datastrukturen \u2014 det er bare vanvid. Jeg beh\u00f8ver ikke engang at forestille mig, hvor slemt det kan v\u00e6re, jeg har foretaget strenge kodegennemgange og set ting, som I mennesker ikke engang kan dr\u00f8mme om.<\/i>. Men jeg ved ogs\u00e5, hvordan gode strukturer ser ud, hvordan de skal bruges<\/a><\/noindex> og hvorfor det er n\u00f8dvendigt at g\u00f8re det.<\/a><\/noindex>Jeg kan forestille mig en verden, hvor Firestore ville give fuldst\u00e6ndig mening, og de mennesker, der skabte det, ville tro, de gjorde et godt stykke arbejde. Men vi lever ikke i denne verden.<\/p>\n
St\u00f8tten til opbygning af foresp\u00f8rgsler i FireBase er d\u00e5rlig efter enhver standard, den findes n\u00e6sten ikke. Det kr\u00e6ver bestemt forbedring eller i det mindste en revision. Men Firestore er ikke meget bedre, da den er begr\u00e6nset af de samme en-dimensionale indekser, der findes i simpel SQL. Hvis du har brug for foresp\u00f8rgsler, som folk udf\u00f8rer med kaotiske data, kr\u00e6ves der fuldtekst s\u00f8gning, filtre p\u00e5 flere intervaller og vilk\u00e5rlig brugerdefineret r\u00e6kkef\u00f8lge. Ved n\u00e6rmere eftersyn er mulighederne i simpel SQL for begr\u00e6nsede. Desuden er de eneste SQL-foresp\u00f8rgsler, som folk kan udf\u00f8re i produktionen \u2014 hurtige foresp\u00f8rgsler. Du f\u00e5r brug for en specialiseret l\u00f8sning til indeksering med gennemt\u00e6nkte datastrukturer. Til alt andet skal der i det mindste v\u00e6re en inkrementel map-reduce eller noget lignende.<\/p>\n
Hvis du s\u00f8ger information om dette i Googles dokumentation, h\u00e5ber jeg, at du vil blive henvist til noget som BigTable og BigQuery. Men alle disse l\u00f8sninger er besv\u00e6ret med en s\u00e5dan m\u00e6ngde tungt salgssprog, at du hurtigt vil vende tilbage og begynde at lede efter noget andet.<\/p>\n
Det sidste, du har brug for i en realtidsdatabase, er noget skabt af mennesker og til mennesker, der arbejder efter en l\u00f8nstruktur for ledelsen.<\/p>\n
(*) Det er en vittighed, der findes ikke noget som 100% kompatibilitet med JSON<\/a><\/noindex>.<\/i><\/p>\n
<\/p>\n
Annoncering<\/h4>\n
\nLeder du efter VDS<\/a><\/noindex> en server til fejlfinding af projekter, udvikling og hosting? Du er helt sikkert vores kunde \ud83d\ude42 Daglig priss\u00e6tning af servere i de mest forskellige konfigurationer, antiDDoS og Windows-licenser er allerede inkluderet 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 database er i brand\u2026 | ProHoster","description":"Lad mig fort\u00e6lle en teknisk historie. Mange \u00e5r.","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/eta-baza-dannyh-v-ogne","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\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\/da\/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\/da\/wp-json\/wp\/v2\/posts\/96465","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=96465"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/96465\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media\/96466"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=96465"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=96465"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=96465"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}