{"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\/it\/blog\/administrirovanie\/eta-baza-dannyh-v-ogne","title":{"rendered":"Questo database \u00e8 in fiamme\u2026","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Questo
\n
\nLasciate che vi racconti una storia tecnica.<\/p>\n

Molti anni fa, stavo sviluppando un'app con funzionalit\u00e0 integrate di collaborazione. Era un esperimento comodo che utilizzava il pieno potenziale del primo React e di CouchDB. Sincronizzava i dati in tempo reale tramite JSON. OT<\/a><\/noindex>. Venne utilizzato nel lavoro interno dell'azienda, ma l'ampia applicabilit\u00e0 e il potenziale in altri settori erano evidenti.<\/p>\n

Cercando di vendere questa tecnologia a clienti potenziali, ci siamo imbattuti in un ostacolo inaspettato. Nel video dimostrativo, la nostra tecnologia appariva e funzionava bene, qui non c'erano problemi. Il video mostrava esattamente come funzionava, senza alcuna simulazione. Abbiamo elaborato e codificato uno scenario di utilizzo realistico dell'app.
\n<\/a><\/noindex>
\n\"Questo
\nIn realt\u00e0, questo divenne un problema. Il nostro demo funzionava esattamente come tutti gli altri facevano con le proprie applicazioni. In particolare, le informazioni venivano trasmesse istantaneamente da A a B, anche se si trattava di grandi file multimediali. Dopo aver effettuato il login, ogni utente vedeva le nuove registrazioni. Con l'app, diversi utenti potevano collaborare chiaramente su progetti specifici, anche in caso di disconnessione di Internet in una qualche localit\u00e0 sperduta. Ci\u00f2 \u00e8 implicitamente suggerito in qualsiasi video sul prodotto montato in After Effects.<\/p>\n

Nonostante tutti sapessero a cosa servisse il pulsante di aggiornamento, nessuno sembrava comprendere che le web app che ci chiedevano di creare erano generalmente soggette ai propri limiti. E che se non servissero pi\u00f9, l'esperienza utente sarebbe stata completamente diversa. In genere, notavano che si poteva \"chattare\", lasciando messaggi agli interlocutori, e quindi si chiedevano in cosa si differenziasse, ad esempio, da Slack. Uff!<\/p>\n

Design delle sincronizzazioni quotidiane<\/h2>\n

\nSe hai gi\u00e0 esperienza nello sviluppo software, dovrebbe irritarti il dover ricordare che la maggior parte delle persone non pu\u00f2 semplicemente guardare un'immagine dell'interfaccia e capire cosa far\u00e0 interagendo con essa. Per non parlare di ci\u00f2 che accade all'interno stesso del programma. La consapevolezza di cosa pu\u00f2<\/i> succedere \u2014 \u00e8 in gran parte il risultato della conoscenza di ci\u00f2 che non pu\u00f2 e non dovrebbe accadere. Questo richiede modello mentale<\/a><\/noindex> non solo di ci\u00f2 che fa il software, ma anche di come le sue parti sono collegate e comunicano tra loro.<\/p>\n

Un esempio classico di questo \u00e8 l'utente che, per venti minuti, guarda spinner.gif<\/i>, chiedendosi quando finalmente il lavoro si concluder\u00e0. Lo sviluppatore avrebbe capito che il processo probabilmente si era bloccato e che il gif non sarebbe mai scomparso dallo schermo. Questa animazione imita il completamento del lavoro, ma non \u00e8 correlata al suo stato. In situazioni simili, alcuni tecnici amano alzare gli occhi al cielo, stupiti dalla misura dell'illusione degli utenti. Tuttavia, notate chi tra loro indica gli orologi che girano e dice che in realt\u00e0 sono fermi?<\/p>\n

\"Questo
\nQui risiede il valore del tempo reale. Al giorno d'oggi, i database in tempo reale sono ancora utilizzati molto poco e molti li guardano con sospetto. La maggior parte di questi database tende ad inclinarsi verso lo stile NoSQL, il che porta generalmente a utilizzare soluzioni basate su Mongo, che \u00e8 meglio dimenticare. Tuttavia, per me significa lavorare comodamente con CouchDB e apprendere a progettare strutture che possano essere riempite da dati non solo da qualche burocrate. Penso di trascorrere il mio tempo in modo pi\u00f9 ottimale.<\/p>\n

Ma il vero tema di questo post \u00e8 ci\u00f2 che utilizzo oggi. Non per scelta, ma a causa di una politica aziendale adottata con indifferenza e cecit\u00e0. Quindi fornir\u00f2 un confronto Completamente Onesto e Imparziale di due prodotti strettamente correlati per lavorare con i database in tempo reale di Google.<\/p>\n

\"Questo
\nEntrambi hanno la parola Fire nei loro nomi. Uno lo ricordo con affetto. L'altro per me \u00e8 un altro tipo di fuoco. Non ho fretta di dire i loro nomi, perch\u00e9 appena lo far\u00f2, ci troveremo di fronte al primo grande problema: i nomi.<\/p>\n

Il primo si chiama Firebase Real-Time Database<\/i>, e il secondo \u00e8 Firebase Cloud Firestore<\/i>. Entrambi sono prodotti della Firebase suite<\/i> di Google. Le loro API sono chiamate, rispettivamente, firebase.database(\u2026)<\/code> e firebase.firestore(\u2026)<\/code>.<\/p>\n

\u00c8 andata cos\u00ec perch\u00e9 Real-Time Database<\/i> \u00e8 semplicemente la versione originale di Firebase<\/i> prima della sua acquisizione da parte di Google nel 2014. Poi, in Google, hanno deciso di creare un prodotto parallelo, una copia<\/i> di Firebase basata sui big data dell'azienda, e l'hanno chiamata Firestore con cloud. Spero che non vi siate gi\u00e0 persi. Se vi siete persi, non preoccupatevi, ho riscritto questa parte dell'articolo dieci volte.<\/p>\n

Perch\u00e9 \u00e8 necessario specificare Firebase<\/i> riguardo a Firebase, e Firestore<\/i> riguardo a Firebase, almeno per essere compresi alcuni anni fa su Stack Overflow.<\/p>\n

Se ci fosse un premio per il peggior naming dei prodotti software, questo caso sarebbe sicuramente uno dei candidati. La distanza di Hamming tra questi nomi \u00e8 cos\u00ec ridotta che confonde anche ingegneri esperti, le cui dita digitano un nome mentre la mente pensa a un altro. Questi sono piani falliti con grande clamore, concepiti con le migliori intenzioni; hanno adempiuto alla profezia che la banca dati sarebbe andata in fiamme. E non sto affatto scherzando. La persona che ha ideato tale schema di denominazione \u00e8 stata la causa di sangue, sudore e lacrime.<\/p>\n

\"Questo<\/p>\n

Vittoria di Pirro<\/h2>\n

\nSi potrebbe pensare che Firestore sia una sostituzione<\/i> di Firebase, il suo discendente di nuova generazione, ma sarebbe un errore. Firestore non pu\u00f2 assolutamente essere considerato una sostituzione di Firebase. Sembra che qualcuno abbia rimosso tutto ci\u00f2 che era interessante e abbia confuso gran parte di ci\u00f2 che \u00e8 rimasto in vari modi.<\/p>\n

Tuttavia, uno sguardo superficiale ai due prodotti potrebbe confonderti: sembrano fare la stessa cosa, attraverso API sostanzialmente identiche e persino nella stessa sessione di database. Le differenze sono poco evidenti e si scoprono solo mediante un attento studio comparativo della documentazione dettagliata. O quando cerchi di portare un codice che funziona perfettamente su Firebase, affinch\u00e9 funzioni con Firestore. Gi\u00e0 in quel momento scopri che l'interfaccia del database si accende non appena cerchi di eseguire il drag-and-drop in tempo reale. Ripeto, non sto scherzando.<\/p>\n

Il client Firebase \u00e8 gentile nel senso che bufferizza le modifiche e esegue automaticamente il tentativo di aggiornamenti, dando priorit\u00e0 all'ultima operazione di scrittura. Tuttavia, Firestore ha un limite di 1 operazione di scrittura per documento per utente al secondo, e questo limite \u00e8 imposto dal server. Quando lavori con esso, devi trovare tu stesso un modo per aggirarlo e implementare un limitatore della frequenza degli aggiornamenti, anche quando stai semplicemente cercando di creare la tua applicazione. Vale a dire, Firestore \u00e8 un database in tempo reale senza un client in tempo reale, che si maschera da tale attraverso l'API.<\/p>\n

Con questo iniziamo a vedere i primi segni del senso di esistere di Firestore. Forse mi sbaglio, ma sospetto che qualcuno in alto nella dirigenza di Google, dopo aver acquistato Firebase, abbia semplicemente detto: \u00abNo, Dio mio, no. \u00c8 inaccettabile. Non sotto la mia supervisione\u00bb.<\/p>\n

\"Questo
\n\u00c8 uscito dalle sue stanze e ha proclamato:<\/p>\n

\u00abUn grande documento JSON? No. Dovete suddividere i dati in documenti separati, ognuno dei quali avr\u00e0 una dimensione massima di 1 megabyte\u00bb.<\/i><\/p>\n

Sembra che tale limite non sopravvivr\u00e0 al primo incontro con qualsiasi base utenti sufficientemente motivata. Lo sai che \u00e8 cos\u00ec. Da noi, per esempio, abbiamo oltre mille e cinquecento presentazioni, ed \u00e8 assolutamente normale.<\/p>\n

Con tale limite, dovrete rassegnarvi al fatto che un \u00abdocumento\u00bb nel database non assomiglier\u00e0 a nessun oggetto che l'utente possa definire un documento.<\/p>\n

\u00abArray di array, che possono ricorsivamente contenere altri elementi? No. Gli array conterranno solo oggetti o numeri di lunghezza fissa, come previsto dal Signore\u00bb.<\/i><\/p>\n

Quindi, se speravate di inserire il vostro GeoJSON in Firestore, scoprirete che \u00e8 impossibile. \u00c8 inammissibile qualsiasi cosa multidimensionale. Spero che vi piaccia Base64 e\/o JSON all'interno di JSON.<\/p>\n

\u00abImportazione ed esportazione JSON tramite HTTP, strumenti da riga di comando o pannello di amministrazione? No. Potrete solo esportare e importare dati in Google Cloud Storage. Cos\u00ec, sembra che si chiami ora. E quando dico 'voi', mi riferisco solo a coloro che hanno i diritti di Project Owner. Tutti gli altri possono andare a creare ticket.\u00bb<\/i><\/p>\n

Come vedete, il modello dati FireBase \u00e8 facile da descrivere. Contiene un unico enorme documento JSON, che collega le chiavi JSON con i percorsi URL. Se registrate usando HTTP PUT<\/code> in \/<\/code> FireBase il seguente:<\/p>\n

{\n  \"ciao\": \"mondo\"\n}<\/code><\/pre>\n
\nAllora GET \/hello<\/code> restituir\u00e0 \"mondo\"<\/code>. Fondamentalmente, funziona esattamente come vi aspettate. La collezione di oggetti FireBase \/my-collection\/:id<\/code> \u00e8 equivalente a un dizionario JSON {\"mia-collezione\": {...}}<\/code> nella root, il cui contenuto \u00e8 accessibile in \/my-collection<\/code>:<\/p>\n
{\n  \"id1\": {...oggetto},\n  \"id2\": {...oggetto},\n  \"id3\": {...oggetto},\n  \/\/ ...\n}<\/code><\/pre>\n
\nFunziona perfettamente se ogni inserimento ha ID senza collisioni, per cui nel sistema c'\u00e8 una soluzione standard.<\/p>\n
In altre parole, il database \u00e8 compatibile al 100% con JSON (*) e funziona bene con HTTP, ad esempio con CouchDB. Ma, principalmente, lo usi tramite un'API in tempo reale, che astrae i websockets, l'autenticazione e le sottoscrizioni. Il pannello di amministrazione ha entrambe le funzionalit\u00e0, permettendo sia la modifica in tempo reale che l'importazione\/esportazione di JSON. Se nel tuo codice segui lo stesso approccio, rimarrai sorpreso di quanto codice specializzato scomparir\u00e0, quando capirai che patch e diff JSON risolvono il 90% delle attivit\u00e0 di routine nella gestione dello stato persistente.<\/p>\n
Il modello di dati Firestore \u00e8 simile a JSON, ma differisce in alcuni aspetti critici. Ho gi\u00e0 menzionato l'assenza di array all'interno di array. Il modello delle sub-collection \u00e8 progettato affinch\u00e9 siano concetti di prima classe, separati dal documento JSON che le contiene. Poich\u00e9 non esiste una serializzazione pronta per questo, \u00e8 necessaria una via di esecuzione del codice specializzata per leggere e scrivere dati. Per gestire le proprie collezioni \u00e8 necessario scrivere script e strumenti personalizzati. Il pannello di amministrazione consente di apportare solo piccole modifiche a un campo alla volta e non offre possibilit\u00e0 di importazione\/esportazione.<\/p>\n
Hanno preso un database NoSQL in tempo reale e lo hanno trasformato in un lento non-SQL con auto-unione e una colonna separata non-JSON. Qualcosa nello stile di GraftQL<\/i>.<\/p>\n
\"Questo<\/p>\n
Java caldo<\/h2>\n
\nSe Firestore dovesse diventare pi\u00f9 affidabile e scalabile, l'ironia \u00e8 che il developer medio otterr\u00e0 una soluzione meno affidabile rispetto a FireBase \"out of the box\". Il software necessario a un Amministratore di Database Brontolone richiede un livello di impegno e di competenza tali da risultare semplicemente irrealistico per la nicchia in cui, presumibilmente, dovrebbe esistere un buon prodotto. \u00c8 simile a come l\u2019HTML5 Canvas non possa sustituire Flash se non ci sono strumenti di sviluppo e un lettore. Inoltre, Firestore \u00e8 afflitta da un eccesso di attenzione alla purezza dei dati e alla convalida sterile, che semplicemente non \u00e8 in linea con il modo in cui un utente aziendale medio ama lavorare<\/i>: per lui tutto \u00e8 superfluo, perch\u00e9 fino alla fine tutto \u00e8 un progetto in bozza.<\/p>\n
Il principale svantaggio di FireBase \u00e8 che il client \u00e8 stato creato diversi anni prima del suo tempo, ancor prima che la maggior parte degli sviluppatori web scoprisse l'immutabilit\u00e0. Per questo motivo, FireBase presume che tu stia modificando i dati e quindi non sfrutta i vantaggi offerti dall'immutabilit\u00e0. Inoltre, non riutilizza i dati negli snapshot inviati all'utente, il che rende molto pi\u00f9 difficile eseguire un diff. Per documenti di grandi dimensioni, il suo meccanismo di transazione basato su diff mutabili \u00e8 semplicemente inadeguato. Ragazzi, abbiamo gi\u00e0 WeakMap<\/code> in JavaScript. \u00c8 conveniente.<\/p>\n
Se dai ai dati la forma giusta e non rendi gli alberi troppo voluminosi, puoi aggirare questo problema. Ma sono curioso di sapere se FireBase sarebbe molto pi\u00f9 interessante se gli sviluppatori avessero rilasciato una vera e propria API client che utilizza l'immutabilit\u00e0 combinata con consigli pratici seri sulla struttura dei database. Invece, sembra che abbiano cercato di riparare ci\u00f2 che non era rotto, e questo ha reso tutto peggiore.<\/p>\n
Non conosco tutta la logica che ha portato alla creazione di Firestore. Speculare sulle motivazioni che sorgono all'interno di una black box \u00e8 anch'essa parte del divertimento. Questa contrapposizione tra due database estremamente simili ma incomparabili \u00e8 piuttosto rara. \u00c8 come se qualcuno avesse pensato: \u00abFirebase \u00e8 semplicemente una funzione che possiamo emulare in Google Cloud\u00bb<\/i>, ma a quel punto non aveva ancora scoperto il concetto di definire i requisiti del mondo reale o di creare soluzioni utili che soddisfino tutti questi requisiti. \u00abLascia che ci pensino gli sviluppatori. Fai semplicemente l'interfaccia utente bella... E si pu\u00f2 aggiungere pi\u00f9 fuoco?\u00bb<\/i><\/p>\n
Capisco un paio di cose riguardo alle strutture dati. Vedo chiaramente che il concetto di \u00abtutto in un grande albero JSON\u00bb \u00e8 un tentativo di astrarre da un database qualsiasi sentore di una struttura su larga scala. Aspettarsi che il software si occupi di qualsiasi dubbio frattale della struttura dati \u00e8 pura follia. Non ho nemmeno bisogno di immaginare quanto possa essere malvagio tutto, ho eseguito audit rigorosi del codice e ho visto cose che voi umani non potete nemmeno immaginare.<\/i>Ma so anche come appaiono buone strutture, come utilizzarle<\/a><\/noindex> e e perch\u00e9 \u00e8 necessario farlo.<\/a><\/noindex>. Posso immaginare un mondo in cui Firestore sembrerebbe del tutto logico e le persone che l'hanno creata penserebbero di aver fatto un buon lavoro. Ma non viviamo in questo mondo.<\/p>\n
Il supporto alla costruzione di query in FireBase \u00e8 scarso secondo qualsiasi standard, praticamente non esiste. Ha sicuramente bisogno di miglioramenti o perlomeno di una revisione. Ma Firestore non \u00e8 molto meglio, poich\u00e9 \u00e8 limitato agli stessi indici unidimensionali che si trovano in un semplice SQL. Se hai bisogno di query che le persone eseguono con dati disordinati, sono richiesti la ricerca testuale completa, filtri su pi\u00f9 intervalli e un ordine definito liberamente dall'utente. Esaminando da vicino le funzionalit\u00e0 del semplice SQL, si scopre che esse sono troppo limitate. Inoltre, le uniche query SQL che le persone possono eseguire in produzione sono le query rapide. Avrai bisogno di una soluzione specializzata per l'indicizzazione con strutture dati ben progettate. Per tutto il resto, almeno dovrebbe esserci un map-reduce incrementale o qualcosa di simile.<\/p>\n
Se cerchi informazioni al riguardo nella documentazione di Google, spero che ti indirizzino verso qualcosa come BigTable e BigQuery. Tuttavia, tutte queste soluzioni sono accompagnate da una quantit\u00e0 di gergo aziendale cos\u00ec fitta che tornerai rapidamente indietro e inizierai a cercare qualcos'altro.<\/p>\n
Ultima cosa di cui hai bisogno se stai lavorando con un database in tempo reale \u00e8 qualcosa creato da persone e per persone che lavorano su scala salariale per una direzione.<\/p>\n
(*) \u00c8 uno scherzo, non esiste un concetto come compatibilit\u00e0 al 100% con JSON<\/a><\/noindex>.<\/i><\/p>\n
<\/p>\n
In base alla pubblicit\u00e0<\/h4>\n
\nStai cercando VDS<\/a><\/noindex> un server per lo sviluppo e il deployment dei tuoi progetti? Sei sicuramente il nostro cliente \ud83d\ude42 Tariffe giornaliere per server di varie configurazioni, antiDDoS e licenze Windows gi\u00e0 incluse nel prezzo.<\/p>\n
\"Questo<\/a><\/noindex>
\n
Fonte: 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\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\udd47Questo database \u00e8 in fiamme\u2026 | ProHoster","description":"Lasciami raccontare una storia tecnica. Molti anni fa.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/eta-baza-dannyh-v-ogne","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","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\/it\/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\/it\/wp-json\/wp\/v2\/posts\/96465","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=96465"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/96465\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/96466"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=96465"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=96465"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=96465"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}