Diese Datenbank brennt ...

Lassen Sie mich eine technische Geschichte erzählen.

Vor vielen Jahren habe ich eine Anwendung mit integrierten Funktionen für die Zusammenarbeit entwickelt. Es handelte sich um einen benutzerfreundlichen experimentellen Stack, der das volle Potenzial von Early React und CouchDB nutzte. Es synchronisierte Daten in Echtzeit über JSON OT. Es wurde unternehmensintern genutzt, seine breite Anwendbarkeit und sein Potenzial in anderen Bereichen waren jedoch klar.

Als wir versuchten, diese Technologie an potenzielle Kunden zu verkaufen, stießen wir auf ein unerwartetes Hindernis. Im Demovideo sah unsere Technologie großartig aus und funktionierte großartig, es gab keine Probleme. Das Video zeigte genau, wie es funktioniert und ahmte nichts nach. Wir haben ein realistisches Szenario für die Verwendung des Programms entwickelt und codiert.


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

Obwohl jeder wusste, wozu die Schaltfläche „Aktualisieren“ diente, verstand niemand wirklich, dass die Webanwendungen, mit deren Erstellung wir beauftragt wurden, normalerweise ihren eigenen Einschränkungen unterliegen. Und wenn sie nicht mehr benötigt werden, wird das Benutzererlebnis völlig anders sein. Sie bemerkten vor allem, dass sie „chatten“ konnten, indem sie Notizen für die Personen hinterließen, mit denen sie sprachen, und fragten sich daher, was der Unterschied beispielsweise zu Slack sei. Puh!

Gestaltung alltäglicher Synchronisierungen

Wenn Sie Erfahrung in der Softwareentwicklung haben, muss es nervenaufreibend sein, sich daran zu erinnern, dass die meisten Menschen nicht einfach ein Bild einer Schnittstelle betrachten und verstehen können, was sie tut, wenn sie damit interagieren. Ganz zu schweigen davon, was im Programm selbst passiert. Wissen Sie, dass können Was passieren kann, ist größtenteils das Ergebnis des Wissens, was nicht passieren kann und was nicht passieren sollte. Dafür braucht man mentales Modell nicht nur, was die Software macht, sondern auch, wie ihre einzelnen Teile koordiniert sind und miteinander kommunizieren.

Ein klassisches Beispiel hierfür ist ein Benutzer, der auf a starrt Spinner.gif, frage mich, wann die Arbeiten endlich abgeschlossen sein werden. Der Entwickler hätte erkannt, dass der Prozess wahrscheinlich hängen geblieben ist und das GIF niemals vom Bildschirm verschwinden würde. Diese Animation simuliert die Ausführung eines Jobs, hat jedoch keinen Bezug zu dessen Zustand. In solchen Fällen verdrehen einige Technikfreaks gerne die Augen und sind erstaunt über das Ausmaß der Verwirrung der Benutzer. Beachten Sie jedoch, wie viele von ihnen auf die rotierende Uhr zeigen und sagen, dass sie tatsächlich stationär ist?

Dies ist die Essenz des Echtzeitwerts. Heutzutage werden Echtzeitdatenbanken noch kaum genutzt und von vielen Menschen mit Argwohn betrachtet. Die meisten dieser Datenbanken orientieren sich stark am NoSQL-Stil, weshalb sie meist Mongo-basierte Lösungen verwenden, die man am besten vergisst. Für mich bedeutet das jedoch, sich mit CouchDB vertraut zu machen und zu lernen, Strukturen zu entwerfen, die mehr als nur ein Bürokrat mit Daten füllen kann. Ich glaube, ich nutze meine Zeit besser.

Aber das eigentliche Thema dieses Beitrags ist das, was ich heute verwende. Nicht freiwillig, sondern aufgrund gleichgültig und blind angewandter Unternehmensrichtlinien. Deshalb werde ich einen völlig fairen und unvoreingenommenen Vergleich zweier eng verwandter Google-Echtzeitdatenbankprodukte anbieten.

Beide tragen das Wort Feuer im Namen. An eine Sache erinnere ich mich gern. Das Zweite ist für mich eine andere Art von Feuer. Ich habe es nicht eilig, ihre Namen zu nennen, denn wenn ich das tue, werden wir auf das erste große Problem stoßen: Namen.

Der erste heißt Firebase-Echtzeitdatenbank, und zweitens - Firebase Cloud Firestore. Bei beiden handelt es sich um Produkte von Firebase-Suite Google. Ihre APIs werden jeweils aufgerufen firebase.database(…) и firebase.firestore(…).

