Firebase Datenbank – die "Fan Out" Technik

Ich habe das FirebaseDatenbank– Beispiel für Android untersucht und erkannt, dass es seine Daten auf folgende Weise speichert:

Bildbeschreibung hier eingeben

  • Reparieren Sie eine Ansicht in Android - bewegen Sie von einem Layout in ein anderes
  • Platz zwischen gestapelten TextViews entfernen
  • Android - Capture-Bildschirm des Telefons als Film
  • VoIP-Bibliothek für Android
  • Datei hochladen in WebView
  • Ist es möglich, Android SDK Methoden mit @hide Annotation verwenden?
  • Ich bin nicht ganz vertraut mit NoSQL-Techniken und versuche zu verstehen, warum wir jede user_posts zweimal anhalten müssen – bei posts und user_posts entsprechend. Die Dokumentation sagt, dass dieser Ansatz "Fan Out" genannt wird und ich bin mir vollkommen einig, dass es sinnvoll sein könnte, auf die Beiträge des Nutzers zuzugreifen, und zwar durch einfache Konstruktion wie databaseReference.child("user-posts").child("<user_uid>") . Aber warum brauchen wir dann den posts ? Was ist, wenn wir irgendwelche Post aktualisieren müssen – müssen wir es zweimal machen?

     // [START write_fan_out] private void writeNewPost(String userId, String username, String title, String body) { // Create new post at /user-posts/$userid/$postid and at // /posts/$postid simultaneously String key = mDatabase.child("posts").push().getKey(); Post post = new Post(userId, username, title, body); Map<String, Object> postValues = post.toMap(); Map<String, Object> childUpdates = new HashMap<>(); childUpdates.put("/posts/" + key, postValues); childUpdates.put("/user-posts/" + userId + "/" + key, postValues); mDatabase.updateChildren(childUpdates); } // [END write_fan_out] 

    Also frage ich mich … wenn dieser Ansatz nützlich sein könnte und wann nicht? Hat Firebase SDK alle Werkzeuge, um alle Duplikate synchron zu halten, wenn Sie Daten aktualisieren oder entfernen?


    UPDATE: Hier ist die Erklärung von Firebase Team:

    Der Grund, warum die Beiträge vervielfältigt werden, ist, weil wir in der Lage sein werden, schnell alle Beiträge zu einem Benutzer (wie Sie vorgeschlagen) und Filterung aus der Liste aller Beiträge jemals, um die Beiträge von einem Benutzer bekommen kann ziemlich teuer wie die Anzahl der Stellen erweitert.

    Das bedeutet, dass wir den Beitrag an zwei Standorten aktualisieren müssen, sobald wir es aktualisieren. Es macht den Code ein wenig hässlicher, aber da Abfragen häufiger sind als schreibt, ist es besser, für das Lesen der Daten zu optimieren.

    Ich vermute, dass dieser Ansatz nicht ganz elegant aussehen könnte, aber es ist wahrscheinlich die schnellste Option für große Datensätze, solange Sie SELECT öfter als UPDATE ausführen. Allerdings würde ich für einige Fälle lieber auf andere Lösungen hinweisen, die hier empfohlen werden.

  • Wenn ich ein Fragment in einem XML-Layout deklariere, wie gebe ich ihm ein Bundle?
  • Wie kann ich bei einer von einem SearchView / Widget aufgerufenen Suche zusätzliche Variablen übergeben?
  • Erkennen von mehreren Keywords mit PocketSphinx
  • Android als SIP zum GSM-Gateway
  • Wie kann man die ViewPager-Seite auf eine pro Geste beschränken
  • Android in App-Abrechnung Kaufprüfung fehlgeschlagen
  • 2 Solutions collect form web for “Firebase Datenbank – die "Fan Out" Technik”

    Data Fan Out ist eine großartige Technik, um massive Datenmengen zu verwalten. Wenn du dieses Muster nicht benutzt hast, könntest du in Zukunft ernsthafte Skalierungsprobleme haben.

    Was ich aus deiner Datenbankstruktur sehe, ist, dass du die ganze Postinformation zweimal speicherst, und das ist keine gute Praxis. Sie wollen nur einen Verweis auf den Beitrag unter einem anderen Knoten stattdessen speichern. So haben Sie einen Knoten namens users-posts die aus Benutzerschlüsseln bestehen, und jeder dieser Schlüssel wird eine Reihe von Posts-Schlüsseln mit dem Wert von true . Um es klarer zu machen:

    Bildbeschreibung hier eingeben

    Auf diese Weise verfolgst du, welche Beiträge der Benutzer unter dem users-posts Knoten geschrieben hat. Und auch der Benutzer, der jeden Beitrag unter dem posts . Jetzt müssen Sie möglicherweise eine Liste aller Benutzerposten erhalten. Was Sie tun müssen, ist, auf den users-posts/USER_KEY/ Knoten zu synchronisieren, um die Schlüssel für alle Beiträge zu erhalten, die der Benutzer geschrieben hat, und dann mehr Post-Informationen mit der Post-Taste, die Sie gerade bekommen haben .

    Warum wird dieses Datenbankdesign empfohlen? Weil du für jede Synchronisation viel weniger Informationen bekommst (mit Firebase stellen wir keine Anfragen per-se aus, also nenne ich das Lesen einer Synchronisation). In deinem Beispiel, wenn du einen Hörer an die user-posts/USER_KEY/ , um eine Liste aller Beiträge zu erhalten, wirst du auch nach all den Informationen von JEDEM UND JEDEM Post, den sie geschrieben haben, Mit dem Daten-Fan-Out-Ansatz können Sie nur für die Post-Informationen, die Sie benötigen, weil Sie bereits den Schlüssel der Beiträge haben.

    Meiner Meinung nach ist dies nicht ein guter Ansatz, da müssen Sie in Synchronisierung dieser Daten zu halten und Firebase bietet kein Werkzeug, um Duplikate synchron zu halten. Ein guter Ansatz wäre, nur den Schlüssel in user-posts zu speichern.

    Ich schlage vor, dies zu lesen, es ist sehr interessant zu verstehen, wie man Daten strukturiert: https://www.firebase.com/docs/web/guide/structuring-data.html

    Das Android ist ein Google Android Fan-Website, Alles ├╝ber Android Phones, Android Wear, Android Dev und Android Spiele Apps und so weiter.