具有地理空间/地理哈希搜索的firebase中的分层数据结构；我做得对吗？

Question

意图：

创建一个航空摄影目录。记录将由AngularJS窗体创建，但由地图查看器检索，如传单。

目标：

以多种方式检索信息:飞行、采集、ID图像和地理图像

数据结构：

Collection: {
    meta: '',
    Flights: {
        meta: '',
        Aerials: {
            meta:'',
            geopoint: [lat, lon],
            geopoly: [[x1,y1], [x2,y2], [x3,y3], [x4,y4]]
        }
    }
}

Firebase (尝试去甲基化)结构：

• /收藏品/CID
• /收集站航班/CID
• /集合图像/CID
• /航班/FID
• /图像/IID

(我参考了https://stackoverflow.com/questions/16239819/performance-of-firebase-forge-with-large-data-sets)

问题：

1. 如果有100万张图片，那么去正规化看起来是否足够？(每次飞行将有大约80张图像，每个集合将平均100个航班.(如果重要的话)
2. 我应该使用GeoHash吗?如果是这样的话，GeoHash会成为火基引用/图像/UID的“图像ID”吗？(或者应该进行另一个引用--例如:/GeoHash_Geo/)
3. 必须使用类似于此示例的 GeoHash (在大多数映射服务器上，我可以在用户当前视图的边框中传递)，服务器将返回该位置的所有项。(不知道如何使用Firebase来实现这一点。)

Answer 1

如果Collection_Flights和Collections_Images只包含If，并且总是在获取Collection/$CID的同时检索它们，则可能不需要对这些索引进行去denormalize。

这里去角色化的主要目的是使获取集合列表或抓取Collection/$CID的速度更快，而不必等待图像和飞行列表的加载。因此，同样，如果这些总是并行使用，可能会增加复杂性而没有任何好处。

从索引中引用的航班/和图片/的分割是一个很好的选择。

每幅10k的100万张图像大约是10 of的数据，这是一个重要的考虑因素。假设图像不以实时速度变化，您可能希望通过为这些映像找到一个非常便宜的存储设备(S3、CDN等)来进行优化，只将URL存储在Firebase中，而不是将它们存储为数据，并为这些庞大的静态资产的带宽和存储支付实时费率。

是否应该使用GeoHash是一个很大的话题，也是一个值得商榷的话题；正如您已经指出的那样，有很多替代方案。我认为没有人能以问答格式(可能是教科书中的一章或适当的邮件列表上的讨论主题)告诉您这个巨大的实现决策的答案。