Dies geschah, weil Echtzeitdatenbank - Es ist nur das Original Firebase vor dem Kauf durch Google im Jahr 2014. Dann beschloss Google, ein Parallelprodukt zu erstellen kopieren Firebase basiert auf einem Big-Data-Unternehmen und nennt es Firestore mit einer Cloud. Ich hoffe, Sie sind noch nicht verwirrt. Wenn Sie immer noch verwirrt sind, machen Sie sich keine Sorgen, ich selbst habe diesen Teil des Artikels zehnmal umgeschrieben.

Weil Sie angeben müssen Firebase in der Firebase-Frage und Feuerladen in einer Frage zu Firebase, zumindest um es Ihnen vor ein paar Jahren auf Stack Overflow verständlich zu machen.

Wenn es eine Auszeichnung für das schlechteste Software-Benennungserlebnis gäbe, wäre dies definitiv einer der Kandidaten. Der Hamming-Abstand zwischen diesen Namen ist so gering, dass er selbst erfahrene Ingenieure verwirrt, deren Finger einen Namen tippen, während ihr Kopf über einen anderen nachdenkt. Das sind gut gemeinte Pläne, die kläglich scheitern; Sie erfüllten die Prophezeiung, dass die Datenbank in Flammen stehen würde. Und ich mache überhaupt keine Witze. Die Person, die sich dieses Namensschema ausgedacht hat, verursachte Blut, Schweiß und Tränen.

Pyrrhussieg

Man könnte meinen, dass Firestore es ist замена Firebase, sein Nachkomme der nächsten Generation, aber das wäre irreführend. Es kann nicht garantiert werden, dass Firestore ein geeigneter Ersatz für Firebase ist. Es sieht so aus, als hätte jemand alles Interessante daraus herausgeschnitten und den Rest auf verschiedene Weise verwirrt.

Ein kurzer Blick auf die beiden Produkte könnte Sie jedoch verwirren: Sie scheinen dasselbe zu tun, über grundsätzlich dieselben APIs und sogar in derselben Datenbanksitzung. Die Unterschiede sind subtil und werden nur durch sorgfältige vergleichende Untersuchung umfangreicher Dokumentation deutlich. Oder wenn Sie versuchen, Code zu portieren, der perfekt auf Firebase funktioniert, damit er mit Firestore funktioniert. Selbst dann stellen Sie fest, dass die Datenbankoberfläche aufleuchtet, sobald Sie versuchen, in Echtzeit per Drag & Drop mit der Maus zu ziehen. Ich wiederhole, ich mache keine Witze.

Der Firebase-Client ist in dem Sinne höflich, dass er Änderungen puffert und automatisch Aktualisierungen wiederholt, die dem letzten Schreibvorgang Priorität einräumen. Allerdings gibt es in Firestore ein Limit von 1 Schreibvorgang pro Dokument, pro Benutzer und Sekunde, und dieses Limit wird vom Server durchgesetzt. Wenn Sie damit arbeiten, liegt es an Ihnen, einen Weg zu finden, dies zu umgehen und eine Begrenzung der Aktualisierungsrate zu implementieren, selbst wenn Sie gerade versuchen, Ihre Anwendung zu erstellen. Das heißt, Firestore ist eine Echtzeitdatenbank ohne Echtzeit-Client, die sich über eine API als solche ausgibt.

Hier beginnen wir, die ersten Anzeichen der Daseinsberechtigung von Firestore zu erkennen. Vielleicht irre ich mich, aber ich vermute, dass jemand hoch oben im Google-Management nach dem Kauf auf Firebase geschaut und einfach gesagt hat: „Nein, oh mein Gott, nein.“ Das ist inakzeptabel. Nur nicht unter meiner Führung.“

Er erschien aus seinen Gemächern und erklärte:

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

Es scheint, dass eine solche Einschränkung die erste Begegnung mit einer ausreichend motivierten Benutzerbasis nicht überstehen wird. Du weißt, dass es so ist. Bei der Arbeit haben wir zum Beispiel mehr als eineinhalbtausend Präsentationen, und das ist völlig normal.

Mit dieser Einschränkung müssen Sie die Tatsache akzeptieren, dass ein „Dokument“ in der Datenbank keinem Objekt ähnelt, das ein Benutzer als Dokument bezeichnen könnte.

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

