Diese Datenbank brennt ...

Lassen Sie mich Ihnen eine technische Geschichte erzählen.



Vor vielen Jahren entwickelte ich eine Anwendung mit integrierten Funktionen für die Zusammenarbeit. Es war ein praktischer experimenteller Stack, der das volle Potenzial von Early React und CouchDB ausnutzte. Es synchronisierte Daten über JSON OT in Echtzeit . Es wurde intern im Unternehmen eingesetzt, aber seine breite Anwendbarkeit und sein Potenzial in anderen Bereichen waren offensichtlich.



Beim Versuch, diese Technologie an potenzielle Kunden zu verkaufen, stießen wir auf ein unerwartetes Hindernis. Im Demo-Video sah unsere Technologie großartig aus und funktionierte problemlos. Das Video zeigte genau, wie es funktioniert, und nichts wurde darin nachgeahmt. Wir haben ein realistisches Szenario für die Verwendung des Programms entwickelt und codiert.





In der Tat wurde dies das Problem. Unsere Demo funktionierte genau so, wie alle anderen die Arbeit ihrer Anwendungen simuliert haben. Insbesondere wurden Informationen sofort von A nach B übertragen, selbst wenn es sich um große Mediendateien handelte. Nach dem Anmelden sah jeder Benutzer neue Einträge. Mit der Anwendung konnten verschiedene Benutzer an genau denselben Projekten zusammenarbeiten, selbst wenn die Internetverbindung irgendwo im Dorf unterbrochen wurde. Dies ist implizit in jedem geschnittenen Produktvideo in After Effects enthalten.



Obwohl jeder wusste, wofür die Schaltfläche "Aktualisieren" gedacht war, verstand niemand, dass die Webanwendungen, die wir erstellen sollen, normalerweise ihren eigenen Einschränkungen unterliegen. Und wenn sie nicht mehr benötigt werden, ist die Benutzererfahrung völlig anders. Grundsätzlich haben sie bemerkt, dass Sie "chatten" können, indem Sie den Gesprächspartnern Notizen hinterlassen, und sie haben sich gefragt, wie es sich beispielsweise von Slack unterscheidet. Uf-f-f!

Tägliches Synchronisierungsdesign

Wenn Sie bereits Erfahrung in der Softwareentwicklung haben, sollte es Sie nerven, sich daran zu erinnern, dass die meisten Menschen nicht einfach ein Bild einer Benutzeroberfläche betrachten und verstehen können, was sie bei der Interaktion mit ihr tut. Ganz zu schweigen davon, was im Programm selbst vor sich geht. Zu wissen, was passieren kann , ist größtenteils das Ergebnis des Wissens, was nicht passieren kann und was nicht passieren sollte. Dies erfordert ein mentales Modell nicht nur dessen, was die Software tut, sondern auch, wie ihre einzelnen Teile koordiniert sind und miteinander kommunizieren.



Ein klassisches Beispiel hierfür ist ein Benutzer, der zwanzig Minuten lang auf spinner.gif schautIch frage mich, wann die Arbeit endlich enden wird. Der Entwickler würde verstehen, dass der Prozess wahrscheinlich eingefroren ist und dass das GIF niemals vom Bildschirm verschwindet. Diese Animation simuliert die Ausführung der Arbeit, ist jedoch nicht mit ihrem Status verknüpft. In solchen Fällen rollen einige Technikfreaks gerne mit den Augen und staunen über den Grad der Verwirrung der Benutzer. Beachten Sie jedoch, welcher von ihnen auf die rotierende Uhr zeigt und sagt, dass sie tatsächlich stationär sind?





Dies ist die Essenz des Echtzeitwerts. Echtzeitdatenbanken werden heutzutage noch sehr wenig genutzt, und viele sind ihnen gegenüber misstrauisch. Die meisten dieser Datenbanken tendieren aktiv zum NoSQL-Stil, weshalb sie normalerweise Mongo-basierte Lösungen verwenden, die besser dran sind. Für mich bedeutet dies jedoch den Komfort der Arbeit mit CouchDB sowie das Studium des Entwurfs von Strukturen, die nicht nur einige Bürokraten mit Daten füllen können. Ich denke, ich verbringe meine Zeit besser.



Aber das eigentliche Thema dieses Beitrags ist das, was ich heute benutze. Nicht nach Wahl, sondern wegen der gleichgültig und blind angewandten Unternehmenspolitik. Daher gebe ich Ihnen einen absolut ehrlichen und unvoreingenommenen Vergleich zweier eng verwandter Google-Echtzeitdatenbankprodukte.





