Firebase 快照是否可扩展？
Is Firebase snapshot scalable?
我正在构建一个实时协作应用程序。文档总大小可以达到 100+ MB，但文档中有一个逻辑分区可以达到 10+ MB。
最好的类比是 Photoshop，其中可能有数十层图像，但每一层可能有数百万像素需要同步。用户通常只会修改我的应用程序中单个图层的一部分。我想协作编辑这样大小的文档。 Firebase 有一个绘图应用程序，但它的规模很小。
理想情况下，我希望接收集合中 addition/deletion/update 个单独记录的事件，而不是取回整个集合。在此示例中，我希望能够仅接收更改的像素。
为文档的每一部分创建一个唯一的集合是唯一的方法吗？还是我做错了什么或理解错了？有什么好的架构 pointers/advice?
谢谢，
布雷特
这个问题很开放，您真的应该提供一些关于您尝试过的代码，也许还有 Firebase 数据结构。
话虽这么说，答案是肯定的，可以做到；但还有一些问题需要克服。
如果您的要求是仅使用已更改的像素来更新协作者，那么如果您要存储整个图像的 10Mb 切片，这将是一个挑战。
如果 slice_0 中的像素 5000 和 5001 发生更改，您需要将整个 10Mb 切片写入 Firebase（因为它存储在单个节点中），然后通过观察通知您的协作者事件，然后他们将下载 10Mb 切片（哎哟）
因为不够细化，所以会产生大量数据。
一个更简单的解决方案是将数据分解并存储元素，例如字符串； "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 via 3/3 = 01.
我们不知道该应用程序的范围，所以我建议使用一个 100Mb 的文件，编写一些代码和一个 Firebase 结构并试一试。
您可以尝试分割成 1Mb 的切片（这样就有 100 个），看看性能如何，然后从那里进行调整。
我正在构建一个实时协作应用程序。文档总大小可以达到 100+ MB，但文档中有一个逻辑分区可以达到 10+ MB。
最好的类比是 Photoshop，其中可能有数十层图像，但每一层可能有数百万像素需要同步。用户通常只会修改我的应用程序中单个图层的一部分。我想协作编辑这样大小的文档。 Firebase 有一个绘图应用程序，但它的规模很小。
理想情况下，我希望接收集合中 addition/deletion/update 个单独记录的事件，而不是取回整个集合。在此示例中，我希望能够仅接收更改的像素。
为文档的每一部分创建一个唯一的集合是唯一的方法吗？还是我做错了什么或理解错了？有什么好的架构 pointers/advice?
谢谢， 布雷特
这个问题很开放，您真的应该提供一些关于您尝试过的代码，也许还有 Firebase 数据结构。
话虽这么说，答案是肯定的，可以做到；但还有一些问题需要克服。
如果您的要求是仅使用已更改的像素来更新协作者，那么如果您要存储整个图像的 10Mb 切片，这将是一个挑战。
如果 slice_0 中的像素 5000 和 5001 发生更改，您需要将整个 10Mb 切片写入 Firebase（因为它存储在单个节点中），然后通过观察通知您的协作者事件，然后他们将下载 10Mb 切片（哎哟）
因为不够细化，所以会产生大量数据。
一个更简单的解决方案是将数据分解并存储元素，例如字符串； "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 via 3/3 = 01.
我们不知道该应用程序的范围，所以我建议使用一个 100Mb 的文件，编写一些代码和一个 Firebase 结构并试一试。
您可以尝试分割成 1Mb 的切片（这样就有 100 个），看看性能如何，然后从那里进行调整。