Questo database è in fiamme...

Lasciatemi raccontare una storia tecnica.

Molti anni fa stavo sviluppando un'applicazione con funzionalità di collaborazione integrate. Era uno stack sperimentale facile da usare che sfruttava tutto il potenziale dei primi React e CouchDB. Ha sincronizzato i dati in tempo reale tramite JSON OT. Veniva utilizzato internamente all'azienda, ma la sua ampia applicabilità e il potenziale in altre aree erano evidenti.

Durante il tentativo di vendere questa tecnologia a potenziali clienti, abbiamo riscontrato un ostacolo inaspettato. Nel video dimostrativo, la nostra tecnologia sembrava e funzionava alla grande, senza problemi. Il video mostrava esattamente come funziona e non imitava nulla. Abbiamo ideato e codificato uno scenario realistico per l'utilizzo del programma.


In effetti, questo è diventato il problema. La nostra demo ha funzionato esattamente nel modo in cui tutti gli altri hanno simulato le proprie applicazioni. Nello specifico, 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 ha visto nuove voci. Utilizzando l'applicazione, diversi utenti potevano lavorare insieme chiaramente sugli stessi progetti, anche se la connessione Internet fosse interrotta da qualche parte nel villaggio. Ciò è implicitamente implicito in qualsiasi video del prodotto tagliato in After Effects.

Anche se tutti sapevano a cosa serviva il pulsante Aggiorna, nessuno capiva veramente che le applicazioni web che ci chiedevano di realizzare erano solitamente soggette ai propri limiti. E che se non fossero più necessari, l’esperienza dell’utente sarà completamente diversa. Per lo più hanno notato che potevano "chattare" lasciando note per le persone con cui stavano parlando, quindi si sono chiesti come questo fosse diverso, ad esempio, da Slack. Uff!

Progettazione di sincronizzazioni quotidiane

Se hai esperienza nello sviluppo di software, deve essere snervante ricordare che la maggior parte delle persone non può semplicemente guardare l'immagine di un'interfaccia e capire cosa farà quando interagisce con essa. Per non parlare di ciò che accade all'interno del programma stesso. Conoscenza che может accadere è in gran parte il risultato della conoscenza di ciò che non può accadere e di ciò che non dovrebbe accadere. Questo richiede modello mentale non solo cosa fa il software, ma anche come le sue singole parti sono coordinate e comunicano tra loro.

Un classico esempio di ciò è un utente che fissa un file spinner.gif, chiedendosi quando i lavori saranno finalmente ultimati. Lo sviluppatore si sarebbe reso conto che probabilmente il processo era bloccato e che la gif non sarebbe mai scomparsa dallo schermo. Questa animazione simula l'esecuzione di un lavoro, ma non è correlata al suo stato. In questi casi, ad alcuni tecnici piace alzare gli occhi al cielo, stupiti dalla portata della confusione degli utenti. Tuttavia, notate quanti di loro indicano l'orologio rotante e dicono che in realtà è fermo?

Questa è l’essenza del valore in tempo reale. Al giorno d'oggi, i database in tempo reale sono ancora poco utilizzati e molte persone li guardano con sospetto. La maggior parte di questi database si appoggia fortemente allo stile NoSQL, motivo per cui di solito utilizzano soluzioni basate su Mongo, che è meglio dimenticare. Tuttavia, per me questo significa abituarsi a lavorare con CouchDB, oltre a imparare a progettare strutture che più di un semplice burocrate può riempire di dati. Penso che sto usando meglio il mio tempo.

Ma il vero argomento di questo post è quello che sto usando oggi. Non per scelta, ma per politiche aziendali applicate indifferentemente e ciecamente. Quindi fornirò un confronto completamente corretto e imparziale di due prodotti di database in tempo reale di Google strettamente correlati.

Entrambi hanno la parola Fuoco nel loro nome. Una cosa che ricordo con affetto. La seconda cosa per me è un diverso tipo di fuoco. Non ho fretta di dire i loro nomi, perché una volta fatto ci imbatteremo nel primo grosso problema: i nomi.

Si chiama il primo Database in tempo reale Firebasee il secondo Firebase Cloud Fire Store. Entrambi sono prodotti da Suite Firebase Google. Le loro API vengono chiamate rispettivamente firebase.database(…) и firebase.firestore(…).

Questo è successo perché Banca dati in tempo reale - è solo l'originale Firebase prima del suo acquisto da parte di Google nel 2014. Quindi Google ha deciso di crearlo come prodotto parallelo copiare Firebase basato su una società di big data e lo ha chiamato Firestore con un cloud. Spero che tu non sia ancora confuso. Se sei ancora confuso, non preoccuparti, io stesso ho riscritto questa parte dell’articolo dieci volte.

Perché devi indicare Firebase nella domanda Firebase e fuoco in una domanda su Firebase, almeno per farvi capire qualche anno fa su Stack Overflow.

