Questo database è in fiamme…

Lasciatemi raccontare una storia tecnica.

Molti anni fa sviluppai un'applicazione con funzionalità di collaborazione integrate. Era uno stack sperimentale molto utile, che sfruttava appieno il potenziale del primo React e CouchDB. Sincronizzava i dati in tempo reale tramite JSON. OT. Venne utilizzato nel lavoro interno dell'azienda, ma l'ampia applicabilità e il potenziale in altri settori erano evidenti.

Cercando di vendere questa tecnologia ai potenziali clienti, ci troviamo di fronte a un ostacolo inaspettato. Nel video dimostrativo, la nostra tecnologia appariva e funzionava alla perfezione, senza alcun problema. Il video mostrava esattamente come funzionava, senza alcuna simulazione. Abbiamo ideato e codificato uno scenario di utilizzo realistico del programma.


In realtà, questo è stato il problema. La nostra demo funzionava esattamente come tutte le altre applicazioni imitate. In particolare, le informazioni venivano trasferite istantaneamente da A a B, anche se si trattava di file multimediali di grandi dimensioni. Dopo aver effettuato l'accesso, ogni utente vedeva nuovi aggiornamenti. Grazie all'applicazione, diversi utenti potevano collaborare sui medesimi progetti, anche in caso di interruzioni della connessione Internet in una zona rurale. Ciò è implicitamente sottinteso in qualsiasi video prodotto in After Effects.

Nonostante tutti sapessero a cosa servisse il pulsante Refresh, nessuno comprendeva veramente che le applicazioni web che ci chiedono di creare sono comunemente soggette a limiti. E che se non servissero più, l'esperienza utente sarebbe completamente diversa. In generale, notavano che si poteva "chattare", lasciando messaggi agli interlocutori, quindi si chiedevano in che modo ciò differisse, ad esempio, da Slack. Uff!

Design delle sincronizzazioni quotidiane

Se hai già esperienza nello sviluppo di software, sai quanto possa essere frustrante il bisogno di ricordare che la maggior parte delle persone non può semplicemente guardare un'immagine dell'interfaccia e capire cosa farà interagendovi. Tanto meno sapere cosa accade all'interno del programma stesso. Sapere cosa può può accadere è in gran parte il risultato della consapevolezza di ciò che non può e non deve accadere. Questo richiede un modello mentale non solo di cosa fa il software, ma anche di come le sue componenti sono collegate e comunicano tra loro.

Un esempio classico di questo è l'utente che per venti minuti fissa spinner.gif, chiedendosi quando finalmente il lavoro si concluderà. Lo sviluppatore comprenderebbe che il processo è probabilmente bloccato e che il gif non scomparirà mai dallo schermo. Questa animazione imita l'esecuzione del lavoro, ma non è collegata al suo stato. In tali casi, alcuni tecnici amano alzare gli occhi al cielo, stupendosi del grado di errata percezione degli utenti. Tuttavia, nota chi tra loro indica le lancette che girano e dice che in realtà sono ferme?

Questo è il vero valore del tempo reale. Oggi, i database in tempo reale vengono ancora utilizzati molto poco, e molti li guardano con sospetto. La maggior parte di questi database tende attivamente verso lo stile NoSQL, il che porta comunemente a soluzioni basate su Mongo, che sarebbe meglio dimenticare. Tuttavia, per me questo significa lavorare comodamente con CouchDB, così come studiare la progettazione di strutture che possano essere riempite di dati non solo da qualche burocrate. Penso che stia ottimizzando il mio tempo.

Ma il vero tema di questo post è quello che utilizzo oggi. Non per mia scelta, ma a causa di una politica aziendale applicata in modo indifferente e cieco. Perciò, presenterò un confronto assolutamente onesto e imparziale tra due prodotti strettamente correlati per lavorare con i database in tempo reale di Google.

Entrambi i nomi contengono la parola Fire. Il primo lo ricordo con affetto. Il secondo per me è un altro tipo di fuoco. Non ho fretta di dire i loro nomi, perché non appena lo farò, ci troveremo di fronte alla prima grande problematica: i nomi.

Il primo si chiama Firebase Real-Time Database, e il secondo è Firebase Cloud Firestore. Entrambi sono prodotti della Firebase suite di Google. Le loro API sono chiamate, rispettivamente, firebase.database(…) e firebase.firestore(…).

Questo è accaduto perché Real-Time Database è semplicemente il prodotto originale Firebase prima del suo acquisto da parte di Google nel 2014. Poi Google ha deciso di creare un prodotto parallelo basato su big data dell'azienda, chiamato Firestore with a cloud. Spero che non vi siate già confusi. Se vi siete confusi, non preoccupatevi, ho riscritto questa parte dell'articolo dieci volte. копию Firebase на основе big data компании, и назвали её Firestore with a cloud. Надеюсь, вы ещё не запутались. Если всё-таки запутались, не волнуйтесь, я сам переписывал эту часть статьи десять раз.

Perché è necessario specificare Firebase nella questione di Firebase, e Firestore nella questione di Firebase, almeno per essere compresi diversi anni fa su Stack Overflow.