Beide haben das Wort Feuer in ihren Namen. Eine Sache erinnere ich mich mit Vorliebe. Das zweite ist für mich eine andere Art von Feuer. Ich habe es nicht eilig, ihre Namen zu sagen, denn sobald ich das tue, stehen wir vor dem ersten großen Problem - den Namen.



Die erste heißt Firebase Real-Time Database und die zweite ist Firebase Cloud Firestore . Beide sind Produkte aus der Firebase-Suite von Google. Ihre APIs heißen jeweils firebase.database(…)und firebase.firestore(…).



Dies liegt daran, dass die Echtzeitdatenbank nur die ursprüngliche Firebase ist, bevor Google sie 2014 gekauft hat. Dann beschloss Google, eine Kopie von zu erstellenFirebase basiert auf den Big Data des Unternehmens und wird als Firestore mit Cloud bezeichnet. Ich hoffe du bist noch nicht verwirrt. Wenn Sie verwirrt sind, machen Sie sich keine Sorgen, ich selbst habe diesen Teil des Artikels zehn Mal umgeschrieben.



Weil Firebase in der Firebase- Frage und Firestore in der Firebase-Frage zitiert werden muss , zumindest um vor einigen Jahren über Stack Overflow verstanden zu werden.



Wenn es eine Auszeichnung für die schlechteste Benennung von Softwareprodukten geben würde, würde dieser Fall definitiv zu einem der Konkurrenten werden. Der Hamming-Abstand zwischen diesen Namen ist so gering, dass selbst erfahrene Ingenieure verwirrt sind, deren Finger einen Namen eingeben, obwohl der Kopf an einen anderen denkt. Dies sind Pläne, die kläglich gescheitert sind und mit den besten Absichten erfunden wurden. Sie erfüllten die Prophezeiung, dass die Datenbank in Flammen stehen würde. Und ich mache keine Witze. Der Mann, der dieses Namensschema erfand, verursachte Blut, Schweiß und Tränen.

Pyrrhussieg

Man würde denken, dass Firestore ein Ersatz für Firebase ist, seinen Nachkommen der nächsten Generation, aber das wäre ein Missverständnis. Firestore ist garantiert kein Ersatz für Firebase. Es sieht so aus, als hätte jemand alles Interessante herausgeschnitten und die meisten anderen auf unterschiedliche Weise verwirrt.



Ein kurzer Blick auf die beiden Produkte kann jedoch verwirrend sein: Sie scheinen dasselbe zu tun, meist über dieselben APIs und sogar in derselben Datenbanksitzung. Die Unterschiede sind subtil und werden erst durch eine sorgfältige vergleichende Untersuchung der umfangreichen Dokumentation deutlich. Oder wenn Sie versuchen, Code zu portieren, der perfekt zu Firebase funktioniert, um mit Firestore zu arbeiten. Selbst dann stellen Sie fest, dass die Datenbankschnittstelle aufleuchtet, sobald Sie versuchen, in Echtzeit per Drag & Drop zu arbeiten. Wieder scherze ich nicht.



Der Firebase-Client ist höflich in dem Sinne, dass er Änderungen puffert und Aktualisierungen automatisch wiederholt, wobei dem letzten Schreibvorgang Vorrang eingeräumt wird. Firestore hat jedoch ein Limit von 1 Schreibvorgängen pro Dokument und Benutzer pro Sekunde, und dieses Limit wird vom Server festgelegt. Wenn Sie damit arbeiten, müssen Sie selbst einen Weg finden, dies zu umgehen und einen Aktualisierungsratenbegrenzer zu implementieren, selbst wenn Sie nur versuchen, Ihre Anwendung zu erstellen. Das heißt, Firestore ist eine Echtzeitdatenbank ohne einen Echtzeitclient, der sich mithilfe einer API tarnt.



Damit sehen wir die ersten Anzeichen für die Bedeutung der Existenz des Firestores. Ich kann mich irren, aber ich vermute, dass sich jemand hoch oben in der Google-Führung um den Kauf bei Firebase gekümmert hat und nur gesagt hat: „Nein, mein Gott, nein. Das ist inakzeptabel. Nur nicht unter meiner Führung. "





Er kam aus seinen Gemächern und verkündete:



„Ein großes JSON-Dokument? Nein. Sie teilen die Daten in separate Dokumente auf, die jeweils nicht größer als 1 Megabyte sind. "



Es sieht so aus, als würde eine solche Einschränkung die erste Begegnung mit einer einigermaßen motivierten Benutzerbasis nicht überleben. Sie wissen, dass es ist. Bei der Arbeit haben wir zum Beispiel über fünfzehnhundert Präsentationen, und das ist vollkommen normal.



Mit dieser Einschränkung müssen Sie sich damit abfinden, dass ein „Dokument“ in der Datenbank nicht wie ein Objekt ist, das der Benutzer ein Dokument aufrufen würde.