Wenn Sie also gehofft haben, GeoJSON in Ihren Firestore zu integrieren, werden Sie feststellen, dass dies nicht möglich ist. Nichts Nicht-Eindimensionales ist akzeptabel. Ich hoffe, Ihnen gefällt Base64 und/oder JSON innerhalb von JSON.

„JSON-Import und -Export über HTTP, Befehlszeilentools oder Admin-Panel? Nein. Sie können Daten nur in Google Cloud Storage exportieren und importieren. So heißt es jetzt, glaube ich. Und wenn ich „Sie“ sage, spreche ich nur diejenigen an, die über die Qualifikation als Projektinhaber verfügen. Alle anderen können hingehen und Tickets erstellen.“

Wie Sie sehen, 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 mit schreiben HTTP PUT в / FireBase ist Folgendes:

{
  "hello": "world"
}

die GET /hello wird zurückkehren "world". Im Grunde funktioniert es genau so, wie man es erwarten würde. Sammlung von FireBase-Objekten /my-collection/:id entspricht einem JSON-Wörterbuch {"my-collection": {...}} im Stammverzeichnis, dessen Inhalt in verfügbar ist /my-collection:

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

Dies funktioniert gut, wenn jede Einfügung eine kollisionsfreie ID hat, wofür das System eine Standardlösung hat.

Mit anderen Worten: Die Datenbank ist zu 100 % JSON(*)-kompatibel und funktioniert hervorragend mit HTTP, wie z. B. CouchDB. Aber im Grunde verwenden Sie es über eine Echtzeit-API, die Websockets, Autorisierung 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 das Gleiche in Ihrem Code tun, werden Sie überrascht sein, wie viel spezialisierter Code verschwendet wird, wenn Sie feststellen, dass Patch und Diff JSON 90 % der Routineaufgaben im Umgang mit persistenten Zuständen lösen.

Das Firestore-Datenmodell ähnelt JSON, unterscheidet sich jedoch in einigen entscheidenden Punkten. Das Fehlen von Arrays innerhalb von Arrays habe ich bereits erwähnt. Das Modell für Untersammlungen sieht vor, dass es sich dabei um erstklassige Konzepte handelt, getrennt von dem JSON-Dokument, das sie enthält. Da es hierfür keine vorgefertigte Serialisierung gibt, ist zum Abrufen und Schreiben von Daten ein spezieller Codepfad erforderlich. Um Ihre eigenen Sammlungen zu verarbeiten, müssen Sie Ihre eigenen Skripte und Tools schreiben. Im Admin-Bereich können Sie jeweils nur kleine Änderungen an einem Feld vornehmen und verfügen nicht über Import-/Exportfunktionen.

Sie nahmen eine Echtzeit-NoSQL-Datenbank und wandelten sie in eine langsame Nicht-SQL-Datenbank mit automatischem Join und einer separaten Nicht-JSON-Spalte um. So etwas wie GraftQL.

Heißes Java

Wenn Firestore zuverlässiger und skalierbarer sein sollte, dann liegt die Ironie darin, dass der durchschnittliche Entwickler am Ende eine weniger zuverlässige Lösung erhält, als wenn er sich sofort für FireBase entscheidet. Die Art von Software, die der mürrische Datenbankadministrator benötigt, erfordert ein Maß an Aufwand und Talent, das für die Nische, in der das Produkt gut sein soll, einfach unrealistisch ist. Dies ähnelt der Tatsache, dass HTML5 Canvas überhaupt kein Ersatz für Flash ist, wenn keine Entwicklungstools und kein Player vorhanden sind. Darüber hinaus verspürt Firestore den Wunsch nach Datenreinheit und steriler Validierung, der einfach nicht mit den Gewohnheiten eines durchschnittlichen Geschäftsanwenders übereinstimmt liebt es zu arbeiten: Für ihn ist alles optional, denn bis zum Schluss ist alles ein Entwurf.

Der Hauptnachteil von FireBase besteht darin, dass der Client seiner Zeit mehrere Jahre voraus war, bevor die meisten Webentwickler etwas über Unveränderlichkeit wussten. Aus diesem Grund geht FireBase davon aus, dass Sie die Daten ändern und nutzt daher nicht die vom Benutzer bereitgestellte Unveränderlichkeit. Darüber hinaus werden die Daten in den Snapshots, die an den Benutzer übergeben werden, nicht wiederverwendet, was die Differenz erheblich erschwert. Für große Dokumente ist der veränderbare Diff-basierte Transaktionsmechanismus einfach unzureichend. Leute, das haben wir schon WeakMap in JavaScript. Das ist bequem.