Se ci fosse un premio per la peggiore esperienza di denominazione del software, questo sarebbe sicuramente uno dei contendenti. La distanza di Hamming tra questi nomi è così piccola da confondere anche gli ingegneri esperti le cui dita digitano un nome mentre la loro testa ne pensa ad un altro. Questi sono piani ben intenzionati che falliscono miseramente; hanno adempiuto la profezia secondo cui il database sarebbe andato a fuoco. E non sto affatto scherzando. La persona che ha ideato questo schema di denominazione ha causato sangue, sudore e lacrime.

Vittoria di Pirro

Si potrebbe pensare che Firestore lo sia замена Firebase, il suo discendente di prossima generazione, ma sarebbe fuorviante. Non è garantito che Firestore sia un sostituto adeguato per Firebase. Sembra che qualcuno abbia tagliato fuori tutto ciò che è interessante e abbia confuso la maggior parte del resto in vari modi.

Tuttavia, una rapida occhiata ai due prodotti potrebbe confonderti: sembrano fare la stessa cosa, sostanzialmente attraverso le stesse API e persino nella stessa sessione di database. Le differenze sono sottili e vengono rivelate solo da un attento studio comparativo di un'ampia documentazione. O quando stai tentando di trasferire codice che funziona perfettamente su Firebase in modo che funzioni con Firestore. Anche allora scopri che l'interfaccia del database si illumina non appena provi a trascinare e rilasciare con il mouse in tempo reale. Ripeto, non sto scherzando.

Il client Firebase è educato nel senso che memorizza nel buffer le modifiche e riprova automaticamente gli aggiornamenti che danno 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 viene applicato dal server. Quando lavori con esso, spetta a te trovare un modo per aggirarlo e implementare un limitatore della velocità di aggiornamento, anche quando stai solo cercando di creare la tua applicazione. Cioè, Firestore è un database in tempo reale senza un client in tempo reale, che si maschera da database che utilizza un'API.

Qui cominciamo a vedere i primi segni della ragion d'essere di Firestore. Potrei sbagliarmi, ma sospetto che qualcuno ai vertici della gestione di Google abbia guardato Firebase dopo l'acquisto e abbia semplicemente detto: "No, oh mio Dio, no. Questo è inaccettabile. Ma non sotto la mia guida."

Uscì dalle sue stanze e dichiarò:

“Un grande documento JSON? NO. Suddividerai i dati in documenti separati, ciascuno dei quali non avrà una dimensione superiore a 1 megabyte.

Sembra che tale limitazione non sopravvivrà al primo incontro con una base di utenti sufficientemente motivata. Lo sai che lo è. Al lavoro, ad esempio, abbiamo più di mille e mezzo presentazioni, e questo è del tutto normale.

Con questa limitazione, sarai costretto ad accettare il fatto che un "documento" nel database non assomiglierà a nessun oggetto che un utente potrebbe chiamare documento.

"Array di array che possono contenere ricorsivamente altri elementi? NO. Gli array conterranno solo oggetti o numeri di lunghezza fissa, come Dio intendeva."

Quindi, se speravi di inserire GeoJSON nel tuo Firestore, scoprirai che ciò non è possibile. Niente che non sia unidimensionale è accettabile. Spero che ti piaccia Base64 e/o JSON all'interno di JSON.

“Importare ed esportare JSON tramite HTTP, strumenti a riga di comando o pannello di amministrazione? NO. Potrai esportare e importare dati solo su Google Cloud Storage. Si chiama così adesso, credo. E quando dico “tu” mi rivolgo solo a coloro che hanno le credenziali di Project Owner. Tutti gli altri possono andare e creare i biglietti."

Come puoi vedere, il modello dati FireBase è facile da descrivere. Contiene un enorme documento JSON che associa le chiavi JSON ai percorsi URL. Se scrivi con HTTP PUT в / FireBase è il seguente:

{
  "hello": "world"
}

il GET /hello tornerà "world". Fondamentalmente funziona esattamente come ti aspetteresti. Raccolta di oggetti FireBase /my-collection/:id equivalente a un dizionario JSON {"my-collection": {...}} nella radice, i cui contenuti sono disponibili in /my-collection:

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

Ciò funziona correttamente se ciascun inserto ha un ID privo di collisioni, per il quale il sistema dispone di una soluzione standard.

In altre parole, il database è compatibile al 100% con JSON(*) e funziona perfettamente con HTTP, come CouchDB. Ma fondamentalmente lo usi tramite un'API in tempo reale che astrae websocket, autorizzazione e abbonamenti. Il pannello di amministrazione ha entrambe le funzionalità, consentendo sia la modifica in tempo reale che l'importazione/esportazione JSON. Se fai lo stesso nel tuo codice, rimarrai sorpreso dalla quantità di codice specializzato che verrà sprecato quando ti renderai conto che patch e diff JSON risolvono il 90% delle attività di routine di gestione dello stato persistente.

Il modello dati Firestore è simile a JSON, ma differisce in alcuni aspetti critici. Ho già menzionato la mancanza di array all'interno di array. Il modello per le sottoraccolte prevede che siano concetti di prima classe, separati dal documento JSON che li contiene. Poiché non esiste una serializzazione già pronta per questo, è necessario un percorso di codice specializzato per recuperare e scrivere i dati. Per elaborare le tue raccolte, devi scrivere i tuoi script e strumenti. Il pannello di amministrazione ti consente solo di apportare 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 join automatico e una colonna non JSON separata. Qualcosa come GraftQL.

