Diese Datenbank brennt…

Lassen Sie mich 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 frühem React und CouchDB nutzte. Die Daten wurden in Echtzeit über JSON synchronisiert OT. Es wurde in der internen Arbeit des Unternehmens verwendet, jedoch war die breite Anwendbarkeit und das Potenzial in anderen Bereichen offensichtlich.

Als wir versuchten, diese Technologie potenziellen Kunden zu verkaufen, stießen wir auf ein unerwartetes Hindernis. Im Demovideo sah unsere Technologie großartig aus und funktionierte einwandfrei, da gab es keine Probleme. Das Video zeigte genau, wie es funktioniert, und es wurde nichts simuliert. Wir hatten ein realistisches Anwendungsszenario für das Programm gedacht und codiert.


In der Tat wurde das zum Problem. Unsere Demo funktionierte genau so, wie alle anderen es taten, die ihre Anwendungen simulierten. Konkret wurde die Information sofort von A nach B übermittelt, selbst wenn es sich um große Mediendateien handelte. Nach dem Login sah jeder Benutzer neue Einträge. Mithilfe der Anwendung konnten verschiedene Benutzer deutlich an denselben Projekten zusammenarbeiten, selbst bei instabiler Internetverbindung irgendwo im Dorf. Eine solche Annahme ist implizit in jedem in After Effects geschnittenen Produktvideo.

Obwohl alle wussten, wofür die Schaltfläche Aktualisieren gedacht war, verstanden nur sehr wenige, dass Webanwendungen, die sie uns bitten zu erstellen, normalerweise ihren Einschränkungen unterliegen. Und dass, wenn sie nicht mehr benötigt werden, die Benutzererfahrung völlig anders sein wird. Im Wesentlichen bemerkten sie, dass man "chatten" konnte, indem man den Gesprächspartnern Notizen hinterließ, und fragten sich, was daran beispielsweise anders als bei Slack sei. Uff!

Das Design alltäglicher Synchronisationen

Wenn Sie bereits Erfahrung in der Softwareentwicklung haben, sollte es Ihnen auf die Nerven gehen, sich daran zu erinnern, dass die meisten Menschen nicht einfach auf ein Bild der Benutzeroberfläche schauen und verstehen können, was es bei der Interaktion tun wird. Ganz zu schweigen von dem, was innerhalb des Programms geschieht. Das Wissen über das, was plötzliche Fehler verarbeiten und nützliche Details zur Fehlersuche anzeigen, wie z. B. einen Stack-Trace. Die Fehlermeldung wurde vereinfacht – es reicht aus, auf den Link zu klicken. passieren kann, ist in hohem Maße das Ergebnis des Wissens darüber, was nicht passieren kann und was nicht passieren sollte. Dafür ist es erforderlich Mentale Modelle nicht nur das, was die Software tut, sondern auch, wie die einzelnen Teile miteinander abgestimmt und kommuniziert werden.

Ein klassisches Beispiel dafür ist der Benutzer, der zwanzig Minuten lang auf spinner.gif, spekuliert, wann die Arbeit schließlich abgeschlossen sein wird. Der Entwickler würde verstehen, dass der Prozess wahrscheinlich feststeckt und dass das GIF nie vom Bildschirm verschwinden wird. Diese Animation simuliert die Ausführung der Arbeit, steht aber nicht mit ihrem Zustand in Verbindung. In solchen Fällen neigen einige Techniker dazu, die Augen zu rollen und sind erstaunt über das Ausmaß des Irrtums der Benutzer. Aber bemerkst du, wer von ihnen auf die sich drehende Uhr deutet und sagt, dass sie tatsächlich stillsteht?

Darum geht es im Wert von Echtzeit. Heutzutage werden Echtzeit-Datenbanken immer noch sehr wenig genutzt, und viele stehen ihnen skeptisch gegenüber. Die meisten solcher Datenbanken neigen aktiv zum NoSQL-Stil, weshalb in der Regel Lösungen basierend auf Mongo verwendet werden, von denen man besser vergessen sollte. Für mich bedeutet das jedoch, dass ich mit CouchDB komfortabel arbeiten kann und Strukturen lernen kann, die nicht nur von einem Bürokraten mit Daten gefüllt werden können. Ich denke, dass ich meine Zeit effektiver nutze.

Aber das eigentliche Thema dieses Beitrags ist das, was ich heute benutze. Nicht aus meiner Wahl, sondern aufgrund der gleichgültig und blind angewandten Unternehmenspolitik. Daher werde ich einen völlig ehrlichen und unvoreingenommenen Vergleich zweier eng verbundener Produkte für den Umgang mit Echtzeit-Datenbanken von Google anstellen.