Se ci fosse un premio per il peggior naming di prodotti software, questo caso sicuramente sarebbe tra i candidati. La distanza di Hamming tra questi nomi è così ridotta che confonde anche gli ingegneri più 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 diceva che il database sarebbe andato a fuoco. E non sto scherzando. La persona che ha ideato tale schema di denominazione è stata la causa di sangue, sudore e lacrime.

Vittoria di Pirro

Si potrebbe pensare che Firestore sia un sostituto di Firebase, il suo discendente di nuova generazione, ma sarebbe un errore. Firestore non è affatto adatto a essere un sostituto di Firebase. Sembrano aver tagliato tutto ciò che era interessante, mentre la maggior parte di ciò che è rimasto è stata confusa in vari modi.

Tuttavia, uno sguardo rapido ai due prodotti può confondere: sembra che svolgano la stessa funzione, attraverso API sostanzialmente identiche e persino nella stessa sessione di database. Le differenze sono poco evidenti e vengono scoperte solo attraverso un'attenta analisi della documentazione dettagliata. Oppure quando cerchi di portare un codice che funziona perfettamente su Firebase affinché funzioni con Firestore. Già in quel momento ti rendi conto che l'interfaccia del database si attiva non appena tenti di eseguire un'operazione di trascinamento del mouse in tempo reale. Ripeto, non sto scherzando.

Il client Firebase è cortese in quanto memorizza le modifiche e esegue automaticamente i tentativi di aggiornamento, dando priorità all'ultima operazione di scrittura. Tuttavia, Firestore ha un limite di 1 operazione di scrittura per documento per utente al secondo, e questo limite è imposto dal server. Quando lavori con esso, devi trovare un modo per aggirarlo e implementare un limiter per la frequenza di aggiornamenti, anche quando stai semplicemente cercando di creare la tua applicazione. In altre parole, Firestore è un database in tempo reale senza un client in tempo reale, che si maschera come tale tramite API.

Qui iniziamo a vedere i primi segni del significato dell'esistenza di Firestore. Forse mi sbaglio, ma sospetto che qualcuno in alto nella direzione di Google abbia guardato dopo l'acquisto di Firebase e semplicemente abbia detto: 'No, Dio mio, no. Questo è inaccettabile. Solo non sotto la mia supervisione.'

Egli uscì dai suoi appartamenti e proclamò:

‘Un grande documento JSON? No. Dividerete i dati in documenti separati, ognuno dei quali avrà una dimensione massima di 1 megabyte.’

Sembra che tale restrizione non resista al primo incontro con una qualsiasi base utenti sufficientemente motivata. Lo sapete anche voi. Ad esempio, nel nostro lavoro abbiamo più di millecinquecento presentazioni, e questo è assolutamente normale.

Con questa limitazione, dovrete accettare il fatto che un 'documento' nel database non assomiglierà a nessun oggetto che l'utente possa chiamare documento.

«Array di array che possono contenere ricorsivamente altri elementi? No. Gli array conterranno solo oggetti o numeri di lunghezza fissa, come voluto dal Signore».

Quindi se speravate di inserire il vostro GeoJSON in Firestore, scoprirete che non è possibile. È inaccettabile qualsiasi cosa non unidimensionale. Spero che vi piaccia Base64 e/o JSON all'interno di JSON.

«Importare ed esportare JSON via HTTP, strumenti della riga di comando o pannello di amministrazione? No. Potrete solo esportare e importare dati in Google Cloud Storage. Così, sembra si chiami adesso. E quando dico 'voi', mi riferisco solo a coloro che hanno i diritti di Project Owner. Tutti gli altri possono andare a creare ticket.»

Come potete vedere, il modello di dati FireBase è facile da descrivere. Esso contiene un grande documento JSON che collega le chiavi JSON ai percorsi URL. Se scrivete usando HTTP PUT in / FireBase il seguente:

{
  "hello": "world"
}

Allora GET /hello restituirà "world". Funziona fondamentalmente come ci si aspetta. La collezione di oggetti FireBase /my-collection/:id è equivalente a un dizionario JSON {"my-collection": {...}} nella radice, il cui contenuto è disponibile in /my-collection:

{
  "id1": {...object},
  "id2": {...object},
  "id3": {...object},
  // ...
}

Funziona perfettamente se ogni inserimento ha un ID senza collisioni, per cui il sistema ha una soluzione standard.

In altre parole, il database è compatibile al 100% con JSON (*) e funziona bene con HTTP, ad esempio con CouchDB. Ma, nella maggior parte dei casi, lo utilizzi tramite API in tempo reale, che astrae websocket, autorizzazioni e sottoscrizioni. Il pannello di amministrazione offre entrambe le possibilità, permettendo di effettuare modifiche in tempo reale e di importare/esportare JSON. Se nel vostro codice seguirete lo stesso approccio, vi stupirete di quanto codice specializzato sparirà quando capirete che patch e diff JSON risolvono il 90% delle attività di routine per la gestione dello stato persistente.