Wenn Sie den Daten die gewünschte Form geben und die Bäume nicht zu voluminös machen, kann dieses Problem umgangen werden. Aber ich bin gespannt, ob FireBase viel interessanter wäre, wenn die Entwickler eine wirklich gute Client-API veröffentlichen würden, die Unveränderlichkeit kombiniert mit einigen ernsthaften praktischen Ratschlägen zum Datenbankdesign. Stattdessen schienen sie zu versuchen, das zu reparieren, was nicht kaputt war, und das machte es noch schlimmer.

Ich kenne nicht die ganze Logik hinter der Gründung von Firestore. Auch das Spekulieren über die Motive, die in der Black Box entstehen, gehört zum Spaß dazu. Dieses Nebeneinander zweier äußerst ähnlicher, aber unvergleichlicher Datenbanken ist recht selten. Als ob jemand gedacht hätte: „Firebase ist nur eine Funktion, die wir in Google Cloud emulieren können“, hat aber noch nicht das Konzept entdeckt, reale Anforderungen zu identifizieren oder nützliche Lösungen zu entwickeln, die alle diese Anforderungen erfüllen. „Lassen Sie die Entwickler darüber nachdenken. Machen Sie einfach die Benutzeroberfläche schön ... Können Sie mehr Feuer hinzufügen?“

Ich verstehe ein paar Dinge über Datenstrukturen. Ich sehe das Konzept „Alles in einem großen JSON-Baum“ definitiv als einen Versuch, jegliches Gefühl einer großräumigen Struktur aus der Datenbank zu abstrahieren. Von einer Software zu erwarten, dass sie mit jedem fragwürdigen Datenstruktur-Fraktal einfach zurechtkommt, ist einfach verrückt. Ich muss mir nicht einmal vorstellen, wie schlimm die Dinge sein könnten, ich habe strenge Code-Audits durchgeführt und Ich habe Dinge gesehen, von denen ihr nie geträumt habt. Aber ich weiß auch, wie gute Strukturen aussehen, wie man sie benutzt и warum sollte das gemacht werden. Ich kann mir eine Welt vorstellen, in der Firestore logisch erscheint und die Leute, die es erstellt haben, denken würden, dass sie gute Arbeit geleistet haben. Aber wir leben nicht in dieser Welt.

Die Abfrageunterstützung von FireBase ist in jeder Hinsicht dürftig und praktisch nicht vorhanden. Es bedarf definitiv einer Verbesserung oder zumindest einer Überarbeitung. Aber Firestore ist nicht viel besser, da es auf dieselben eindimensionalen Indizes beschränkt ist, die auch in einfachem SQL zu finden sind. Wenn Sie Abfragen benötigen, die Menschen auf chaotischen Daten ausführen, benötigen Sie eine Volltextsuche, Mehrbereichsfilter und eine benutzerdefinierte benutzerdefinierte Reihenfolge. Bei näherer Betrachtung sind die Funktionen von reinem SQL zu eingeschränkt. Darüber hinaus sind die einzigen SQL-Abfragen, die Menschen in der Produktion ausführen können, schnelle Abfragen. Sie benötigen eine individuelle Indexierungslösung mit durchdachten Datenstrukturen. Für alles andere sollte es zumindest eine inkrementelle Kartenreduzierung oder ähnliches geben.

Wenn Sie Google Docs nach Informationen hierzu durchsuchen, werden Sie hoffentlich auf etwas wie BigTable und BigQuery verwiesen. Allerdings sind all diese Lösungen mit einem derart dichten Firmen-Verkaufsjargon verbunden, dass Sie schnell umkehren und nach etwas anderem suchen werden.

Das Letzte, was Sie von einer Echtzeitdatenbank wollen, ist etwas, das von und für Leute auf der Gehaltsskala des Managements gemacht wurde.

(*) Das ist ein Witz, so etwas gibt es nicht 100 % JSON-kompatibel.

Über die Rechte der Werbung

Auf der Suche nach VDS zum Debuggen von Projekten, ein Server für Entwicklung und Hosting? Sie sind auf jeden Fall unser Kunde 🙂 Tagespreise für Server verschiedener Konfigurationen, Anti-DDoS- und Windows-Lizenzen sind bereits im Preis enthalten.

Source: habr.com