In den Namen beider ist das Wort Fire enthalten. An einen erinnere ich mich mit Zuneigung. Der andere ist für mich eine andere Art von Feuer. Ich beeile mich nicht, ihre Namen zu nennen, denn sobald ich dies tue, stehen wir vor dem ersten großen Problem – den Namen.

Der erste heißt Firebase Echtzeit-Datenbank, der zweite – Firebase Cloud Firestore. Beide sind Produkte aus der Firebase-Suite von Google. Ihre APIs heißen entsprechend firebase.database(…) und firebase.firestore(…).

Dies geschah, weil Echtzeit-Datenbank seit ihrer Übernahme durch Google im Jahr 2014 einfach der Ursprung ist. Dann entschloss sich Google, ein paralleles Produkt zu schaffen, das eine Firebase Kopie von Firebase auf Basis der Big Data des Unternehmens war, und nannte es Firestore mit einer Cloud. Ich hoffe, ihr seid noch nicht verwirrt. Falls doch, macht euch keine Sorgen, ich habe diesen Teil des Artikels selbst zehnmal umgeschrieben. Denn man muss angeben

Denn es ist notwendig, anzugeben Firebase In Bezug auf Firebase, und Firestore in Bezug auf Firebase, zumindest um verstanden zu werden, vor einigen Jahren auf Stack Overflow.

Wenn es einen Preis für die schlechteste Benennung von Softwareprodukten gäbe, wäre dieser Fall sicherlich einer der Anwärter. Der Hamming-Abstand zwischen diesen Namen ist so gering, dass er selbst erfahrene Ingenieure verwirrt, deren Finger einen Namen tippen, während der Kopf an einen anderen denkt. Es sind gescheiterte Pläne, die mit den besten Absichten entwickelt wurden; sie erfüllten die Vorhersage, dass die Datenbank in Flammen aufgeht. Und ich mache damit ernst. Der Mensch, der ein solches Benennungsschema erfunden hat, war die Ursache für Blut, Schweiß und Tränen.

Pyrrhussieg

Man könnte denken, dass Firestore eine Ersatz für Firebase, sein Nachfolger der nächsten Generation, ist, aber das wäre ein Irrtum. Firestore eignet sich definitiv nicht als Ersatz für Firebase. Es scheint, als hätte jemand alles Interessante daraus entfernt und den größten Teil des Übrigen auf verschiedene Weisen verwirrend gemacht.

Ein flüchtiger Blick auf die beiden Produkte kann jedoch verwirrend sein: Es scheint, dass sie dasselbe tun, über im Wesentlichen dieselben APIs und sogar in derselben Datenbanksitzung. Die Unterschiede sind kaum bemerkbar und zeigen sich erst bei sorgfältiger vergleichender Betrachtung der umfangreichen Dokumentation. Oder wenn du versuchst, perfekt funktionierenden Firebase-Code zu portieren, damit er mit Firestore funktioniert. Schon dann stellst du fest, dass die Datenbankoberfläche aufleuchtet, sobald du versuchst, im Echtzeitmodus mit der Maus zu drag-and-drop. Ich wiederhole, ich mache damit ernst.

Der Firebase-Client ist in dem Sinne höflich, dass er Änderungen puffert und einen automatischen Wiederholungsversuch bei Aktualisierungen durchführt, wobei die letzte Schreiboperation priorisiert wird. Firestore hat jedoch eine Einschränkung von 1 Schreiboperation pro Dokument pro Benutzer pro Sekunde, und diese Einschränkung wird vom Server auferlegt. Bei der Arbeit mit ihm musst du selbst einen Weg finden, sie zu umgehen und einen Rate-Limiter für Updates zu implementieren, selbst wenn du lediglich versuchst, deine Anwendung zu erstellen. Das heißt, Firestore ist eine Echtzeitdatenbank ohne Echtzeit-Client, die sich durch die API als solche tarnt.

Hier beginnen wir, die ersten Anzeichen des Sinns der Existenz von Firestore zu erkennen. Vielleicht irre ich mich, aber ich vermute, dass jemand hoch oben in der Google-Führung nach dem Kauf von Firebase gesagt hat: „Nein, mein Gott, nein. Das ist inakzeptabel. Nur nicht unter meiner Leitung.“

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

„Ein großes JSON-Dokument? Nein. Sie werden die Daten in separate Dokumente aufteilen, von denen jedes nicht größer als 1 Megabyte sein wird.“

Es scheint, dass eine solche Einschränkung das erste Aufeinandertreffen mit einer ausreichend motivierten Benutzerbasis nicht überstehen wird. Sie wissen, dass es so ist. Bei uns auf der Arbeit gibt es zum Beispiel über anderthalbtausend Präsentationen, und das ist durchaus normal.

Mit einer solchen Einschränkung müssen Sie sich damit abfinden, dass ein „Dokument“ in der Datenbank nicht einem beliebigen Objekt ähneln wird, das der Benutzer als Dokument bezeichnen könnte.

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

