Firebase 快照是否可扩展？

Question

我正在构建一个实时协作应用。文档总大小最大可达 100+ MB，但文档内的逻辑分区最大可达 10+ MB。

最好的比喻是 Photoshop，其中可能有数十层图像，但每一层都可能有数百万像素需要同步。用户通常只会修改我的应用程序中单个图层的一部分。我想协作编辑这样大小的文档。 Firebase 有一个绘图应用，但它的规模很小。

理想情况下，我希望接收添加/删除/更新集合中单个记录的事件，而不是取回整个集合。在此示例中，我希望能够仅接收发生变化的像素。

为每个文档创建一个唯一的集合是唯一的方法吗？还是我做错了什么或理解错了？有什么好的架构指针/建议吗？

谢谢， 布雷特

Answer 1

这个问题非常开放，你应该提供一些关于你尝试过的代码，也许还有一个 Firebase 数据结构。

话虽如此，答案是肯定的，可以做到；但有一些问题需要克服。

如果您的要求是仅使用已更改的像素更新协作者，那么如果您要存储整个图像的 10Mb 切片，这将是一个挑战。

如果 slice_0 中的像素 5000 和 5001 发生更改，您需要将整个 10Mb 切片写出到 Firebase（因为它存储在单个节点中），然后它会通过观察事件通知您的协作者，以便他们下载那个 10Mb 切片（哎哟）

因为不够细化，所以会推送大量数据。

更简单的解决方案是分解数据并存储元素，以字符串为例； “你好，世界”

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 个值，并且您可以通过 start 和 end 知道它们是哪些值。

还有许多其他结构可以使用：例如：消除开始和结束子节点并通过等式计算节点名称以获得您想要的。例如; node_name = int(pixel_# / 3)，因此字符 3 (l) 将通过 3/3 = 01 成为 element_01。

我们不知道应用程序的范围，所以我建议使用 100Mb 文件，编写一些代码和 Firebase 结构，然后试一试。

您可以尝试切片为 1Mb 切片（因此会有 100 个切片），然后查看性能如何并从那里进行调整。