{"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\/hr\/blog\/administrirovanie\/eta-baza-dannyh-v-ogne","title":{"rendered":"Ova baza podataka gori\u2026","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Ova
\n
\nDopustite mi da ispri\u010dam tehni\u010dku pri\u010du.<\/p>\n

Prije mnogo godina razvijao sam aplikaciju s funkcijama za zajedni\u010dki rad. Bio je to prakti\u010dan eksperimentalni razdjelnik koji je koristio punu sposobnost ranog Reacta i CouchDB-a. U realnom vremenu je sinkronizirao podatke putem JSON-a. OT<\/a><\/noindex>. Koristila se unutar tvrtke, no \u0161iroka primjenjivost i potencijal u drugim podru\u010djima bili su o\u010diti.<\/p>\n

Poku\u0161avaju\u0107i prodati ovu tehnologiju potencijalnim klijentima, nai\u0161li smo na neo\u010dekivanu prepreku. U demo videu na\u0161a tehnologija izgleda i funkcionira odli\u010dno, tu nema problema. Video prikazuje upravo to kako radi, i u njemu ni\u0161ta nije imitirano. Osmislili smo i kodirali realisti\u010dan scenarij primjene programa.
\n<\/a><\/noindex>
\n\"Ova
\nZapravo, to je i postao problem. Na\u0161 demo je radio upravo onako kako su svi drugi imitirali rad svojih aplikacija. Konkretno, informacije su se odmah prenosile od A do B, \u010dak i kada su u pitanju velike medijske datoteke. Nakon prijave, svaki korisnik je mogao vidjeti nove unose. Pomo\u0107u aplikacije razli\u010diti korisnici mogli su zajedno raditi jasno na istim projektima, \u010dak i u slu\u010daju prekidanih internetskih veza negdje u selu. Ova implicirana ideja prisutna je u svakom videu o proizvodu koji je rezan u After Effectsu.<\/p>\n

Iako su svi znali \u010demu slu\u017ei gumb za osvje\u017eavanje, nitko nije u potpunosti razumio da su web aplikacije, koje od nas tra\u017ee da ih razvijamo, obi\u010dno podlo\u017ene vlastitim ograni\u010denjima. I da ako vi\u0161e nisu potrebne, iskustvo korisnika \u0107e biti potpuno druga\u010dije. Uglavnom su primijetili da mogu 'chatati', ostavljaju\u0107i poruke drugima, pa su se pitali \u010dime se to razlikuje, na primjer, od Slacka. Uf-f-f!<\/p>\n

Dizajn svakodnevnih sinkronizacija<\/h2>\n

\nAko ve\u0107 imate iskustva u razvoju softvera, tada vam mora biti iritantno sje\u0107ati se da ve\u0107ina ljudi ne mo\u017ee samo pogledati sliku su\u010delja i razumjeti \u0161to \u0107e raditi kad s njim interagiraju. Ne govorim o tome \u0161to se doga\u0111a unutar same aplikacije. Znanje o tome mo\u017ee<\/i> \u0161to \u0107e se dogoditi \u2014 u velikoj mjeri je rezultat saznanja o tome \u0161to se ne mo\u017ee dogoditi i \u0161to se ne bi smjelo dogoditi. To zahtijeva mentalni model<\/a><\/noindex> ne samo ono \u0161to softver radi, nego i kako su njegovi dijelovi uskla\u0111eni i me\u0111usobno komuniciraju.<\/p>\n

Klasi\u010dan primjer toga je korisnik koji dvadeset minuta gleda na spinner.gif<\/i>, pitaju\u0107i se kada \u0107e kona\u010dno zavr\u0161iti rad. Programer bi shvatio da je proces vjerojatno zapet i da gif nikada ne\u0107e nestati s ekrana. Ova animacija imitira napredovanje rada, ali nije povezana s njegovim stanjem. U takvim slu\u010dajevima neki tehni\u010dari vole prevrnuti o\u010dima, zadivljeni razinom zablude korisnika. Me\u0111utim, primijetite, tko od njih pokazuje na vrte\u0107e satove i tvrdi da oni zapravo miruju?<\/p>\n

\"Ova
\nU tome le\u017ei su\u0161tina vrijednosti stvarnog vremena. Danas se baze podataka u stvarnom vremenu i dalje koriste vrlo rijetko, a mnogi ih gledaju sumnji\u010davo. Ve\u0107ina takvih baza podataka aktivno se naginje prema NoSQL stilu, zbog \u010dega se obi\u010dno koriste rje\u0161enja temeljena na Mongo, o kojima je najbolje zaboraviti. Me\u0111utim, za mene to zna\u010di udobnost rada s CouchDB-om, kao i istra\u017eivanje dizajniranja struktura koje \u0107e mo\u0107i ispunjavati podacima ne samo neki birokrat. Mislim da optimiziranije tro\u0161im svoje vrijeme.<\/p>\n

Ali prava tema ovog posta je ono \u0161to danas koristim. Ne po svom izboru, ve\u0107 zbog ravnodu\u0161no i slijepo primjenjivane korporativne politike. Stoga \u0107u pru\u017eiti Potpuno Po\u0161teno i Objektivno uspore\u0111ivanje dva usko povezana proizvoda za rad s bazama podataka u stvarnom vremenu iz Googlea.<\/p>\n

\"Ova
\nOba imaju rije\u010d Fire u nazivu. Jedno se sje\u0107am s ljubavlju. Drugo za mene predstavlja drugu vrstu vatre. Ne \u017eurim s izgovaranjem njihovih naziva, jer \u010dim to u\u010dinim, suo\u010dit \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>. Oboth su proizvodi iz Firebase suite<\/i> Googlea. Njihova API-ja nazivaju se, redom, firebase.database(\u2026)<\/code> i firebase.firestore(\u2026)<\/code>.<\/p>\n

To se dogodilo jer je Real-Time Database<\/i> \u2014 to je jednostavno izvorni Firebase<\/i> prije nego \u0161to ga je Google kupio 2014. godine. Tada je Google odlu\u010dio stvoriti paralelni proizvod kao kopiju Firebase na temelju big data kompanije, i nazvao ga Firestore s oblakom. Nadam se da se jo\u0161 niste zbunili. Ako ste se ipak zbunili, ne brinite, sam sam deset puta prepisivao ovaj dio \u010dlanka.<\/i> Jer je potrebno navesti<\/p>\n

Jer je potrebno navesti Firebase<\/i> u pitanju Firebase, i Firestore<\/i> u vezi s Firebase, barem da vas razumiju prije nekoliko godina na Stack Overflowu.<\/p>\n

Da postoji nagrada za najgore imenovanje softverskih proizvoda, ovaj slu\u010daj bi zasigurno bio jedan od kandidata. Hammingova udaljenost izme\u0111u ovih imena je toliko mala da zbunjuje \u010dak i iskusne in\u017eenjere, \u010diji prsti kucaju jedno ime, dok misli lutaju prema drugom. To su planovi koji su propali s velikim intenzitetom, smi\u0161ljeni s najboljim namjerama; ispunili su proricanje da \u0107e baza podataka izgorjeti. I ne \u0161alim se. Osoba koja je smislila takav sustav imenovanja postala je uzrok krvi, znoja i suza.<\/p>\n

\"Ova<\/p>\n

Pirova pobjeda<\/h2>\n

\nMoglo bi se pomisliti da je Firestore zamjena<\/i> Firebase, njegov sljede\u0107i generacijski potomak, ali to bi bila zabluda. Firestore nikako nije prikladan kao zamjena za Firebase. Izgleda kao da je netko izvadio sve zanimljivo iz njega, a ve\u0107inu preostaloga izmije\u0161ao na razne na\u010dine.<\/p>\n

Me\u0111utim, brz pogled na dva proizvoda mo\u017ee vas zbuniti: \u010dini se da rade isto, kroz uglavnom iste API-je i \u010dak u istoj sesiji baza podataka. Razlike su nevidljive i otkrivaju se samo pri detaljnom usporednom prou\u010davanju opse\u017ene dokumentacije. Ili kada poku\u0161avate portirati kod koji savr\u0161eno radi na Firebaseu da bi funkcionirao s Firestoreom. Ve\u0107 tada otkrivate da su su\u010delja baza podataka u problemu \u010dim poku\u0161ate izvr\u0161iti povla\u010denje mi\u0161em u stvarnom vremenu. Ponovno, ne \u0161alim se.<\/p>\n

Firebase klijent je obazriv u smislu da ke\u0161ira promjene i automatski ponavlja poku\u0161aje a\u017euriranja, pri \u010demu se prioritet daje posljednjoj operaciji zapisivanja. Me\u0111utim, Firestore ima ograni\u010denje od 1 operacije zapisivanja po dokumentu po korisniku u sekundi, a to ograni\u010denje postavlja poslu\u017eitelj. Kada radite s njim, sami morate prona\u0107i na\u010din da ga zaobi\u0111ete i implementirate ograni\u010diva\u010d brzine a\u017euriranja, \u010dak i kad samo poku\u0161avate izraditi svoju aplikaciju. Drugim rije\u010dima, Firestore je baza podataka u stvarnom vremenu bez klijenta u stvarnom vremenu, koja se pretvara u takvu pomo\u0107u API-ja.<\/p>\n

Time po\u010dinjemo vidjeti prve znakove smisla postojanja Firestore-a. Mo\u017eda grije\u0161im, ali sumnjam da je netko visoko u upravi Googlea pogledao nakon kupnje Firebasea i jednostavno rekao: \u201eNe, bo\u017ee moj, ne. To je neprihvatljivo. Samo ne pod mojim vodstvom.\u201c<\/p>\n

\"Ova
\nPojavio se iz svojih odaja i proglasio:<\/p>\n

\u201eJedan veliki JSON dokument? Ne. Podijelit \u0107ete podatke na odvojene dokumente, od kojih \u0107e svaki biti veli\u010dine ne ve\u0107e od 1 megabajta.\u201c<\/i><\/p>\n

Izgleda da takvo ograni\u010denje ne\u0107e pre\u017eivjeti prvo suo\u010davanje s bilo kojom dovoljno motiviranom bazom korisnika. Znate da je to to\u010dno. U na\u0161em poslu, na primjer, imamo vi\u0161e od dvije i pol tisu\u0107e prezentacija, i to je sasvim normalno.<\/p>\n

S takvim ograni\u010denjem bit \u0107ete primorani pomiriti se s \u010dinjenicom da jedan \u201edokument\u201c u bazi podataka ne\u0107e nalikovati ni jednom objektu koji bi korisnik mogao nazvati dokumentom.<\/p>\n

\u201eMase nizova koji mogu rekurzivno sadr\u017eavati druge elemente? Ne. Nizovi \u0107e sadr\u017eavati samo objekte ili brojeve fiksne du\u017eine, kako je zamislio Gospodin.\u201c<\/i><\/p>\n

Stoga, ako ste se nadali da \u0107ete staviti svoj Firestore GeoJSON, otkrit \u0107ete da to nije mogu\u0107e. Ni\u0161ta vi\u0161edimenzionalno nije dozvoljeno. Nadam se da volite Base64 i\/ili JSON unutar JSON-a.<\/p>\n

\u201eUvoz i izvoz JSON-a putem HTTP-a, alati naredbenog retka ili administrativna plo\u010da? Ne. Mo\u017eete samo izvoziti i uvoziti podatke u Google Cloud Storage. Tako, \u010dini se, sada zovu. I kada ka\u017eem 'vi', obra\u0107am se samo onima koji imaju ovlasti Project Owner. Svi ostali mogu i\u0107i i otvoriti tikete.\u201c<\/i><\/p>\n

Kao \u0161to vidite, model podataka FireBase-a lako je opisati. Sadr\u017ei jedan ogroman JSON dokument koji povezuje JSON klju\u010deve s URL putanjama. Ako zapi\u0161ete pomo\u0107u HTTP PUT<\/code> u \/<\/code> FireBase sljede\u0107e:<\/p>\n

{\n  \"hello\": \"svijet\"\n}<\/code><\/pre>\n
\nOnda GET \/hello<\/code> vratit \u0107e \"svijet\"<\/code>. Uglavnom to funkcionira onako kako o\u010dekujete. Kolekcija objekata FireBase-a \/my-collection\/:id<\/code> ekvivalentna je JSON rje\u010dniku { \"my-collection\": {...}}<\/code> u korijenu, \u010diji je sadr\u017eaj dostupan u \/my-collection<\/code>:<\/p>\n
{\n  \"id1\": {...object},\n  \"id2\": {...object},\n  \"id3\": {...object},\n  \/\/ ...\n}<\/code><\/pre>\n
\nTo funkcionira odli\u010dno, ako svaki umetak ima ID bez kolizija, za \u0161to sustav ima standardno rje\u0161enje.<\/p>\n
Drugim rije\u010dima, baza podataka je 100% kompatibilna s JSON (*) i odli\u010dno funkcionira s HTTP-om, primjerice s CouchDB. No, u osnovi je koristite putem API-a u stvarnom vremenu, koji apstrahira websockets, autorizaciju i pretplate. Administratorska plo\u010da ima obje mogu\u0107nosti, omogu\u0107uju\u0107i ure\u0111ivanje u stvarnom vremenu i uvoz\/izvoz JSON-a. Ako se u svom kodu pridr\u017eavate istog, iznenadit \u0107ete se koliko \u0107e specijaliziranog koda nestati kada shvatite da patch i diff JSON omogu\u0107uju rje\u0161avanje 90% rutinskih zadataka obrade trajnog stanja.<\/p>\n
Model podataka Firestore sli\u010dan je JSON-u, ali se u nekim klju\u010dnim aspektima razlikuje od njega. Ve\u0107 sam spomenuo odsutnost nizova unutar nizova. Model podkolekcija podrazumijeva da su oni prvoklasne koncepcije, odvojene od JSON dokumenta koji ih sadr\u017ei. Budu\u0107i da za ovo ne postoji gotova serijalizacija, za dohvat i zapis podataka potrebna je specijalizirana putanja izvr\u0161avanja koda. Za obradu vlastitih kolekcija potrebno je pisati vlastite skripte i alate. Administratorska plo\u010da omogu\u0107ava vam da unesete samo male promjene po polju odjednom i nema mogu\u0107nosti uvoza\/izvoza.<\/p>\n
Uzeli su NoSQL bazu podataka u stvarnom vremenu i pretvorili je u sporu ne-SQL bazu s automatskim spajanjem i odvojenim stupcem koji nije JSON. Ne\u0161to poput GraftQL<\/i>.<\/p>\n
\"Ova<\/p>\n
Vru\u0107a Java<\/h2>\n
\nAko je Firestore trebao postati pouzdaniji i skalabilniji, ironija je u tome \u0161to prosje\u010dni programer dobiva manje pouzdano rje\u0161enje nego kada bira FireBase 'iz kutije'. Softver koji je potreban Mrzovoljnom Administratoru Baze Podataka zahtijeva takvu razinu napora i kalibra stru\u010dnjaka da je to jednostavno nerealno za ni\u0161u u kojoj bi, pretpostavljam, trebao biti dobar proizvod. To je kao da HTML5 Canvas zapravo nije zamjena za Flash ako nema alata za razvoj i playera. \u0160tovi\u0161e, Firestore je zapao u te\u017enju za \u010disto\u0107om podataka i sterilnom validacijom, \u0161to jednostavno ne odgovara na\u010dinu na koji prosje\u010dan poslovni korisnik voli raditi<\/i>: za njega nije obavezno, jer je do samog kraja sve zapravo nacrt.<\/p>\n
Glavni nedostatak FireBase-a je to \u0161to je klijent razvijen nekoliko godina prije vremena, jo\u0161 prije nego \u0161to su ve\u0107ina web programera saznala za imutabilnost. Zbog toga FireBase pretpostavlja da \u0107ete mijenjati podatke, stoga ne koristi prednosti imutabilnosti koju korisnici osiguravaju. Tako\u0111er, ne koristi podatke ponovo u proslije\u0111enim korisni\u010dkim snimcima, zbog \u010dega je razlika (diff) daleko slo\u017eenija. Za velike dokumente njegov mehanizam transakcija temeljen na promjenjivim razlikama jednostavno nije adekvatan. Ljudi, ve\u0107 imamo WeakMap<\/code> u JavaScriptu. To je prakti\u010dno.<\/p>\n
Ako se podacima pru\u017ei pravi oblik, i ne prave se drve\u0107a prevelikima, ovaj problem se mo\u017ee zaobi\u0107i. No, zanima me, bi li FireBase bio mnogo zanimljiviji da su developeri izdali zaista dobar klijentski API, koji bi koristio imutabilnost zajedno s ozbiljnim prakti\u010dnim savjetom o strukturi baza podataka. Umjesto toga, \u010dini se da su poku\u0161ali popraviti ono \u0161to nije pokvareno, i od toga je postalo lo\u0161ije.<\/p>\n
Ne znam svu logiku koja je stajala iza stvaranja Firestore-a. Razmi\u0161ljanja o motivima unutar crne kutije tako\u0111er su dio zabave. Takvo suprotstavljanje dviju izuzetno sli\u010dnih, ali neusporedivih baza podataka se pojavljuje prili\u010dno rijetko. Kao da je netko pomislio: \u201eFirebase je jednostavno funkcija koju mo\u017eemo emulirati u Google Cloud\u201c<\/i>, ali pritom jo\u0161 nije otkrio koncept definiranja zahtjeva iz stvarnog svijeta ili stvaranja korisnih rje\u0161enja koja zadovoljavaju sve te zahtjeve. \u201eNeka o tome razmi\u0161ljaju developeri. Samo u\u010dinite UI lijepim\u2026 A da li se mo\u017ee dodati vi\u0161e vatre?\u201c<\/i><\/p>\n
Razumijem nekoliko stvari o strukturama podataka. Jasno vidim da je koncept \u201esve u jednom velikom JSON stablu\u201c poku\u0161aj da se iz baze podataka odstrani bilo kakav osje\u0107aj velike strukture. O\u010dekivati da softver jednostavno rije\u0161i bilo koji sumnjivi fraktal strukture podataka je jednostavno ludilo. Ne trebam ni zami\u0161ljati koliko lo\u0161e sve to mo\u017ee biti, radio sam stroge revizije koda i vidio sam stvari o kojima vi, ljudi, niste ni sanjali<\/i>. No, tako\u0111er znam kako izgledaju dobre strukture, kako ih koristiti<\/a><\/noindex> i za\u0161to to treba raditi<\/a><\/noindex>Mogu zamisliti svijet u kojem bi Firestore djelovao potpuno razumno, a njegovi stvoritelji smatrali bi da su obavili dobar posao. No, ne \u017eivimo u tom svijetu.<\/p>\n
Podr\u0161ka za izgradnju upita u FireBase je slaba prema bilo kojim standardima, prakti\u010dki je ne postoji. Definitivno zahtijeva pobolj\u0161anja ili barem reviziju. No, Firestore nije mnogo bolji jer je ograni\u010den na iste jednodimenzionalne indekse koji postoje u jednostavnom SQL-u. Ako su vam potrebni upiti koje ljudi izvode s kaoti\u010dnim podacima, potrebna vam je puna tekstna pretraga, filtri po vi\u0161e raspona i proizvoljan redoslijed koji korisnici mogu postaviti. U pa\u017eljivom pregledu, osnovne SQL funkcije su same po sebi previ\u0161e ograni\u010dene. Osim toga, jedini SQL upiti koje ljudi mogu izvoditi u produkciji su brzi upiti. Trebat \u0107e vam specijalizirano rje\u0161enje za indeksiranje s promi\u0161ljenim strukturama podataka. Za sve ostalo, barem bi trebao biti inkrementalni map-reduce ili ne\u0161to sli\u010dno.<\/p>\n
Ako potra\u017eite informacije o ovome u Googleovim dokumentima, nadam se da \u0107e vam ukazati put prema ne\u010demu poput BigTable i BigQuery. Me\u0111utim, sva ta rje\u0161enja dolaze s tolikom koli\u010dinom gustog korporativnog \u017eargona, da \u0107ete se brzo vratiti natrag i po\u010deti tra\u017eiti ne\u0161to drugo.<\/p>\n
Posljednje \u0161to vam treba u slu\u010daju baze podataka u stvarnom vremenu je ne\u0161to stvoreno od strane ljudi i za ljude, koje funkcionira prema platnim skalama menad\u017ementa.<\/p>\n
(*) To je \u0161ala, ne postoji takav pojam kao 100% kompatibilnost s JSON-om<\/a><\/noindex>.<\/i><\/p>\n
<\/p>\n
U okviru reklame<\/h4>\n
\nTra\u017eite VDS<\/a><\/noindex> poslu\u017eitelj za razvoj i hosting koji \u0107e vam pomo\u0107i u debagiranju projekata? Vi ste definitivno na\u0161 klijent \ud83d\ude42 Naplata poslu\u017eitelja raznih konfiguracija po danu, antiDDoS i Windows licence su ve\u0107 uklju\u010deni u cijenu.<\/p>\n
\"Ova<\/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\udd47Ova baza podataka gori\u2026 | ProHoster","description":"Dopustite da vam ispri\u010dam tehni\u010dku pri\u010du. Prije mnogo godina.","canonical_url":"https:\/\/prohoster.info\/hr\/blog\/administrirovanie\/eta-baza-dannyh-v-ogne","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"hr_HR","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\/hr\/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\/hr\/wp-json\/wp\/v2\/posts\/96465","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/comments?post=96465"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/posts\/96465\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/media\/96466"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/media?parent=96465"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/categories?post=96465"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/tags?post=96465"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}