具有地理空间/地理散列搜索的firebase中的分层数据结构;我这样做对吗

意图：
创建航空摄影目录。记录由AngularJS表单创建，但由类似地图查看器的传单检索。

目标：
通过多种方式检索信息：按航班、收集、按ID图像和按地理位置图像

数据结构：

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

Firebase(尝试去规范化)结构：

(我引用了这个堆栈流)

问题：

如果有100万个图像，那么反规范化看起来足够吗(每次飞行将有大约80张图像，每次收集平均将有100次飞行……如果重要的话)
我应该使用GeoHash吗？，如果是，GeoHash是否会成为firebase引用/Images/UID的"图像ID(IID)">(或者我应该做另一个参考，例如：/Images_Geo/)
我必须像这个例子一样使用GeoHash吗(在大多数映射服务器上，我可以通过用户当前视图的边界框，服务器会返回该位置的所有项目。不知道如何使用Firebase进行此操作。)

如果Collection_Flights和Collection_Images只包含id，并且如果您总是在获取Collections/$CID的同时检索它们，那么您可能不需要对这些索引进行反规范化。

此处取消规范化的主要目的是使获取Collections列表或获取Collections/$CID的速度更快，而无需等待加载图像和航班列表。因此，如果这些总是并行使用，可能会增加复杂性而没有任何好处。

从索引中引用的Flights/和Images/上的拆分是一个很好的选择。

一百万张10k的图像将是大约10GB的数据；一个重要的考虑。假设图像没有以实时速度变化，您可能希望通过为这些图像找到一个极其便宜的存储设施(S3、CDN等)并将URL存储在Firebase中来进行优化，而不是将它们存储为数据并为这些庞大的静态资产的带宽和存储支付实时费用。

是否应该使用GeoHash是一个巨大的话题，也是一个颇有争议的话题；正如你已经指出的，有很多替代方案。我认为没有人能在问答中告诉你这个巨大的实施决定的答案；一种格式(可能是教科书中的一章，也可能是适当邮件列表上的讨论主题)。

相关内容