„Arrays von Arrays, die rekursiv andere Elemente enthalten können? Nein. Arrays enthalten nur Objekte oder Zahlen fester Länge, wie es der Herr beabsichtigt hat. "



Wenn Sie also gehofft haben, GeoJSON in Ihren Firestore zu bringen, werden Sie feststellen, dass dies nicht möglich ist. Nichts Uneinheitliches ist erlaubt. Ich hoffe, Sie lieben Base64 und / oder JSON in JSON.



JSON-Import und -Export über HTTP, Befehlszeilentools oder Admin-Panel? Nein. Sie können nur Daten in Google Cloud Storage exportieren und importieren. So scheint es jetzt genannt zu werden. Und wenn ich „Sie“ sage, beziehe ich mich nur auf diejenigen, die über die Befugnisse des Projektbesitzers verfügen. Alle anderen können Tickets erstellen. "



Wie Sie sehen können, ist das FireBase-Datenmodell einfach zu beschreiben. Es enthält ein riesiges JSON-Dokument, das JSON-Schlüssel mit URL-Pfaden verknüpft. Wenn Sie Folgendes HTTP PUTin /FireBase schreiben:

{
  "hello": "world"
}

Es GET /hellowird zurückkehren "world". Es funktioniert im Grunde genau so, wie Sie es erwarten würden. Eine Sammlung von FireBase-Objekten /my-collection/:identspricht einem JSON-Wörterbuch {"my-collection": {...}}im Stammverzeichnis, dessen Inhalt verfügbar ist in /my-collection:

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

Dies funktioniert einwandfrei, wenn jeder Einsatz eine Nichtkollisions-ID hat, was die Standardlösung hierfür im System ist.



Mit anderen Worten, die Datenbank ist 100% JSON (*) -kompatibel und funktioniert hervorragend mit HTTP wie CouchDB. Meistens verwenden Sie es jedoch über eine Echtzeit-API, die Websockets, Autorisierungen und Abonnements abstrahiert. Das Admin-Panel verfügt über beide Funktionen und ermöglicht sowohl die Bearbeitung in Echtzeit als auch den JSON-Import / Export. Wenn Sie sich in Ihrem Code an dasselbe halten, werden Sie überrascht sein, wie viel benutzerdefinierter Code verschwendet wird, wenn Sie feststellen, dass Patch- und Diff-JSON 90% der routinemäßigen Aufgaben im persistenten Status lösen.



Das Firestore-Datenmodell ähnelt JSON, unterscheidet sich jedoch in mehreren kritischen Punkten davon. Ich habe bereits das Fehlen von Arrays in Arrays erwähnt. Das Untersammlungsmodell soll ein erstklassiges Konzept sein, das vom enthaltenen JSON-Dokument getrennt ist. Da es hierfür keine sofort einsatzbereite Serialisierung gibt, ist ein spezieller Codepfad erforderlich, um Daten abzurufen und zu schreiben. Um Ihre eigenen Sammlungen zu verarbeiten, müssen Sie Ihre eigenen Skripte und Tools schreiben. Im Admin-Bereich können Sie nur kleine Änderungen in einem Feld vornehmen und haben keine Import- / Exportfunktionen.



Sie nahmen eine NoSQL-Datenbank in Echtzeit und verwandelten sie in eine langsame Nicht-SQL-Datenbank mit automatischer Verknüpfung und einer separaten Nicht-JSON-Spalte. Etwas im Geiste von GraftQL .

Heißes Java

Wenn Firestore zuverlässiger und skalierbarer wird, ist die Ironie, dass der durchschnittliche Entwickler eine weniger zuverlässige Lösung erhält, als FireBase sofort zu wählen. Die Software, die der mürrische Datenbankadministrator benötigt, erfordert so viel Aufwand und Kaliber an Spezialisten, dass es für eine Nische, in der das Produkt gut sein soll, einfach unrealistisch ist. Dies ähnelt der Tatsache, dass HTML5 Canvas Flash überhaupt nicht ersetzt, wenn keine Entwicklungstools und kein Player vorhanden sind. Darüber hinaus ist Firestore auf der Suche nach Datenbereinigung und steriler Validierung festgefahren, was einfach nicht der Art und Weise entspricht, wie ein durchschnittlicher Geschäftsbenutzer gerne arbeitet : Für ihn ist alles optional, da alles ein Entwurf bis zum Ende ist.



