{"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\/sl\/blog\/administrirovanie\/eta-baza-dannyh-v-ogne","title":{"rendered":"Ta podatkovna baza je v ognju\u2026","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Ta
\n
\nDovolite mi, da vam povem tehni\u010dno zgodbo.<\/p>\n

Pred mnogimi leti sem razvijal aplikacijo z vklju\u010denimi funkcijami za sodelovanje. To je bil priro\u010den eksperimentalni sklad, ki je izkoristil celoten potencial zgodnjega Reacta in CouchDB. V realnem \u010dasu je sinhroniziral podatke preko JSON. OT<\/a><\/noindex>. Uporabljali so ga v notranjem delu podjetja, vendar je bila \u0161iroka uporabnost in potencial na drugih podro\u010djih o\u010ditna.<\/p>\n

Med poskusom prodaje te tehnologije potencialnim strankam smo se sre\u010dali z nepri\u010dakovanim oviranjem. V demo videu je na\u0161a tehnologija izgledala in delovala odli\u010dno, tukaj ni bilo nobenih te\u017eav. Video je prikazoval natan\u010dno to, kako deluje, in ni\u010d ni bilo simulirano. Izumili in kodirali smo realisti\u010den scenarij uporabe programa.
\n<\/a><\/noindex>
\n\"Ta
\nDejansko je to postalo te\u017eava. Na\u0161 demo je deloval natan\u010dno tako, kot so vsi drugi simulirali delovanje svojih aplikacij. Konkretno, informacije so se takoj prena\u0161ale od A do B, tudi \u010de so to bili veliki medijski datoteki. Po prijavi je vsak uporabnik videl nove vnose. Z aplikacijo so razli\u010dni uporabniki lahko sodelovali pri istem projektu, tudi \u010de je bilo internetno povezavo kje v vasi prekinjeno. To je implicitno zajeto v katerem koli videu o izdelku, narejenem v After Effects.<\/p>\n

\u010ceprav so vsi vedeli, za kaj je gumb Refresh, nih\u010de ni povsem razumel, da so spletne aplikacije, ki jih prosijo, da jih ustvarimo, obi\u010dajno podvr\u017eene svojim omejitvam. In kaj se zgodi, \u010de jih ne potrebujemo ve\u010d, bo uporabni\u0161ka izku\u0161nja povsem druga\u010dna. Ve\u010dinoma so opazili, da lahko 'klepetajo', pu\u0161\u010dajo\u010d sporo\u010dila sogovornikom, zato so se spra\u0161evali, kaj je druga\u010de, na primer od Slacka. Uf-f-f!<\/p>\n

Oblikovanje vsakodnevnih sinhronizacij<\/h2>\n

\n\u010ce \u017ee imate izku\u0161nje z razvojem programske opreme, vas mora motiti potreba, da si zapomnite, da ve\u010dina ljudi ne more preprosto pogledati slike vmesnika in razumeti, kaj bo po\u010del pri interakciji z njim. O tem, kar se dogaja v sami aplikaciji, niti ne govorimo. Zavedanje o tem, kaj lahko<\/i> se zgodi \u2014 je v veliki meri rezultat znanja o tem, kaj se ne more zgoditi in kar se ne sme zgoditi. To zahteva mentalni model<\/a><\/noindex> ne samo ono \u0161to softver radi, ve\u0107 i kako su njegovi delovi uskla\u0111eni i komuniciraju jedni s drugima.<\/p>\n

Klasi\u010dan primer ovog je korisnik koji dvadeset minuta gleda u spinner.gif<\/i>, pitaju\u0107i se kada \u0107e kona\u010dno rad zavr\u0161iti. Programer bi shvatio da je proces verovatno zavezan i da gif nikada ne\u0107e nestati sa ekrana. Ova animacija imituje izvr\u0161avanje posla, ali nije povezana s njegovim stanjem. U takvim slu\u010dajevima neki tehni\u010dari vole prevrnuti o\u010dima, zapanjeni stepenom zablude korisnika. Ipak, primetite ko od njih pokazuje na pokreta\u010de sata i ka\u017ee da su oni zapravo nepomi\u010dni?<\/p>\n

\"Ta
\nU tome se sastoji su\u0161tina vrednosti stvarnog vremena. Danas se baze podataka u stvarnom vremenu i dalje koriste veoma malo, i mnogi ih gledaju sumnji\u010davo. Ve\u0107ina takvih baza podataka aktivno se priklanja NoSQL stilu, zbog \u010dega se obi\u010dno koriste re\u0161enja zasnovana na Mongo-u, o kojima je bolje zaboraviti. Me\u0111utim, za mene to zna\u010di udobnost rada s CouchDB, kao i istra\u017eivanje dizajna struktura koje \u0107e mo\u0107i puniti podacima ne samo neki birokrata. Mislim da svoje vreme tro\u0161im efikasnije.<\/p>\n

Ali prava tema ovog posta je ono \u0161to danas koristim. Ne svojom voljom, ve\u0107 zbog ravnodu\u0161no i slepo primenjene korporativne politike. Zbog toga \u0107u napraviti Potpuno Po\u0161tenu i Nepristrasnu podelu izme\u0111u dva tesno povezana proizvoda za rad s bazama podataka u stvarnom vremenu Google-a.<\/p>\n

\"Ta
\nU nazivima oba ima re\u010d Fire. Jedan se sa setom se\u0107am. Drugi za mene predstavlja drugi oblik vatre. Ne \u017eurim da ka\u017eem njihova imena, jer jedva da to uradim, suo\u010di\u0107emo se s prvim velikim problemom \u2014 imenima.<\/p>\n

Prvi se zove Firebase Real-Time Database<\/i>, a drugi \u2014 Firebase Cloud Firestore<\/i>. Oboje su proizvodi iz Firebase suite<\/i> Google-a. Njihovi API-ji se zovu, redom, firebase.database(\u2026)<\/code> in firebase.firestore(\u2026)<\/code>.<\/p>\n

Tako je ispalo jer je Real-Time Database<\/i> jednostavno izvorni Firebase<\/i> pre nego \u0161to ga je Google kupio 2014. godine. Potom je Google odlu\u010dio da stvori paralelni proizvod kao kopiju kopa<\/i> Firebase na osnovu velikih podataka kompanije, i nazvao je Firestore with a cloud. Nadam se da se jo\u0161 niste zbunili. Ako ste se ipak zbunili, ne brinite, i sam sam prepisivao ovaj deo \u010dlanka deset puta.<\/p>\n

Zato \u0161to treba navesti Firebase<\/i> v zvezi s Firebase, in Firestore<\/i> v zvezi s Firebase, vsaj, da so vas pred nekaj leti razumeli na Stack Overflow.<\/p>\n

\u010ce bi obstajala nagrada za najslab\u0161e poimenovanje programske opreme, bi bil ta primer zagotovo eden izmed kandidatov. Hammingova razdalja med tema imenom je tako majhna, da zmede tudi izku\u0161ene in\u017eenirje, katerih prsti tipkajo eno ime, medtem ko misli zadevajo drugo. To so na\u010drti, ki so propadli s strahotnim udarcem, zasnovani z najbolj\u0161imi nameni; izpolnili so prerokbo, da bo baza podatkov v ognju. In ne \u0161alim se. Oseba, ki je zasnovala to shemo poimenovanja, je postala vzrok za kri, znoj in solze.<\/p>\n

\"Ta<\/p>\n

Pirova zmaga<\/h2>\n

\nLahko bi pomislili, da je Firestore nadomestilo<\/i> Firebase, njegov naslednik naslednje generacije, vendar bi to bila zmota. Firestore zagotovo ni primeren kot nadomestilo za Firebase. Zdi se, da je nekdo iz njega izrezal vse zanimivo, veliko preostalega pa zmedel na razli\u010dne na\u010dine.<\/p>\n

Vendar lahko hitri pogled na dva izdelka zmede: zdi se, da delata isto, preko ve\u010dinoma enakih API-jev in celo v istem seji baz podatkov. Razlike so te\u017eko opazne in jih odkrijemo le pri skrbnem primerjalnem pregledu obse\u017ene dokumentacije. Ali ko posku\u0161ate prenesti kodo, ki deluje brezhibno na Firebase, da bi delovala s Firestore. Takrat \u017ee ugotovite, da se vmesnik baze podatkov v\u017ege, takoj ko posku\u0161ate izvesti povleci in spusti v realnem \u010dasu. \u0160e enkrat, ne \u0161alim se.<\/p>\n

Odjemalec Firebase je vljuden v tem smislu, da predpomni spremembe in izvaja samodejno ponavljanje poskusov posodobitve, pri \u010demer daje prednost zadnji operaciji zapisa. Vendar Firestore omejuje na 1 operacijo zapisa na dokument na uporabnika na sekundo, kar omejuje stre\u017enik. Pri delu z njim se morate sami potruditi, da najdete na\u010din za obhod te omejitve in implementacijo omejevalnika hitrosti posodobitev, tudi ko posku\u0161ate ustvariti svojo aplikacijo. Torej je Firestore baza podatkov v realnem \u010dasu brez stranke v realnem \u010dasu, ki se maskira kot taka s pomo\u010djo API.<\/p>\n

Na tem, mi za\u010dnemo videti prve znake smisla obstoja Firestore. Morda se motim, vendar sumim, da je nekdo visoko v vodstvu Googla po nakupu Firebase samo rekel: \"Ne, o moj bog, ne. To je nesprejemljivo. Samo ne pod mojim vodstvom.\"<\/p>\n

\"Ta
\nPojavil se je iz svojih prostorov in razglasil:<\/p>\n

\"Eden velik dokument JSON? Ne. Podatki bodo razdeljeni na lo\u010dene dokumente, vsak od njih ne sme presegati 1 megabajta.\"<\/i><\/p>\n

Zdi se, da tak\u0161no omejitev ne bo pre\u017eivela prvega sre\u010danja z dovolj motivirano bazo uporabnikov. Veste, da je to res. Pri nas na delu imamo na primer ve\u010d kot poltretjega tiso\u010da predstavitev, in to je popolnoma normalno.<\/p>\n

Ob tak\u0161ni omejitvi se boste morali sprijazniti s tem, da en \"dokument\" v bazi podatkov ne bo podoben nobenemu objektu, ki bi ga uporabnik lahko poimenoval dokument.<\/p>\n

\"Matrike matrik, ki lahko rekurzivno vsebujejo druge elemente? Ne. Matrike bodo vsebovale le objekte ali \u0161tevila fiksne dol\u017eine, kot je bilo zami\u0161ljeno s strani Gospoda.\"<\/i><\/p>\n

Zato, \u010de ste upali v svojo Firestore umestiti GeoJSON, boste ugotovili, da je to nemogo\u010de. Nih\u010de ne dovoljuje ni\u010d neprenormalnega. Upam, da imate radi Base64 in\/ali JSON znotraj JSON.<\/p>\n

\"Uvoz in izvoz JSON prek HTTP, orodja za ukazno vrstico ali nadzorna plo\u0161\u010da? Ne. Lahko boste le izvozili in uvozili podatke v Google Cloud Storage. Tako se, zdi se, zdaj imenuje. In ko re\u010dem 'vi', mislim samo na tiste, ki imajo pooblastila Project Owner. Vsi ostali lahko gredo in ustvarijo tikete.\"<\/i><\/p>\n

Kot vidite, je model podatkov FireBase enostavno opisati. Vsebuje en velik dokument JSON, ki povezuje JSON klju\u010de s potmi URL. \u010ce zapi\u0161ete z uporabo HTTP PUT<\/code> u \/<\/code> FireBase naslednje:<\/p>\n

{\n  \"hello\": \"svet\"\n}<\/code><\/pre>\n
\nPotem GET \/hello<\/code> vrne \"svet\"<\/code>. Na splo\u0161no to deluje to\u010dno tako, kot pri\u010dakujete. Zbirka objektov FireBase \/my-collection\/:id<\/code> je ekvivalentna JSON slovarju {\"my-collection\": {...}}<\/code> v korenu, vsebina je dostopna v \/my-collection<\/code>:<\/p>\n
{\n  \"id1\": {...object},\n  \"id2\": {...object},\n  \"id3\": {...object},\n  \/\/ ...\n}<\/code><\/pre>\n
\nTo deluje odli\u010dno, \u010de ima vsak vstavljen ID brez kolizij, za kar ima sistem standardno re\u0161itev.<\/p>\n
Drugimi besedami, baza podatkov je 100% zdru\u017eljiva z JSON (*) in odli\u010dno deluje s HTTP, na primer, s CouchDB. Vendar jo ve\u010dinoma uporabljate prek API-ja v realnem \u010dasu, ki abstrahira websockets, avtentifikacijo in naro\u010dnine. Administratorska plo\u0161\u010da ima obe mo\u017enosti, kar omogo\u010da tako urejanje v realnem \u010dasu kot tudi uvoz\/izvoz JSON-a. \u010ce se boste v svoji kodi dr\u017eali tega, boste presene\u010deni, koliko specializirane kode bo izginilo, ko boste razumeli, da patch in diff JSON omogo\u010data re\u0161itev 90% rutinskih nalog pri obdelavi trajnega stanja.<\/p>\n
Podatkovni model Firestore je podoben JSON-u, vendar se v nekaterih kriti\u010dnih vidikih razlikuje od njega. \u017de sem omenil pomanjkanje tabel v tabelah. Model pod-collection je zasnovan tako, da so koncepti prvega razreda, lo\u010deni od dokumenta JSON, ki jih vsebuje. Ker ne obstaja nobena pripravljena serializacija, za pridobivanje in zapisovanje podatkov potrebujete specializirano pot izvajanja kode. Za obdelavo lastnih zbirk morate napisati svoje skripte in orodja. Administratorska plo\u0161\u010da vam omogo\u010da, da opravite le majhne spremembe na enem polju naenkrat in nima mo\u017enosti uvoza\/izvoza.<\/p>\n
Vzeli so podatkovno bazo NoSQL v realnem \u010dasu in jo spremenili v po\u010dasno ne-SQL z avtozdru\u017eevanjem in lo\u010denim stolpcem ne-JSON. Nekaj v stilu GraftQL<\/i>.<\/p>\n
\"Ta<\/p>\n
Zagret Java<\/h2>\n
\n\u010ce naj bi Firestore postal bolj zanesljiv in raz\u0161irljiv, je ironija v tem, da bo povpre\u010dni razvijalec prejel manj zanesljivo re\u0161itev, kot \u010de bi izbral FireBase \u2018iz \u0161katle\u2019. Programska oprema, ki jo potrebujete za Mrzlega Administratorja Baze Podatkov, zahteva tak\u0161no raven truda in kalibra strokovnjakov, da je to preprosto nerealisti\u010dno za ni\u0161o, v kateri naj bi bil dober izdelek. To je podobno temu, kot da HTML5 Canvas nikakor ni zamenjava za Flash, \u010de ni orodij za razvoj in predvajalnika. Poleg tega se je Firestore ujela v prizadevanju za \u010distost podatkov in sterilno validacijo, kar preprosto ne ustreza na\u010dinom, kako povpre\u010dni poslovni uporabnik rad dela<\/i>: zanj ni vse nujno, ker na koncu vse ostaja osnutek.<\/p>\n
Glavni nedostatak FireBase-a je to \u0161to je klijent napravljen nekoliko godina pre svog vremena, jo\u0161 pre nego \u0161to su ve\u0107ina web programera saznala o imutabilnosti. Zbog ovog FireBase pretpostavlja da \u0107ete menjati podatke, pa ne koristi prednosti koje pru\u017ea imutabilnost. Pored toga, ne koristi podatke ponovo u snapshot-ima koje korisnik dobija, zbog \u010dega je razlika daleko te\u017ea za izvr\u0161avanje. Za velike dokumente, njegov mehanizam transakcija baziran na promenljivim razlikama je jednostavno neadekvatan. Momci, ve\u0107 imamo WeakMap<\/code> u JavaScript-u. To je zgodno.<\/p>\n
Ako se podacima da odgovaraju\u0107i oblik, i ne pravi prevelika stabla, ovu problematiku je mogu\u0107e zaobi\u0107i. Ali me zanima, da li bi FireBase bio mnogo zanimljiviji da su programeri izbacili stvarno dobar klijentski API koji koristi imutabilnost zajedno sa ozbiljnim prakti\u010dnim savetima o strukturi baza podataka. Umesto toga, izgleda da su poku\u0161ali da poprave ono \u0161to nije pokvareno, i to je samo pogor\u0161alo situaciju.<\/p>\n
Ne znam svu logiku koja je stajala iza stvaranja Firestore-a. Razmi\u0161ljanja o motivima unutar crne kutije su tako\u0111e deo zabave. Takvo suprotstavljanje dva izuzetno sli\u010dna, ali nesrazmerna baze podataka se retko sre\u0107e. Kao da je neko pomislio: \u201eFirebase je samo funkcija koju mo\u017eemo emulirati u Google Cloud-u\u201c<\/i>, ali pritom jo\u0161 nije otkrio koncept definisanja zahteva iz stvarnog sveta ili kreiranja korisnih re\u0161enja koja zadovoljavaju sve te zahteve. \u201eNeka o tome misle programeri. Samo u\u010dinite UI lepim... A mo\u017eemo li dodati vi\u0161e vatre?\u201c<\/i><\/p>\n
Razumem nekoliko stvari o strukturama podataka. Jasno vidim da je koncepcija \u201esve u jednom velikom JSON stablu\u201c poku\u0161aj da se iz baze podataka odstrani bilo kakvo ose\u0107anje za velike strukture. O\u010dekivati da \u0107e softver jednostavno da se izbori sa bilo kojim sumnjivim fraktalom strukture podataka je jednostavno ludost. Ne treba mi ni da zamislim koliko lo\u0161e mo\u017ee biti, obavljao sam rigorozne revizije koda i video sam stvari o kojima vi, ljudi, ni ne sanjate<\/i>. Ali tako\u0111e znam kako izgledaju dobre strukture, kako ih koristiti<\/a><\/noindex> in za\u0161to to treba raditi<\/a><\/noindex>Lahko si predstavljam svet, kjer bi se Firestore zdela povsem smiselna, ljudje, ki so jo ustvarili, pa bi menili, da so opravili dobro delo. Ampak ne \u017eivimo v tem svetu.<\/p>\n
Podpora za gradnjo poizvedb v FireBase je slaba po katerikoli meri, skoraj je ni. Nedvomno potrebujemo izbolj\u0161ave ali vsaj pregled situacije. A Firestore ni veliko bolj\u0161a, saj je omejena na iste enodimenzionalne indekse, ki jih najdemo v preprostem SQL-u. \u010ce potrebujete poizvedbe, ki jih ljudje izvajajo z naklju\u010dnimi podatki, potrebujete polno besedno iskanje, filtre za ve\u010d razponov in poljubno urejanje s strani uporabnikov. Ob natan\u010dnej\u0161em pregledu so funkcije preprostega SQL-a same po sebi preve\u010d omejene. Poleg tega edini SQL-poizvedbe, ki jih ljudje lahko izvajajo v produkciji, so hitre poizvedbe. Potrebovali boste specializirano re\u0161itev za indeksiranje s premi\u0161ljenimi podatkovnimi strukturami. Za vse ostalo bi vsaj morala biti inkrementalna map-reduce ali kaj podobnega.<\/p>\n
\u010ce boste poiskali informacije o tem v dokumentaciji Googla, vas bodo upam da usmerili k \u010demu takemu kot sta BigTable in BigQuery. Vendar so vse te re\u0161itve obremenjene s tako velikim volumnom gostega korporativnega \u017eargona, da se boste hitro vrnili nazaj in za\u010deli iskati nekaj drugega.<\/p>\n
Zadnja stvar, ki jo potrebujete pri bazi podatkov v realnem \u010dasu, je nekaj ustvarjenega za ljudi in od ljudi, ki delujejo na temelju pla\u010d vodstva.<\/p>\n
(*) To je \u0161ala, ne obstaja tak koncept kot 100% JSON zdru\u017eljivost<\/a><\/noindex>.<\/i><\/p>\n
<\/p>\n
V okviru ogla\u0161evanja<\/h4>\n
\nI\u0161\u010dete VDS<\/a><\/noindex> stre\u017enik za razvijanje in gostovanje projektov? Ste na\u0161 strankarski profil \ud83d\ude42 Pla\u010dilo po dnevih za stre\u017enike razli\u010dnih konfiguracij, antiDDoS in licence Windows so \u017ee vklju\u010dene v ceno.<\/p>\n
\"Ta<\/a><\/noindex>
\n
Izvor: 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\udd47Ta baza podatkov je v ognju\u2026 | ProHoster","description":"Dovolite mi, da vam povem tehni\u010dno zgodbo. Mnoge leta.","canonical_url":"https:\/\/prohoster.info\/sl\/blog\/administrirovanie\/eta-baza-dannyh-v-ogne","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sl_SI","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\/sl\/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\/sl\/wp-json\/wp\/v2\/posts\/96465","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/comments?post=96465"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/posts\/96465\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/media\/96466"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/media?parent=96465"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/categories?post=96465"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/tags?post=96465"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}