Lassen Sie mich eine technische Geschichte erzählen.
Vor vielen Jahren entwickelte ich eine Anwendung mit integrierten Funktionen zur Zusammenarbeit. Es war ein praktischer experimenteller Stack, der das volle Potenzial von frühem React und CouchDB ausnutze. Es synchronisierte Daten in Echtzeit über JSON. . Es wurde in der internen Arbeit des Unternehmens verwendet, aber die breite Anwendbarkeit und das Potenzial in anderen Bereichen waren offensichtlich.
Als wir versuchten, diese Technologie potenziellen Kunden zu verkaufen, stießen wir auf ein unerwartetes Hindernis. In dem Demovideo sah unsere Technologie großartig aus und funktionierte einwandfrei, da gab es keine Probleme. Das Video zeigte genau, wie es funktioniert, und es war nichts simuliert. Wir hatten ein realistisches Anwendungsszenario für das Programm entwickelt und programmiert.
Das war tatsächlich das Problem. Unser Demo funktionierte genau so, wie alle anderen ihre Anwendungen simulierten. Konkret wurde die Information sofort von A nach B übertragen, selbst wenn es sich um große Mediendateien handelte. Nach dem Einloggen sah jeder Benutzer neue Einträge. Mit der Anwendung konnten verschiedene Benutzer klar an denselben Projekten zusammenarbeiten, selbst wenn die Internetverbindung in einem Dorf unterbrochen wurde. Implizit wird dies in jedem in After Effects geschnittenen Produktvideo angedeutet.
Obwohl jeder wusste, wozu die Schaltfläche "Aktualisieren" diente, verstand niemand wirklich, dass die Webanwendungen, die sie uns bitten, zu erstellen, oftmals eigenen Beschränkungen unterliegen. Und dass, wenn sie nicht mehr benötigt werden, das Benutzererlebnis völlig anders sein wird. Im Wesentlichen bemerkten sie, dass sie "chatten" konnten, indem sie den Gesprächspartnern Notizen hinterließen, weshalb sie sich fragten, was das schließlich von Slack unterscheidet. Uff!
Design alltäglicher Synchronisationen
Wenn Sie bereits Erfahrung in der Softwareentwicklung haben, wird Sie wahrscheinlich die Notwendigkeit stören, dass die meisten Menschen nicht einfach auf ein Bild der Benutzeroberfläche schauen können und verstehen, was es bei der Interaktion damit tun wird. Ganz zu schweigen davon, was innerhalb des Programms tatsächlich passiert. Das Wissen darüber, was herausfinden, ob der Benutzer Animationseffekte deaktiviert hat und auch verschiedene Animationsmöglichkeiten auf der Website deaktivieren, wie beispielsweise den Wackeleffekt bei den Schaltflächen, die zur Aufmerksamkeit geworben werden; passieren kann — ist in hohem Maße das Ergebnis des Wissens darüber, was nicht passieren kann und was nicht geschehen sollte. Dafür benötigt man nicht nur dafür, was die Software tut, sondern auch dafür, wie die einzelnen Teile miteinander koordiniert sind und miteinander kommunizieren.
Ein klassisches Beispiel dafür ist ein Benutzer, der zwanzig Minuten lang auf spinner.gif, geduldig wartet, wann die Arbeit endlich beendet ist. Ein Entwickler würde verstehen, dass der Prozess wahrscheinlich festhängt und dass das GIF niemals vom Bildschirm verschwindet. Diese Animation simuliert die Ausführung von Arbeit, hat aber nichts mit ihrem tatsächlichen Zustand zu tun. In solchen Fällen neigen einige Techniker dazu, mit den Augen zu rollen und sich über das Ausmaß der Missverständnisse der Benutzer zu wundern. Beachten Sie jedoch, wer von ihnen auf die kreisenden Stunden zeigt und sagt, dass sie tatsächlich stillstehen?
Das ist das Wesentliche des Wertes der Echtzeit. Heutzutage werden Echtzeit-Datenbanken immer noch sehr wenig genutzt, und viele stehen ihnen skeptisch gegenüber. Die meisten dieser Datenbanken tendieren stark zu NoSQL-Stilen, weshalb oft Lösungen auf Basis von Mongo verwendet werden, die man besser vergessen sollte. Für mich bedeutet das jedoch, dass ich mit CouchDB angenehm arbeiten kann und Strukturen entwerfen kann, die nicht nur von irgendeinem Bürokraten mit Daten gefüllt werden können. Ich denke, dass ich meine Zeit effizienter nutze.
Aber das eigentliche Thema dieses Beitrags ist, was ich heute benutze. Nicht aus eigener Wahl, sondern aufgrund der gleichgültig und blind angewandten Unternehmenspolitik. Daher werde ich einen vollkommen ehrlichen und objektiven Vergleich von zwei eng verwandten Produkten zur Arbeit mit Echtzeit-Datenbanken von Google anstellen.
In beiden Titeln kommt das Wort Feuer vor. Eines erinnere ich mit Zärtlichkeit. Das andere ist für mich eine andere Art von Feuer. Ich beeile mich nicht, ihre Namen zu nennen, denn sobald ich das tue, werden wir mit dem ersten großen Problem konfrontiert — den Namen.
Das erste heißt Firebase Realtime Database, das zweite — Firebase Cloud Firestore. Beide sind Produkte aus der Firebase-Suite von Google. Ihre APIs heißen entsprechend firebase.database(…) und firebase.firestore(…).
Das kam zustande, weil die Real-Time-Datenbank einfach die ursprüngliche Firebase bis zu ihrem Kauf durch Google im Jahr 2014 war. Danach entschied Google, ein paralleles Produkt zu entwickeln, das eine Kopie von Firebase basierend auf den Big Data des Unternehmens war, und nannte es Firestore with a cloud. Ich hoffe, du bist noch nicht verwirrt. Falls du doch verwirrt bist, keine Sorge, ich habe diesen Teil des Artikels selbst zehnmal umgeschrieben.
Denn man muss angeben, Firebase wenn es um Firebase geht, und Firestore in Bezug auf Firebase, zumindest um vor einigen Jahren auf Stack Overflow verstanden zu werden.
Wäre es eine Auszeichnung für die schlechteste Benennung von Softwareprodukten, wäre dieser Fall definitiv ein Anwärter. Der Hamming-Abstand zwischen diesen Namen ist so gering, dass er selbst erfahrene Ingenieure verwirrt, deren Hände einen Namen tippen, während der Kopf an einen anderen denkt. Dies sind gründlich gescheiterte Pläne, die mit den besten Absichten entwickelt wurden; sie erfüllten die Prophezeiung, dass die Datenbank in Flammen aufgehen würde. Und ich mache keinen Scherz. Die Person, die ein solches Namensschema erfunden hat, war der Grund für Blut, Schweiß und Tränen.
Pyrrhussieg
Man könnte denken, dass Firestore eine Ersatzlösung für Firebase, seinen Nachfolger der nächsten Generation, ist, aber das wäre ein Irrtum. Firestore ist garantiert nicht als Ersatz für Firebase geeignet. Es scheint, als hätte jemand alles Interessante daraus herausgeschnitten und den größten Teil des Übrigen auf verschiedene Arten verwirrt.
Ein flüchtiger Blick auf die beiden Produkte kann jedoch verwirrend sein: Es scheint, als würden sie dasselbe tun, über nahezu identical APIs und sogar in derselben Datenbanksitzung. Die Unterschiede sind kaum wahrnehmbar und zeigen sich erst bei einer gründlichen vergleichenden Analyse der umfangreichen Dokumentation. Oder wenn man versucht, perfekt funktionierenden Code von Firebase zu portieren, damit er mit Firestore funktioniert. Bereits dann stellst du fest, dass die Datenbankschnittstelle sich meldet, sobald du versuchst, in Echtzeit per Drag & Drop zu arbeiten. Ich wiederhole, ich mache keine Scherze.
Der Firebase-Client ist nett, da er Änderungen puffert und automatische Wiederholungsversuche für Aktualisierungen durchführt, wobei die letzte Schreiboperation Priorität hat. Firestore hat jedoch eine Begrenzung von 1 Schreiboperation pro Dokument und Benutzer pro Sekunde, und diese Einschränkung wird vom Server auferlegt. Wenn Sie damit arbeiten, müssen Sie selbst einen Weg finden, diese Einschränkung zu umgehen und einen Aktualisierungsratenbegrenzer zu implementieren, selbst wenn Sie nur versuchen, Ihre Anwendung zu erstellen. Das bedeutet, dass Firestore eine Echtzeitdatenbank ohne echten Echtzeit-Client ist, die sich durch die API als solcher tarnt.
Hier beginnen wir, die ersten Anzeichen für den Sinn von Firestore zu erkennen. Vielleicht irre ich mich, aber ich vermute, dass jemand hoch oben im Google-Management nach dem Kauf von Firebase darauf schaute und einfach sagte: "Nein, oh mein Gott, nein. Das ist inakzeptabel. Nur nicht unter meiner Aufsicht."
Er trat aus seinen Gemächern hervor 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 darf."
Похоже, что такое ограничение не переживёт первого столкновения с любой достаточно мотивированной базой пользователей. Вы знаете, что это так. У нас на работе, например, есть полторы с лишним тысяч презентаций, и это Совершенно Нормально.
При таком ограничении вы будете вынуждены смириться с тем фактом, что один «документ» в базе данных не будет похож ни на один объект, который пользователь мог бы назвать документом.
«Массивы массивов, которые могут рекурсивно содержать другие элементы? Нет. Массивы будут содержать только объекты или числа фиксированной длины, как задумано Господом».
Поэтому если вы надеялись поместить в свою Firestore GeoJSON, то обнаружите, что это невозможно. Недопустимо ничего неодномерного. Надеюсь, вы любите Base64 и/или JSON внутри JSON.
«Импорт и экспорт JSON по HTTP, инструменты командной строки или панель администратора? Нет. Вы сможете только экспортировать и импортировать данные в Google Cloud Storage. Так, кажется, оно сейчас называется. И когда я говорю „вы“, то обращаюсь только к тем, кто имеет полномочия Project Owner. Все остальные могут пойти и создать тикеты.»
Wie Sie sehen, ist es einfach, das FireBase-Datenmodell zu beschreiben. Es enthält ein großes 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 Grunde funktioniert es so, wie Sie es erwarten würden. Eine Sammlung von FireBase-Objekten /my-collection/:id entspricht einem JSON-Wörterbuch {"my-collection": {...}} in der Wurzel, dessen Inhalt unter /my-collection:
{
"id1": {...object},
"id2": {...object},
"id3": {...object},
// ...
}funktioniert hervorragend, vorausgesetzt, jede Einfügung hat eindeutige IDs, wofür es in der Systemlösung einen Standard gibt.
Anders ausgedrückt, die Datenbank ist zu 100 % mit JSON (*) kompatibel und funktioniert hervorragend mit HTTP, z. B. mit CouchDB. Aber im Grunde verwenden Sie es über die Echtzeit-API, die Websockets, Authentifizierung und Abonnements abstrahiert. Die Administrationsoberfläche bietet beide Möglichkeiten, sowohl Echtzeitbearbeitung als auch JSON-Import/-Export. Wenn Sie in Ihrem Code das gleiche beibehalten, werden Sie überrascht sein, wie viel spezialisierten Code entfallen kann, wenn Sie feststellen, dass Patch und Diff JSON 90 % der täglichen Aufgaben bei der Verarbeitung des permanenten Zustands lösen.
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 Unterkollektionen besteht darin, dass sie eigenständige Konzepte sind, die getrennt vom enthaltenen JSON-Dokument existieren. Da es dafür keine vorgefertigte Serialisierung gibt, ist ein spezialisierter Codeausführungspfad erforderlich, um Daten zu lesen und zu schreiben. Um eigene Sammlungen zu verarbeiten, müssen Sie Ihre eigenen Skripte und Tools schreiben. Das Administrationspanel erlaubt es Ihnen, nur kleine Änderungen an einem Feld auf einmal 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 Nicht-JSON-Spalte verwandelt. Irgendwas in der Art von GraftQL.
Hot Java
Wenn Firestore zuverlässiger und skalierbarer werden sollte, ist die Ironie, dass der durchschnittliche Entwickler eine weniger zuverlässige Lösung erhält, als wenn er FireBase „out of the box“ auswählen würde. Die Software, die der mürrische Datenbankadministrator benötigt, erfordert ein solches Maß an Aufwand und Fachkenntnis, dass dies einfach unrealistisch für das Nischenfeld ist, in dem ein gutes Produkt vermutet wird. Es ist, als ob HTML5 Canvas Flash überhaupt nicht ersetzen kann, wenn es keine Entwicklungswerkzeuge und keinen Player gibt. Darüber hinaus ist Firestore in dem Bestreben, Datenreinheit und sterile Validierung zu erreichen, so verstrickt, dass dies einfach nicht dem entspricht, wie der durchschnittliche Geschäftsnutzer arbeiten: für ihn ist alles optional, denn am Ende ist alles ein Entwurf.
Der Hauptnachteil von FireBase besteht darin, dass der Client Jahre vor seiner Zeit entwickelt wurde, noch bevor die meisten Webentwickler von Unveränderlichkeit erfuhren. Deshalb geht FireBase davon aus, dass Sie Daten ändern werden, und nutzt nicht die Vorteile der nutzerseitigen Unveränderlichkeit. Zudem verwendet es die Daten in den Benutzer-Snapshots nicht wieder, was das Diffing erheblich schwieriger macht. Für große Dokumente ist der auf veränderbaren Diffs basierende Transaktionsmechanismus einfach unzureichend. Leute, wir haben das schon WeakMap in JavaScript. Das ist praktisch.
Wenn man die Daten richtig formatiert und die Bäume nicht zu umfangreich macht, kann man dieses Problem umgehen. Aber ich frage mich, ob FireBase viel interessanter geworden wäre, wenn die Entwickler eine wirklich gute Client-API veröffentlicht hätten, die Unveränderlichkeit mit ernsthaften praktischen Ratschlägen zur Datenbankstruktur kombinieren würde. Stattdessen scheinen sie versucht zu haben, etwas zu reparieren, das nicht kaputt ist, und dadurch wird es schlechter.
Ich kenne nicht die gesamte Logik, die der Erstellung von Firestore zugrunde lag. Über die Motive nachzudenken, die innerhalb einer Black Box entstehen, ist ebenfalls Teil des Vergnügens. Eine solche Gegenüberstellung von zwei extrem ähnlichen, aber nicht vergleichbaren Datenbanken kommt ziemlich selten vor. Es ist, als ob jemand gedacht hätte: „Firebase ist einfach eine Funktion, die wir in Google Cloud emulieren können“, aber dabei noch nicht das Konzept der Anforderungen aus der realen Welt oder die Schaffung nützlicher Lösungen, die all diesen Anforderungen gerecht werden, entdeckt hat. „Lass die Entwickler darüber nachdenken. Mach einfach die Benutzeroberfläche schön... Kann man noch mehr Feuer hinzufügen?“
Ich verstehe ein paar Dinge über Datenstrukturen. Ich sehe eindeutig, dass das Konzept „alles in einem großen JSON-Baum“ der Versuch ist, aus der Datenbank jegliches Gefühl für eine groß angelegte Struktur zu abstrahieren. Zu erwarten, dass die Software mit jedem fragwürdigen Fraktal der Datenstruktur einfach fertig wird, ist einfach Wahnsinn. Ich muss mir nicht einmal vorstellen, wie schlecht alles sein könnte, ich habe strenge Code-Audits durchgeführt und habe Dinge gesehen, von denen ihr, Menschen, nicht einmal träumt.. Aber ich weiß auch, wie gute Strukturen aussehen, und Ich kann mir eine Welt vorstellen, in der Firestore durchaus logisch erscheint und die Menschen, die es entwickelt haben, denken, 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 nach jeglichem Standard schlecht, sie existiert praktisch nicht. Es bedarf definitiv einer Verbesserung oder wenigstens einer Überarbeitung. Aber Firestore ist nicht viel besser, da es durch dieselben eindimensionalen Indizes eingeschränkt ist, die es in einfachem SQL gibt. Wenn Sie Abfragen benötigen, die Menschen mit chaotischen Daten ausführen, dann erfordert es eine Volltextsuche, Filter für mehrere Bereiche und eine beliebig vom Benutzer definierbare Reihenfolge. Bei genauerer Betrachtung sind einfache SQL-Funktionen für sich genommen zu begrenzt. Darüber hinaus sind die einzigen SQL-Abfragen, die Menschen in der Produktion ausführen können, schnelle Abfragen. Sie benötigen eine spezialisierte Lösung für die Indizierung mit durchdachten Datenstrukturen. Für alles andere sollte mindestens inkrementelles Map-Reduce oder etwas Ähnliches vorhanden sein.
Wenn Sie danach in den Google-Dokumenten suchen, hoffe ich, dass Sie auf etwas wie BigTable und BigQuery hingewiesen werden. Allerdings kommen all diese Lösungen mit so viel dichtem Unternehmensjargon daher, dass Sie schnell wieder umkehren und nach etwas anderem suchen werden.
Das Letzte, was Sie bei einer Echtzeit-Datenbank brauchen, ist etwas, das von Menschen geschaffen wurde und für Menschen gedacht ist, die auf Gehaltsstufen für das Management arbeiten.
(*) Das ist ein Witz, es gibt kein Konzept für .
Im Auftrag der Werbung
Suchen Sie nach einem Server für Projektdebugging, Entwicklung und Hosting? Sie sind genau unser Kunde 🙂 Taggenaue Abrechnung für Server in verschiedenen Konfigurationen, Anti-DDoS und Windows-Lizenzen sind bereits im Preis enthalten.
Quelle: habr.com
