Является ли масштабируемый снимок Firebase?

Question

Я создаю приложение для совместной работы в реальном времени. Общий размер документа может быть до 100 МБ, но в документе есть логическое разделение, которое может быть до 10+ МБ.

Лучшая аналогия - это что-то вроде Photoshop, где есть, возможно, десятки слоев изображений, но каждый слой может иметь миллионы пикселей, которые необходимо синхронизировать. Обычно пользователи меняют только часть одного слоя в моем приложении. Я хочу совместно редактировать документ такого размера. Firebase имеет приложение для рисования, но масштаб его крошечный.

В идеале я хотел бы получать события для добавления/удаления/обновления отдельных записей в коллекции, а не для возврата всей коллекции. В этом примере я хотел бы иметь возможность получать только пиксели, которые изменились.

Это единственный способ сделать это, чтобы создать уникальную коллекцию для каждой части документа? Или я делаю что-то неправильно или понимаю это неправильно? Любые хорошие архитектурные указатели/советы?

Спасибо, Brett

Answer 1

Вопрос довольно открытый конец, и вы действительно должны обеспечить некоторый код, чтобы то, что вы пытались и, возможно, Firebase структуры данных.

Это, как говорится, ответ, что да, это можно сделать; но есть проблемы для преодоления.

Если вам необходимо обновить коллаборационисты только с измененными пикселями, это будет проблемой, если вы храните 10 Мб фрагментов всего изображения.

Если пиксели 5000 и 5001 в slice_0 изменены, вам нужно будет записать весь фрагмент размером 10 Мбайт в Firebase (поскольку он хранится в одном узле), который затем уведомляет ваших соавторов через событие наблюдения, после чего они будут скачайте, что 10Mb slice (Ouch)

Это толкает много данных, потому что оно недостаточно гранулировано.

Более простым решением является разложение данных и сохранение элементов, например, строка; «Hello, World»

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

С этой структурой, если элемент element_02 изменяется, это простое обновление для всех сотрудников. Однако теперь у вас есть миллионы узлов, хранящих отдельные фрагменты данных.

Развивая эту структуру, вы должны решить, какой размер срез данных против производительности против масштабируемости будет работать для вашего приложения:

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 

Теперь, если element_02 изменения, это гораздо более управляемым и гораздо меньше узлов в и узел легко расположен, так как каждый хранит 3 значения, и вы знаете, какие значения они находятся через начало и конец.

Существуют десятки других структур, которые будут работать: например: устранить начальные и конечные дочерние узлы и вычислить имя узла с помощью уравнения, чтобы получить тот, который вы хотите. Например; node_name = int (pixel_ #/3), поэтому символ 3 (l) будет element_01 через 3/3 = 01.

Мы не знаем объем приложения, поэтому я бы предложил взять файл 100 Мб, вверх по некоторому коду и структуре Firebase и дать ему вихрь.

Вы можете попробовать нарезать кусочки 1Mb (так было бы 100 из них) и посмотреть, как производительность и настроить оттуда.