Questo database è in fiamme…

Lasciami raccontare una storia tecnica.

Molti anni fa, sviluppai un'applicazione con funzionalità 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. Veniva utilizzata nel lavoro interno dell'azienda, ma la sua ampia applicabilità e il potenziale in altri settori erano evidenti.

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.


In realtà, questo è 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 è implicitamente sottinteso in qualsiasi video prodotto tagliato in After Effects.

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ù 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!

Design delle sincronizzazioni quotidiane

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

Un esempio classico di questo è l'utente che, per venti minuti, osserva spinner.gif, interrogandosi su quando finalmente il processo si concluderà. Un sviluppatore capirebbe che il processo è probabilmente bloccato e che il gif non scomparirà mai dallo schermo. Questa animazione simula il completamento di un lavoro, ma non è 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à sono ferme?

Questo è 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.

Ma il vero tema di questo post è ciò che utilizzo oggi. Non per mia scelta, ma a causa di una politica aziendale applicata con indifferenza e cecità. Pertanto, fornirò un confronto totalmente 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. Uno lo ricordo con affetto. L'altro per me è un altro tipo di fuoco. Non mi affretto a dire i loro nomi, perché non appena lo farò, ci troveremo di fronte al primo grande problema: 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 si chiamano, rispettivamente, firebase.database(…) e firebase.firestore(…).

È accaduto perché Real-Time Database è semplicemente l'originale Firebase prima del suo acquisto da parte di Google nel 2014. Successivamente, Google ha deciso di creare una copia 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.

Perché è necessario specificare Firebase nella questione di Firebase, e Firestore nella questione di Firebase, almeno se volevi essere compreso alcuni anni fa su Stack Overflow.

Se esistesse un premio per il peggior naming di prodotti software, questo caso sarebbe sicuramente un contendente. La distanza di Hamming tra questi nomi è così 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à in fiamme. 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 può certamente essere considerato un sostituto di Firebase. Sembra che qualcuno abbia rimosso tutto ciò che era interessante e confuso gran parte del resto in vari modi.

Tuttavia, uno sguardo veloce ai due prodotti può 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à allora scopri che l'interfaccia del database si accende non appena provi a eseguire il drag-and-drop dal vivo. Ripeto, non sto scherzando.

Il client Firebase è cortese nel senso che memorizza le modifiche e esegue automaticamente i tentativi di aggiornamento, dando priorità all'ultima operazione di scrittura. Tuttavia, Firestore ha una limitazione di 1 operazione di scrittura per documento per utente al secondo, e questa restrizione è imposta dal server. Quando si lavora con esso, è 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 è un database in tempo reale senza un client in tempo reale, che si maschera da tale tramite API.

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. È inaccettabile. Non sotto la mia supervisione."

Egli emerse dai suoi loculi e proclamò:

"Un grande documento JSON? No. Voi suddividerete i dati in documenti distinti, ciascuno dei quali non supererà 1 megabyte."

Sembra che questa restrizione non possa resistere al primo incontro con qualsiasi base utenti sufficientemente motivata. Lo sai che è così. Ad esempio, nel nostro lavoro abbiamo più di millecinquecento presentazioni, ed è assolutamente normale.

Con tale restrizione dovrai accettare il fatto che un 'documento' nel database non assomiglierà a nessun oggetto che un utente potrebbe definire documento.

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

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

«Importazione 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ì, 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.»

Come potete vedere, il modello dei dati FireBase è facile da descrivere. Esso contiene un enorme documento JSON che collega le chiavi JSON con i percorsi URL. Se scrivete utilizzando HTTP PUT in / FireBase il seguente:

{
  "hello": "world"
}

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

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

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

In altre parole, il database è 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à, 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à, quando capirete che patch e diff JSON possono risolvere il 90% delle attività di routine nella gestione dello stato persistente.

Il modello di dati Firestore è simile a JSON, ma si differenzia in alcuni aspetti critici. Ho già 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é non esiste una serializzazione pronta, è necessario un percorso di esecuzione del codice specializzato per ottenere e scrivere dati. Per gestire collezioni personalizzate, è 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à 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 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 è semplicemente irrealistico per la nicchia in cui, presumibilmente, dovrebbe esserci un buon prodotto. È simile al fatto che l'HTML5 Canvas non è affatto un sostituto di Flash, se non ci sono strumenti di sviluppo e un lettore. Inoltre, Firestore è 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: per lui non è tutto necessario, perché fino alla fine tutto è un progetto preliminare.

Il principale svantaggio di FireBase è che il client è stato creato alcuni anni prima del suo tempo, ancora prima che la maggior parte degli sviluppatori web scoprisse l'immuabilità. Per questo motivo FireBase presume che tu stia modificando i dati e quindi non sfrutta i benefici dell'immuabilità fornita dall'utente. Inoltre, non riutilizza i dati nei 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 dai ai dati la forma giusta e non rendi gli alberi troppo pesanti, puoi aggirare questo problema. Ma mi chiedo, diventerebbe FireBase molto più interessante se gli sviluppatori rilasciassero un vero e proprio API client di qualità che utilizzi l'immuabilità insieme a consigli pratici seri sulla struttura dei database. Invece, sembrano aver tentato di riparare qualcosa che non era rotto, e da questo è peggiorato.

Non conosco tutta la logica che sta alla base della creazione di Firestore. Riflettere sui motivi che emergono all'interno di una scatola nera è parte del divertimento. Un confronto tra due database estremamente simili, ma non comparabili, è piuttosto raro. Come se qualcuno avesse pensato: «Firebase è semplicemente una funzione che possiamo emulare in Google Cloud», ma senza aver ancora scoperto il concetto di definire requisiti del mondo reale o di creare 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' più di fuoco?»

Capisco un paio di cose sulle strutture dati. Vedo chiaramente che il concetto di «tutto in un grande albero JSON» è 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 è 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.Ma so anche come si presentano buone strutture, 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 non esiste. Necessita sicuramente di miglioramenti o almeno di una revisione. Tuttavia, Firestore non è molto meglio, poiché è limitato agli stessi indici unidimensionali presenti in un semplice SQL. Se hai bisogno di query che le persone eseguono con dati caotici, è necessario un ricerca full-text, filtri su più 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à 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.

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à di gergo aziendale così densa che presto tornerai indietro e inizierai a cercare qualcos'altro.

L'ultima cosa di cui hai bisogno in un database in tempo reale è qualcosa creato da persone e per persone che lavorano su scala salariale per i dirigenti.

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

In pubblicità

Alla ricerca di VDS un server per debug progetti, sviluppo e hosting? Sei proprio il nostro cliente 🙂 La tariffazione giornaliera per server di varie configurazioni, antiDDoS e licenze Windows sono già inclusi nel prezzo.

Fonte: habr.com