Der Hauptnachteil von FireBase besteht darin, dass der Client einige Jahre im Voraus erstellt wurde, noch bevor die meisten Webentwickler von Unveränderlichkeit wussten. Aus diesem Grund geht FireBase davon aus, dass Sie Daten ändern, und nutzt daher die vom Benutzer bereitgestellte Unveränderlichkeit nicht aus. Darüber hinaus werden Daten in Snapshots, die an den Benutzer gesendet werden, nicht wiederverwendet, was den Unterschied erheblich erschwert. Für große Dokumente ist der auf veränderlichen Diff basierende Transaktionsmechanismus einfach unzureichend. Leute, wir haben bereits WeakMapJavaScript. Das ist bequem.



Indem die Daten nach Bedarf geformt werden und die Bäume nicht zu sperrig werden, kann dieses Problem umgangen werden. Aber ich bin gespannt, ob FireBase viel interessanter wäre, wenn die Entwickler eine wirklich gute Client-API herausbringen würden, die Unveränderlichkeit kombiniert mit soliden, praktischen Ratschlägen zum Datenbankdesign verwendet. Stattdessen scheinen sie versucht zu haben, das zu reparieren, was nicht kaputt ist, und das machte es noch schlimmer.



Ich kenne nicht die ganze Logik hinter der Schaffung von Firestore. Das Nachdenken über die Motive, die in der Black Box auftauchen, ist ebenfalls Teil des Spaßes. Dieses Nebeneinander zweier extrem ähnlicher, aber unvergleichlicher Datenbanken ist ziemlich selten. Als ob jemand gedacht hätte: "Firebase ist nur eine Funktion, die wir in Google Cloud emulieren können."Das Konzept der Definition realer Anforderungen oder der Schaffung nützlicher Lösungen, die alle diese Anforderungen erfüllen, wurde jedoch noch nicht entdeckt. „Lassen Sie die Entwickler darüber nachdenken. Mach die Benutzeroberfläche einfach hübsch ... Kannst du mehr Feuer hinzufügen? "



Ich verstehe ein paar Dinge über Datenstrukturen. Ich kann deutlich sehen, dass das Konzept von "alles in einem großen JSON-Baum" ein Versuch ist, jeden Sinn für eine großräumige Struktur aus der Datenbank zu abstrahieren. Zu erwarten, dass Software einfach mit fragwürdigen Fraktalen der Datenstruktur umgeht, ist verrückt. Ich muss mir nicht einmal vorstellen, wie schlimm alles sein kann. Ich habe strenge Code-Audits durchgeführt und etwas gesehen, von dem Sie nie geträumt haben . Ich weiß aber auch, wie gute Strukturen aussehen, wie man sie benutzt undwarum sollte es getan werden . Ich kann mir eine Welt vorstellen, in der Firestore ziemlich logisch erscheint und die Leute, die es geschaffen haben, dachten, sie hätten gute Arbeit geleistet. Aber wir leben nicht in dieser Welt.



Die Unterstützung für das Erstellen von Abfragen in FireBase ist in jeder Hinsicht schlecht, es gibt sie praktisch nicht. Es muss definitiv verbessert oder zumindest überarbeitet werden. Firestore ist jedoch nicht viel besser, da es auf dieselben 1D-Indizes beschränkt ist, die in einfachem SQL enthalten sind. Wenn Sie Abfragen wünschen, die Personen mit chaotischen Daten ausführen, benötigen Sie eine Volltextsuche, Filter für mehrere Bereiche und eine beliebige benutzerdefinierte Reihenfolge. Bei näherer Betrachtung sind die Funktionen von einfachem SQL für sich genommen zu eingeschränkt. Die einzigen SQL-Abfragen, die in der Produktion ausgeführt werden können, sind schnelle Abfragen. Sie benötigen eine spezielle Indizierungslösung mit ausgefeilten Datenstrukturen. Für alles andere sollte es zumindest eine inkrementelle Kartenreduzierung oder ähnliches geben.



Wenn Sie in Google-Dokumenten nach Informationen dazu suchen, werden Sie hoffentlich in Richtung BigTable und BigQuery geleitet. All diese Entscheidungen werden jedoch von einer derart dichten Fachsprache für Unternehmensverkäufe begleitet, dass Sie schnell zurückkehren und nach etwas anderem suchen.



Das Letzte, was Sie im Fall einer Echtzeitdatenbank benötigen, ist etwas, das von Menschen und für Menschen erstellt wurde, die auf einer Gehaltsskala für Führung arbeiten.



(*) Dies ist ein Witz, es gibt keine 100% JSON-Kompatibilität .

---

Werbung

Suchen Sie einen VDS zum Debuggen von Projekten, einen Server für Entwicklung und Bereitstellung? Sie sind definitiv unser Kunde :) Die tägliche Abrechnung von Servern verschiedener Konfigurationen, Anti-DDoS- und Windows-Lizenzen ist bereits im Preis enthalten.