{"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
\nLasciami raccontare una storia tecnica.<\/p>\n

Molti anni fa, sviluppai un'applicazione con funzionalit\u00e0 di collaborazione integrate. Era una pila sperimentale conveniente, che sfruttava a pieno il potenziale del primo React e CouchDB. Sincronizzava i dati in tempo reale tramite JSON. OT<\/a><\/noindex>. Veniva utilizzata nel lavoro interno dell'azienda, ma la sua 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 alla grande, senza problemi. Il video mostrava esattamente come funzionava e non c'era nulla di simulato. Abbiamo ideato e codificato uno scenario d'uso realistico del programma.
\n<\/a><\/noindex>
\n\"Questo
\nIn realt\u00e0, questo \u00e8 stato il problema. La nostra demo funzionava esattamente come imitavano il funzionamento delle loro applicazioni tutti gli altri. In particolare, le informazioni venivano trasferite istantaneamente da A a B, anche se si trattava di file multimediali di grandi dimensioni. Dopo aver effettuato il login, ogni utente vedeva i nuovi record. Utilizzando l'app, diversi utenti potevano collaborare chiaramente sugli stessi progetti, anche in caso di connessione Internet intermittente da qualche parte nel villaggio. Questo \u00e8 implicitamente sottinteso in qualsiasi video prodotto tagliato in After Effects.<\/p>\n

Nonostante tutti sapessero a cosa servisse il pulsante Refresh, nessuno comprendeva davvero che le web app che ci chiedevano di creare erano soggette alle proprie limitazioni. E che se non fossero pi\u00f9 necessarie, l'esperienza utente sarebbe stata completamente diversa. In generale notavano che si poteva 'chattare', lasciando note ai proprio interlocutori, quindi si chiedevano in cosa fosse diverso, ad esempio, da Slack. Ohh!<\/p>\n

Design delle sincronizzazioni quotidiane<\/h2>\n

\nSe hai gi\u00e0 esperienza nello sviluppo software, capirai quanto possa essere frustrante dover ricordare che la maggior parte delle persone non pu\u00f2 semplicemente guardare un'immagine dell'interfaccia e comprendere cosa far\u00e0 durante l'interazione con essa. Senza contare cosa succede all'interno del programma stesso. La consapevolezza di ci\u00f2 che pu\u00f2<\/i> pu\u00f2 accadere \u00e8 in gran parte il risultato della comprensione di ci\u00f2 che non pu\u00f2 accadere e ci\u00f2 che non dovrebbe accadere. Questo richiede un modello mentale<\/a><\/noindex> non solo di cosa fa il software, ma anche di come le sue singole parti siano collegate e comunichino tra loro.<\/p>\n

Un esempio classico di questo \u00e8 l'utente che, per venti minuti, osserva spinner.gif<\/i>, interrogandosi su quando finalmente il processo si concluder\u00e0. Un sviluppatore capirebbe che il processo \u00e8 probabilmente bloccato e che il gif non scomparir\u00e0 mai dallo schermo. Questa animazione simula il completamento di un lavoro, ma non \u00e8 legata al suo stato. In questi casi, alcuni tecnici amano alzare gli occhi al cielo, meravigliandosi della misura in cui gli utenti siano fuorviati. Tuttavia, notate chi di loro indica le lancette che girano e dice che in realt\u00e0 sono ferme?<\/p>\n

\"Questo
\nQuesto \u00e8 il cuore del valore del tempo reale. Oggi, i database in tempo reale sono ancora poco utilizzati e molti li guardano con sospetto. La maggior parte di questi database tende attivamente verso lo stile NoSQL, il che porta solitamente a soluzioni basate su Mongo, di cui sarebbe meglio dimenticarsi. Tuttavia, per me, questo significa lavorare comodamente con CouchDB e anche studiare la progettazione di strutture in grado di essere riempite con dati, non solo da qualche burocrate. Credo di star ottimizzando il mio tempo.<\/p>\n

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

\"Questo
\nEntrambi i nomi contengono la parola Fire. Uno lo ricordo con affetto. L'altro per me \u00e8 un altro tipo di fuoco. Non mi affretto a dire i loro nomi, perch\u00e9 non 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 si chiamano, rispettivamente, firebase.database(\u2026)<\/code> e firebase.firestore(\u2026)<\/code>.<\/p>\n

\u00c8 accaduto perch\u00e9 Real-Time Database<\/i> \u00e8 semplicemente l'originale Firebase<\/i> prima del suo acquisto da parte di Google nel 2014. Successivamente, Google ha deciso di creare una copia<\/i> di Firebase basata sui big data dell'azienda, chiamandola Firestore with a cloud. Spero che non ti sia ancora confuso. Se ti sei confuso, non preoccuparti, io stesso ho riscritto questa parte dell'articolo dieci volte.<\/p>\n

Perch\u00e9 \u00e8 necessario specificare Firebase<\/i> nella questione di Firebase, e Firestore<\/i> nella questione di Firebase, almeno se volevi essere compreso alcuni anni fa su Stack Overflow.<\/p>\n

Se esistesse un premio per il peggior naming di prodotti software, questo caso sarebbe sicuramente un contendente. La distanza di Hamming tra questi nomi \u00e8 cos\u00ec ridotta che confonde anche ingegneri esperti, le cui mani digitano un nome mentre la mente pensa a un altro. Questi sono piani falliti con un gran fracasso, concepiti con le migliori intenzioni; hanno adempiuto alla profezia secondo cui il database sar\u00e0 in fiamme. E non sto 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 un sostituto<\/i> di Firebase, il suo discendente di nuova generazione, ma sarebbe un errore. Firestore non pu\u00f2 certamente essere considerato un sostituto di Firebase. Sembra che qualcuno abbia rimosso tutto ci\u00f2 che era interessante e confuso gran parte del resto in vari modi.<\/p>\n

Tuttavia, uno sguardo veloce ai due prodotti pu\u00f2 confonderti: sembra che facciano la stessa cosa, attraverso API sostanzialmente identiche e persino nella stessa sessione di database. Le differenze sono sottili e si rivelano solo con un attento confronto della documentazione dettagliata. O quando cerchi di portare un codice che funziona perfettamente su Firebase per farlo funzionare con Firestore. Gi\u00e0 allora scopri che l'interfaccia del database si accende non appena provi a eseguire il drag-and-drop dal vivo. Ripeto, non sto scherzando.<\/p>\n

Il client Firebase \u00e8 cortese nel senso che memorizza le modifiche e esegue automaticamente i tentativi di aggiornamento, dando priorit\u00e0 all'ultima operazione di scrittura. Tuttavia, Firestore ha una limitazione di 1 operazione di scrittura per documento per utente al secondo, e questa restrizione \u00e8 imposta dal server. Quando si lavora con esso, \u00e8 necessario trovare un modo per aggirare questa limitazione e implementare un limitatore di frequenza degli aggiornamenti, anche quando si cerca semplicemente di creare la propria applicazione. In altre parole, Firestore \u00e8 un database in tempo reale senza un client in tempo reale, che si maschera da tale tramite API.<\/p>\n

Qui cominciamo a vedere i primi segni del significato dell'esistenza di Firestore. Potrei sbagliarmi, ma sospetto che qualcuno in cima alla dirigenza di Google dopo l'acquisto di Firebase abbia semplicemente detto: \"No, per l'amor del cielo, no. \u00c8 inaccettabile. Non sotto la mia supervisione.\"<\/p>\n

\"Questo
\nEgli emerse dai suoi loculi e proclam\u00f2:<\/p>\n

\"Un grande documento JSON? No. Voi suddividerete i dati in documenti distinti, ciascuno dei quali non superer\u00e0 1 megabyte.\"<\/i><\/p>\n

Sembra che questa restrizione non possa resistere al primo incontro con qualsiasi base utenti sufficientemente motivata. Lo sai che \u00e8 cos\u00ec. Ad esempio, nel nostro lavoro abbiamo pi\u00f9 di millecinquecento presentazioni, ed \u00e8 assolutamente normale.<\/p>\n

Con tale restrizione dovrai accettare il fatto che un 'documento' nel database non assomiglier\u00e0 a nessun oggetto che un utente potrebbe definire documento.<\/p>\n

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

Quindi, se speravi di inserire un GeoJSON nella tua Firestore, scoprirai che non \u00e8 possibile. Non \u00e8 consentito nulla di non unidimensionale. Spero che ti piaccia Base64 e\/o JSON all'interno di JSON.<\/p>\n

\u00abImportazione ed esportazione di JSON tramite HTTP, strumenti da riga di comando o pannello di amministrazione? No. Potrai solo esportare e importare dati in Google Cloud Storage. Cos\u00ec, sembra si chiami ora. E quando dico 'tu', 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 potete vedere, il modello dei dati FireBase \u00e8 facile da descrivere. Esso contiene un enorme documento JSON che collega le chiavi JSON con i percorsi URL. Se scrivete utilizzando HTTP PUT<\/code> in \/<\/code> FireBase il seguente:<\/p>\n

{\n  \"hello\": \"mondo\"\n}<\/code><\/pre>\n
\nAllora GET \/hello<\/code> restituir\u00e0 \"mondo\"<\/code>. Funziona principalmente proprio come ci si aspetta. La collezione di oggetti FireBase \/my-collection\/:id<\/code> \u00e8 equivalente a un dizionario JSON {\"my-collection\": {...}}<\/code> alla radice, il cui contenuto \u00e8 accessibile in \/my-collection<\/code>:<\/p>\n
{\n  \"id1\": {...object},\n  \"id2\": {...object},\n  \"id3\": {...object},\n  \/\/ ...\n}<\/code><\/pre>\n
\nFunziona ottimamente se ogni inserimento ha un ID senza collisioni, per questo il sistema ha una soluzione standard.<\/p>\n
In altre parole, il database \u00e8 100% compatibile con JSON (*) e funziona perfettamente con HTTP, ad esempio, con CouchDB. Ma principalmente lo utilizzate tramite un API in tempo reale, che astrae i websockets, l'autenticazione e gli abbonamenti. Il pannello di amministrazione offre entrambe le possibilit\u00e0, permettendo sia di effettuare modifiche in tempo reale che di importare\/esportare JSON. Se nel vostro codice vi attenete a questo, rimarrete sorpresi da quanto codice specializzato scomparir\u00e0, quando capirete che patch e diff JSON possono risolvere il 90% delle attivit\u00e0 di routine nella gestione dello stato persistente.<\/p>\n
Il modello di dati Firestore \u00e8 simile a JSON, ma si differenzia in alcuni aspetti critici. Ho gi\u00e0 menzionato l'assenza di array all'interno di array. Il modello delle sub-collection consiste nel trattarle come concetti di primo livello, separati dal documento JSON che le contiene. Poich\u00e9 non esiste una serializzazione pronta, \u00e8 necessario un percorso di esecuzione del codice specializzato per ottenere e scrivere dati. Per gestire collezioni personalizzate, \u00e8 necessario scrivere i propri script e strumenti. Il pannello di amministrazione consente solo piccole modifiche a un campo alla volta e non dispone di funzionalit\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 spirito di GraftQL<\/i>.<\/p>\n
\"Questo<\/p>\n
Java caldo<\/h2>\n
\nSe Firestore doveva diventare pi\u00f9 affidabile e scalabile, l'ironia \u00e8 che lo sviluppatore medio ottiene una soluzione meno affidabile rispetto alla scelta di Firebase \"out of the box\". Il software necessario per un Amministratore di Database Scontento richiede un livello di sforzi e la calibrazione di specialisti tale che \u00e8 semplicemente irrealistico per la nicchia in cui, presumibilmente, dovrebbe esserci un buon prodotto. \u00c8 simile al fatto che l'HTML5 Canvas non \u00e8 affatto un sostituto di Flash, se non ci sono strumenti di sviluppo e un lettore. Inoltre, Firestore \u00e8 affondata nella ricerca della purezza dei dati e di una validazione sterile, che semplicemente non si adatta a come un utente aziendale medio ama lavorare lavora<\/i>: per lui non \u00e8 tutto necessario, perch\u00e9 fino alla fine tutto \u00e8 un progetto preliminare.<\/p>\n
Il principale svantaggio di FireBase \u00e8 che il client \u00e8 stato creato alcuni anni prima del suo tempo, ancora prima che la maggior parte degli sviluppatori web scoprisse l'immuabilit\u00e0. Per questo motivo FireBase presume che tu stia modificando i dati e quindi non sfrutta i benefici dell'immuabilit\u00e0 fornita dall'utente. Inoltre, non riutilizza i dati nei snapshot inviati all'utente, rendendo molto pi\u00f9 difficile eseguire il diff. Per documenti di grandi dimensioni, il suo meccanismo di transazioni basato su diff modificabili \u00e8 semplicemente inadeguato. Ragazzi, abbiamo gi\u00e0 WeakMap<\/code> in JavaScript. \u00c8 comodo.<\/p>\n
Se dai ai dati la forma giusta e non rendi gli alberi troppo pesanti, puoi aggirare questo problema. Ma mi chiedo, diventerebbe FireBase molto pi\u00f9 interessante se gli sviluppatori rilasciassero un vero e proprio API client di qualit\u00e0 che utilizzi l'immuabilit\u00e0 insieme a consigli pratici seri sulla struttura dei database. Invece, sembrano aver tentato di riparare qualcosa che non era rotto, e da questo \u00e8 peggiorato.<\/p>\n
Non conosco tutta la logica che sta alla base della creazione di Firestore. Riflettere sui motivi che emergono all'interno di una scatola nera \u00e8 parte del divertimento. Un confronto tra due database estremamente simili, ma non comparabili, \u00e8 piuttosto raro. Come se qualcuno avesse pensato: \u00abFirebase \u00e8 semplicemente una funzione che possiamo emulare in Google Cloud\u00bb<\/i>, ma senza aver ancora scoperto il concetto di definire requisiti del mondo reale o di creare soluzioni utili che soddisfino tutti questi requisiti. \u00abLasciate che ci pensino gli sviluppatori. Rendete semplicemente l'interfaccia utente bella... E si pu\u00f2 aggiungere un po' pi\u00f9 di fuoco?\u00bb<\/i><\/p>\n
Capisco un paio di cose sulle strutture dati. Vedo chiaramente che il concetto di \u00abtutto in un grande albero JSON\u00bb \u00e8 un tentativo di astrarre dalla base dati qualsiasi sensazione di struttura su larga scala. Aspettarsi che il software gestisca semplicemente qualsiasi dubbioso frattale di struttura dati \u00e8 pura follia. Non ho nemmeno bisogno di immaginare quanto possa andare male, ho effettuato audit rigorosi di codice e ho visto cose che voi umani non potete nemmeno immaginare.<\/i>Ma so anche come si presentano buone strutture, come utilizzarle.<\/a><\/noindex> 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 per la costruzione di query in FireBase \u00e8 scarso secondo qualsiasi standard, praticamente non esiste. Necessita sicuramente di miglioramenti o almeno di una revisione. Tuttavia, Firestore non \u00e8 molto meglio, poich\u00e9 \u00e8 limitato agli stessi indici unidimensionali presenti in un semplice SQL. Se hai bisogno di query che le persone eseguono con dati caotici, \u00e8 necessario un ricerca full-text, filtri su pi\u00f9 intervalli e un ordine arbitrario definito dall'utente. Esaminando attentamente le funzioni di SQL semplice, risultano essere troppo limitate. Inoltre, le uniche query SQL che le persone possono eseguire in produzione sono query rapide. Ti servir\u00e0 una soluzione specializzata per l'indicizzazione con strutture dati ben pensate. Per tutto il resto, almeno dovrebbe esserci un map-reduce incrementale o qualcosa di simile.<\/p>\n
Se cerchi informazioni su questo nei documenti di Google, spero ti verranno indicati qualcosa come BigTable e BigQuery. Tuttavia, tutte queste soluzioni sono accompagnate da una quantit\u00e0 di gergo aziendale cos\u00ec densa che presto tornerai indietro e inizierai a cercare qualcos'altro.<\/p>\n
L'ultima cosa di cui hai bisogno in un database in tempo reale \u00e8 qualcosa creato da persone e per persone che lavorano su scala salariale per i dirigenti.<\/p>\n
(*) \u00c8 uno scherzo, non esiste un concetto come compatibilit\u00e0 con JSON al 100%<\/a><\/noindex>.<\/i><\/p>\n
<\/p>\n
In pubblicit\u00e0<\/h4>\n
\nAlla ricerca di VDS<\/a><\/noindex> un server per debug progetti, sviluppo e hosting? Sei proprio il nostro cliente \ud83d\ude42 La tariffazione giornaliera per server di varie configurazioni, antiDDoS e licenze Windows sono gi\u00e0 inclusi 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":"Lascia che ti racconti una storia tecnica. Molti anni fa, ho sviluppato un'applicazione con funzionalit\u00e0 di collaborazione integrate. Era uno stack sperimentale pratico, che utilizzava il pieno potenziale del primo React e CouchDB. Sincronizzava i dati in tempo reale tramite JSON OT. \u00c8 stato utilizzato nel lavoro interno dell'azienda, ma la sua ampia applicabilit\u00e0 e potenziale in altri ambiti.","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 \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","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"},"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}]}}