Ist Firebase-Snapshot skalierbar?

Question

Ich baue eine Echtzeit-Collaboration-App. Die Gesamtgröße des Dokuments kann bis zu 100 + MB betragen. Es gibt jedoch eine logische Unterteilung innerhalb des Dokuments, die bis zu 10 MB betragen kann.

Die beste Analogie ist etwas wie Photoshop, wo es vielleicht Dutzende von Bildern gibt, aber jede Ebene kann Millionen von Pixeln haben, die synchronisiert werden müssen. Benutzer würden im Allgemeinen nur einen Teil einer einzelnen Ebene in meiner App ändern. Ich möchte ein Dokument dieser Größe gemeinsam bearbeiten. Firebase hat eine Zeichnungs-App, aber die Größe ist winzig.

Idealerweise würde ich gerne Ereignisse zum Hinzufügen/Löschen/Aktualisieren einzelner Datensätze in einer Sammlung erhalten, anstatt die gesamte Sammlung zurückzuerhalten. In diesem Beispiel möchte ich nur die Pixel erhalten, die sich geändert haben.

Ist die einzige Möglichkeit, um eine einzigartige Sammlung für jedes Teil des Dokuments zu erstellen? Oder mache ich etwas falsch oder verstehe es falsch? Irgendwelche guten architektonischen Hinweise/Ratschläge?

Danke, Brett

Answer 1

Die Frage endet ziemlich offen ist, und Sie sollten wirklich einen Code liefern, was Sie versucht haben, und vielleicht eine Firebase Datenstruktur.

Das gesagt, die Antwort ist, dass ja, es kann getan werden; Aber es gibt Probleme zu überwinden.

Wenn Ihre Anforderung darin besteht, Mitarbeiter nur mit den Pixeln zu aktualisieren, die sich geändert haben, ist das eine Herausforderung, wenn Sie 10 MB-Segmente des gesamten Bildes speichern.

Wenn die Pixel 5000 und 5001 in slice_0 geändert werden, müssen Sie den gesamten 10Mb Slice an Firebase schreiben (da er in einem einzigen Knoten gespeichert ist), der Ihre Mitarbeiter dann über ein Beobachtungsereignis benachrichtigen würde herunterladen, dass 10Mb Scheibe (Autsch)

Das ist drängen um eine Menge Daten, weil es nicht granuliert genug ist.

Eine einfachere Lösung besteht darin, die Daten zu zerlegen und die Elemente zu speichern, z. B. eine Zeichenfolge; "Hallo, Welt"

my_string 
    element_00: "H" 
    element_01: "e" 
    element_02: "l" 
    ... 
    element_11: "d" 

Mit dieser Struktur, wenn element_02 sich ändert, ist es ein einfaches Update für alle Mitarbeiter. Sie haben jetzt jedoch Millionen von Knoten, die einzelne Datenelemente speichern.

Aufbauend auf dieser Struktur würden Sie entscheiden müssen, welche Größe Scheibe von Daten vs Leistung vs Skalierbarkeit würde für Ihre Anwendung arbeiten:

my_string 
    element_00 
     data: "Hel" 
     start: 0 
     end: 2 
    element_01: 
     data: "lo," 
     start: 3 
     end: 5 
    element_02 
     data: " Wo" 
     start: 6 
     end: 8 
    element_03 
     data: "old" 
     start: 9 
     end: 11 

Nun, wenn element_02 Änderungen, es ist viel mehr überschaubar und weit weniger Knoten Deal mit und der Knoten ist leicht zu finden, wie jeder 3 Werte speichert und Sie wissen, welche Werte sie über Start und Ende sind.

Es gibt Dutzende anderer Strukturen, die funktionieren würden: Zum Beispiel: Eliminiere die Anfangs- und End-Kindknoten und berechne den Knotennamen über eine Gleichung, um die gewünschte zu erhalten. Beispielsweise; knotenname = int (pixel_ #/3), also zeichen 3 (l) wäre element_01 über 3/3 = 01.

Wir kennen nicht den Umfang der App, also würde ich vorschlagen, eine 100Mb-Datei, Handwerk etwas Code und eine Firebase-Struktur und geben Sie einen Wirbel.

Sie können versuchen, in 1 MB Slices (so würde es 100 von ihnen) zu schneiden und sehen, wie die Leistung ist und von dort einstellen.