Il modello di dati Firestore è simile a JSON, ma presenta alcune differenze critiche. Ho già menzionato l'assenza di array all'interno di array. Il modello delle sub-collection prevede che siano concetti di primo livello, separati dal documento JSON che le contiene. Poiché non esiste una serializzazione pronta per ciò, è necessario un percorso di esecuzione del codice specializzato per ottenere e scrivere dati. Per gestire le proprie collezioni è necessario scrivere script e strumenti personalizzati. Il pannello di amministrazione consente solo piccole modifiche a un campo alla volta e non ha funzionalità di importazione/esportazione.

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.

Java caldo

Se Firestore doveva diventare più affidabile e scalabile, l'ironia è che lo sviluppatore medio ottiene una soluzione meno affidabile rispetto a scegliere FireBase "out of the box". Il software di cui ha bisogno un Amministratore di Database esigente richiede un livello di impegno e un calibro di specialisti tali che è semplicemente irrealistico per la nicchia in cui, presumibilmente, dovrebbe esserci un buon prodotto. È simile a come l'HTML5 Canvas non sia affatto un sostituto di Flash, se non ci sono strumenti di sviluppo e un lettore. Inoltre, Firestore è afflitta dalla ricerca di una pulizia dei dati e di una validazione sterile, che non corrisponde affatto a come un normale utente business ama lavorare per lui non è necessario, perché fino alla fine tutto è un progetto in corso.:

Il principale svantaggio di FireBase è che il client è stato creato anni prima del previsto, quando la maggior parte degli sviluppatori web non conosceva ancora l'immuabilità. Di conseguenza, FireBase presume che tu modificherai i dati e non sfrutta i vantaggi dell'immuabilità fornita dall'utente. Inoltre, non riutilizza i dati negli snapshot inviati all'utente, rendendo molto più difficile eseguire il diff. Per documenti di grandi dimensioni, il suo meccanismo di transazioni basato su diff modificabili è semplicemente inadeguato. Ragazzi, abbiamo già WeakMap in JavaScript. È comodo.

Se si dà ai dati la forma appropriata e non si rendono gli alberi troppo voluminosi, si può aggirare questo problema. Ma sono curioso, FireBase sarebbe molto più interessante se gli sviluppatori pubblicassero un API client realmente buona che utilizzasse l'immuabilità insieme a consigli pratici su come strutturare i database. Invece, sembra che abbiano cercato di riparare ciò che non era rotto, peggiorando le cose.

Non conosco tutta la logica alla base della creazione di Firestore. Ragionare sui motivi che sorgono all'interno di una scatola nera è anch'esso parte del divertimento. Una tale contrapposizione di due database estremamente simili ma incomparabili si verifica piuttosto raramente. È come se qualcuno avesse pensato: «Firebase è solo una funzione che possiamo emulare in Google Cloud», ma senza aver ancora scoperto il concetto di definizione dei requisiti del mondo reale o di creazione di soluzioni utili che soddisfino tutti questi requisiti. «Lasciate che ci pensino gli sviluppatori. Rendete semplicemente l'interfaccia utente bella... E si può aggiungere un po' di fuoco?»

So alcune cose sulle strutture dati. Vedo chiaramente che il concetto di «tutto in un grande albero JSON» è un tentativo di astrarre dalla base di dati qualsiasi percezione di struttura su larga scala. Aspettarsi che il software gestisca senza problemi qualsiasi frattale discutibile di struttura dati è pura follia. Non ho nemmeno bisogno di immaginare quanto possa andare male, ho fatto audit rigorosi del codice e ho visto cose che voi umani non potete nemmeno immaginare. Ma so anche come appaiono buone strutture, e come utilizzarle e perché è necessario farlo. 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.

Il supporto per la costruzione di query in FireBase è scarso secondo qualsiasi standard, praticamente inesistente. Ha sicuramente bisogno di miglioramenti o almeno di una revisione. Ma Firestore non è molto migliore, poiché è limitata agli stessi indici unidimensionali presenti in un semplice SQL. Se hai bisogno di query che le persone eseguono con dati caotici, sono necessari ricerca full-text, filtri su più intervalli e un ordine arbitrario definito dall'utente. Esaminando attentamente la funzionalità del semplice SQL, risulta che è troppo limitata. Inoltre, gli unici 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.

Se cerchi informazioni su questo nei documenti di Google, spero che ti venga indicato qualcosa come BigTable e BigQuery. Tuttavia, tutte queste soluzioni sono accompagnate da un gergo aziendale così denso che tornerai rapidamente indietro per cercare qualcos'altro.

L'ultima cosa di cui hai bisogno in una base dati in tempo reale è qualcosa creato da persone e per persone che lavorano su scale di stipendio per la dirigenza.

(*) È uno scherzo, non esiste un concetto come compatibilità al 100% con JSON.

In pubblicità

Stai cercando VDS un server per il debug dei progetti, sviluppo e hosting? Sei esattamente il nostro cliente 🙂 La tariffazione giornaliera per server con diverse configurazioni, antiDDoS e licenze Windows sono già inclusi nel prezzo.

Fonte: habr.com