Wenn Sie also gehofft haben, Ihr GeoJSON in Firestore unterzubringen, werden Sie feststellen, dass dies nicht möglich ist. Nichts Unidimensionales ist erlaubt. Ich hoffe, Sie lieben Base64 und/oder JSON innerhalb von JSON.

„JSON-Import und -Export über HTTP, Kommandozeilenwerkzeuge oder ein Administrationspanel? Nein. Sie können Daten nur in Google Cloud Storage exportieren und importieren. So, scheint es, heißt es jetzt. Und wenn ich „Sie“ sage, meine ich nur die, die die Berechtigung Projektinhaber haben. Alle anderen können gehen und Tickets erstellen.“

Wie Sie sehen, ist es einfach, das Datenmodell von Firebase zu beschreiben. Es enthält ein riesiges JSON-Dokument, das JSON-Schlüssel mit URL-Pfaden verbindet. Wenn Sie mit HTTP PUT in / Firebase folgendes schreiben:

{
  "hello": "world"
}

Dann GET /hello gibt zurück "world". Im Großen und Ganzen funktioniert es genau so, wie Sie es erwarten. Die Sammlung von Firebase-Objekten /my-collection/:id ist äquivalent zu einem JSON-Wörterbuch {"my-collection": {...}} an der Spitze, dessen Inhalt zugänglich ist über /my-collection:

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

Das funktioniert hervorragend, wenn jede Einfügung eine kollisionsfreie ID hat, wofür es in der Systematik eine Standardlösung gibt.

Mit anderen Worten, die Datenbank ist zu 100 % mit JSON (*) kompatibel und funktioniert hervorragend mit HTTP, beispielsweise mit CouchDB. In der Regel verwenden Sie sie jedoch über eine Echtzeit-API, die Websockets, Authentifizierung und Abonnements abstrahiert. Das Admin-Panel bietet beide Optionen, sowohl Echtzeitbearbeitung als auch Import/Export von JSON. Wenn Sie sich in Ihrem Code an dasselbe halten, werden Sie überrascht sein, wie viel spezialisierten Code wegfällt, wenn Sie erkennen, dass Patch und Diff in JSON 90 % der Routineaufgaben bei der Verarbeitung des dauerhaften Zustands lösen können.

Das Datenmodell von Firestore ähnelt JSON, unterscheidet sich jedoch in einigen kritischen Aspekten. Ich habe bereits das Fehlen von Arrays innerhalb von Arrays erwähnt. Das Konzept der Sub-Collections besteht darin, dass sie erstklassige Konzepte sind, die von dem sie enthaltenden JSON-Dokument getrennt sind. Da es dafür keine fertige Serialisierung gibt, ist ein spezieller Ausführungsweg für das Abrufen und Schreiben von Daten erforderlich. Um eigene Sammlungen zu bearbeiten, müssen eigene Skripte und Werkzeuge geschrieben werden. Das Admin-Panel ermöglicht es Ihnen, nur kleine Änderungen für ein Feld gleichzeitig vorzunehmen, und bietet keine Import-/Exportmöglichkeiten.

Sie haben eine Echtzeit-NoSQL-Datenbank genommen und sie in eine langsame Nicht-SQL-Datenbank mit automatischer Zusammenführung und einer separaten Spalte für Nicht-JSON verwandelt. Etwas in der Art von GraftQL.

Heißer Java

Wenn Firestore zuverlässiger und skalierbarer werden soll, ist die Ironie, dass der durchschnittliche Entwickler eine weniger zuverlässige Lösung erhält, als wenn er FireBase "out of the box" wählt. Die Software, die der Nölende Datenbankadministrator benötigt, erfordert ein solches Maß an Aufwand und Kaliber der Spezialisten, dass es einfach unrealistisch für die Nische ist, in der es guten Produkte geben sollte. Es ist vergleichbar damit, dass das HTML5-Canvas kein Ersatz für Flash ist, wenn es keine Entwicklungswerkzeuge und keinen Player gibt. Darüber hinaus ist Firestore in dem Bestreben, Daten sauber und steril zu validieren, gefangen, was einfach nicht der Realität des durchschnittlichen Geschäftsanwenders entspricht. gerne arbeitet.: für ihn ist alles optional, denn bis zum Ende ist alles ein Entwurf.

Der Hauptnachteil von FireBase besteht darin, dass der Client Jahre früher als geplant erstellt wurde, noch bevor die meisten Webentwickler von Unveränderlichkeit erfahren hatten. Daher geht FireBase davon aus, dass Sie Daten ändern werden, und nutzt daher nicht die Vorteile der vom Benutzer gewährten Unveränderlichkeit. Darüber hinaus verwendet es keine Daten, die in den an den Benutzer übermittelten Snapshots wiederverwendet werden, wodurch es viel schwieriger wird, einen Diff durchzuführen. Für große Dokumente ist sein auf veränderbaren Diffs basierender Transaktionsmechanismus einfach unangemessen. Leute, wir haben schon WeakMap in JavaScript. Das ist praktisch.