Giava calda

Se Firestore dovesse essere più affidabile e scalabile, l'ironia è che lo sviluppatore medio si ritroverà con una soluzione meno affidabile rispetto alla scelta di FireBase pronta all'uso. Il tipo di software di cui ha bisogno l'amministratore del database Grumpy richiede un livello di impegno e un calibro di talento che è semplicemente irrealistico per la nicchia in cui il prodotto dovrebbe essere bravo. Questo è simile al modo in cui HTML5 Canvas non sostituisce affatto Flash se non sono presenti strumenti di sviluppo e un lettore. Inoltre, Firestore è impantanato in un desiderio di purezza dei dati e di convalida sterile che semplicemente non è in linea con il modo in cui l'utente aziendale medio ama lavorare: per lui tutto è facoltativo, perché fino alla fine tutto è un abbozzo.

Lo svantaggio principale di FireBase è che il client è stato creato diversi anni in anticipo sui tempi, prima che la maggior parte degli sviluppatori web conoscessero l'immutabilità. Per questo motivo, FireBase presuppone che modificherai i dati e pertanto non sfrutta l'immutabilità fornita dall'utente. Inoltre, non riutilizza i dati nelle istantanee che passa all'utente, il che rende il diff molto più difficile. Per documenti di grandi dimensioni, il suo meccanismo di transazione mutevole basato su differenze è semplicemente inadeguato. Ragazzi, l'abbiamo già fatto WeakMap in JavaScript. È comodo.

Se dai ai dati la forma desiderata e non rendi gli alberi troppo voluminosi, questo problema può essere aggirato. Ma sono curioso di sapere se FireBase sarebbe molto più interessante se gli sviluppatori rilasciassero un'API client davvero buona che utilizzasse l'immutabilità combinata con alcuni seri consigli pratici sulla progettazione del database. Sembrava invece che cercassero di riparare ciò che non era rotto, e questo peggiorava le cose.

Non conosco tutta la logica dietro la creazione di Firestore. Anche speculare sui motivi che emergono all’interno della scatola nera fa parte del divertimento. Questa giustapposizione di due database estremamente simili ma incomparabili è piuttosto rara. Come se qualcuno pensasse: "Firebase è semplicemente una funzione che possiamo emulare in Google Cloud", ma non ha ancora scoperto il concetto di identificare i requisiti del mondo reale o di creare soluzioni utili che soddisfino tutti questi requisiti. “Lasciate che ci pensino gli sviluppatori. Rendi semplicemente bella l'interfaccia utente... Puoi aggiungere più fuoco?"

Capisco un paio di cose sulle strutture dati. Vedo decisamente il concetto di "tutto in un grande albero JSON" come un tentativo di astrarre qualsiasi senso di struttura su larga scala dal database. Aspettarsi che il software si occupi semplicemente di qualsiasi dubbia struttura di dati frattale è semplicemente folle. Non devo nemmeno immaginare quanto potrebbero essere brutte le cose, ho eseguito rigorosi controlli del codice e Ho visto cose che voi gente non vi sareste mai sognati. Ma so anche come sono le buone strutture, come usarli и perché dovrebbe essere fatto questo?. Posso immaginare un mondo in cui Firestore sembrerebbe logico e le persone che lo hanno creato penserebbero di aver fatto un buon lavoro. Ma non viviamo in questo mondo.

Il supporto delle query di FireBase è scarso rispetto a qualsiasi standard ed è praticamente inesistente. Ha sicuramente bisogno di miglioramenti o almeno di una revisione. Ma Firestore non è molto migliore perché è limitato agli stessi indici unidimensionali presenti nel semplice SQL. Se hai bisogno di query che le persone eseguono su dati caotici, hai bisogno di una ricerca full-text, di filtri multiintervallo e di un ordinamento personalizzato definito dall'utente. Ad un esame più attento, le funzioni del semplice SQL sono di per sé troppo limitate. Inoltre, le uniche query SQL che gli utenti possono eseguire in produzione sono query veloci. Avrai bisogno di una soluzione di indicizzazione personalizzata con strutture dati ponderate. Per tutto il resto, dovrebbe esserci almeno una riduzione incrementale della mappa o qualcosa di simile.

Se cerchi informazioni su Google Docs al riguardo, si spera che verrai indirizzato a qualcosa come BigTable e BigQuery. Tuttavia, tutte queste soluzioni sono accompagnate da un gergo aziendale di vendita così denso che tornerai rapidamente indietro e inizierai a cercare qualcos'altro.

L'ultima cosa che desideri con un database in tempo reale è qualcosa realizzato da e per le persone che lavorano su scale salariali dirigenziali.

(*) Questo è uno scherzo, non esiste Compatibile al 100% con JSON.

Sui diritti della pubblicità

Cercando VDS per i progetti di debug, un server per lo sviluppo e l'hosting? Sei sicuramente un nostro cliente 🙂 Prezzi giornalieri per server di varie configurazioni, licenze anti-DDoS e Windows sono già incluse nel prezzo.

Fonte: habr.com