Wenn man den Daten die richtige Form gibt und die Bäume nicht zu groß macht, kann man dieses Problem umgehen. Aber ich frage mich, ob FireBase viel interessanter wäre, wenn die Entwickler eine wirklich gute Client-API herausgebracht hätten, die Unveränderlichkeit in Kombination mit ernsthaften praktischen Ratschlägen zur Datenbankstruktur nutzt. Stattdessen scheinen sie versucht zu haben, etwas zu reparieren, das nicht kaputt ist, und dadurch ist es schlimmer geworden.

Ich kenne nicht die gesamte Logik, die hinter der Erstellung von Firestore steckt. Über die Motive, die in einem schwarzen Kasten entstehen, nachzudenken, gehört ebenfalls zu dem Vergnügen. So eine Gegenüberstellung von zwei äußerst ähnlichen, aber nicht vergleichbaren Datenbanken kommt ziemlich selten vor. Es ist, als hätte jemand gedacht: „Firebase ist einfach eine Funktion, die wir in Google Cloud emulieren können“, aber gleichzeitig noch nicht das Konzept der Definition von Anforderungen aus der realen Welt oder der Schaffung nützlicher Lösungen entdeckt hat, die all diese Anforderungen erfüllen. „Lass das die Entwickler bedenken. Mach einfach das UI schön… Kann man noch mehr Feuer hinzufügen?“

Ich verstehe ein paar Dinge über Datenstrukturen. Ich sehe klar, dass das Konzept „alles in einem großen JSON-Baum“ der Versuch ist, aus der Datenbank jegliches Gefühl für großflächige Struktur zu abstrahieren. Zu erwarten, dass die Software einfach mit jedem fragwürdigen Datenstrukturfraktal zurechtkommt, ist einfach Wahnsinn. Ich muss mir nicht einmal vorstellen, wie schlecht alles sein kann; ich habe strenge Code-Audits durchgeführt und solche Dinge gesehen, von denen ihr, Leute, nicht einmal träumt.. Aber ich weiß auch, wie gute Strukturen aussehen, wie man sie verwendet und warum man das tun sollte. Ich kann mir eine Welt vorstellen, in der Firestore durchaus sinnvoll erscheint und die Menschen, die sie erschaffen haben, denken, dass sie gute Arbeit geleistet haben. Aber wir leben nicht in dieser Welt.

Die Unterstützung für das Erstellen von Abfragen in FireBase ist nach allen Maßstäben schlecht, sie existiert praktisch nicht. Sie benötigt definitiv Verbesserungen oder zumindest eine Überarbeitung. Aber Firestore ist nicht viel besser, da es durch dieselben eindimensionalen Indizes eingeschränkt ist, die in einfachem SQL vorhanden sind. Wenn Sie Abfragen benötigen, die Menschen mit chaotischen Daten durchführen, sind Volltextsuche, Filter über mehrere Bereiche und eine beliebige, benutzerdefinierte Reihenfolge erforderlich. Bei genauerer Betrachtung sind die Funktionen von einfachem SQL an sich zu begrenzt. Darüber hinaus können die einzigen SQL-Abfragen, die Menschen im Produktivbetrieb ausführen, schnelle Abfragen sein. Sie benötigen eine spezialisierte Lösung für das Indizieren mit durchdachten Datenstrukturen. Für alles andere sollte zumindest inkrementelles Map-Reduce oder etwas Ähnliches vorhanden sein.

Wenn Sie nach Informationen dazu in den Google-Dokumenten suchen, wird Ihnen hoffentlich in Richtung etwas wie BigTable und BigQuery angezeigt. Allerdings sind all diese Lösungen mit so viel dichtem Unternehmensjargon verbunden, dass Sie schnell zurückkehren und nach etwas anderem suchen werden.

Das Letzte, was Sie im Falle einer Echtzeit-Datenbank brauchen, ist etwas, das von Menschen für Menschen geschaffen wurde, die auf Gehaltsstufen für Führungskräfte arbeiten.

(*) Das ist ein Witz, es gibt kein Konzept von 100% JSON-Kompatibilität.

Als Werbung

Suchen Sie VDS nach einem Entwicklungs- und Hostingserver für Projekte? Sie sind definitiv unser Kunde 🙂 Tägliche Abrechnung für Server in den unterschiedlichsten Konfigurationen, Anti-DDoS und Windows-Lizenzen sind bereits im Preis enthalten.

Quelle: habr.com