具有快速（<1 秒）读取查询性能的大型（> 22 万亿项）地理空间数据集
Azw*_*wok 20 performance database-design spatial performance-tuning
我正在为需要快速读取查询性能的大型地理空间数据集设计一个新系统。因此，我想看看是否有人认为在以下情况下有可能或有关于合适的 DBMS、数据结构或替代方法来实现所需性能的经验/建议：
数据将从处理过的卫星雷达数据中不断产生，这些数据将覆盖全球。根据卫星分辨率和地球的陆地覆盖范围，我估计完整数据集可在全球 750 亿个离散位置产生值。在单颗卫星的整个生命周期内，输出将在每个位置产生多达 300 个值（因此总数据集超过 22 万亿个值）。这是针对一颗卫星，并且已经有第二颗在轨，未来几年计划再有两颗。所以会有很多数据！单个数据项非常简单，仅包含（经度、纬度、值），但由于项目的数量，我估计单个卫星最多可产生 100TB。
写入的数据永远不需要更新，因为它只会随着新卫星采集的处理而增长。写入性能并不重要，但读取性能至关重要。该项目的目标是能够通过一个简单的界面（例如谷歌地图上的图层）将数据可视化，其中每个点都有一个基于其平均值、梯度或某个时间随时间变化的函数的颜色值。（帖子末尾的演示）。
从这些需求来看，数据库需要具有可扩展性，我们很可能会转向云解决方案。系统需要能够处理地理空间查询，例如“附近的点（纬度，经度）”和“范围内的点（框）”，并且具有 < 1 秒的读取性能以定位单个点，以及包含多达50,000 点（尽管最好达到 200,000 点）。
到目前为止，我在 1.11 亿个位置拥有约 7.5 亿个数据项的测试数据集。我已经试用了一个 postgres/postGIS 实例，它工作正常，但没有分片的可能性，我不这样做，这将能够随着数据的增长而应付。我还试用了一个 mongoDB 实例，这似乎再次正常到目前为止，使用分片可能足以随数据量扩展。我最近了解了一些有关 elasticsearch 的知识，因此对此的任何评论都会有所帮助，因为它对我来说是新的。
这是我们想要用完整数据集实现的快速动画：
这个 gif（来自我的 postgres 试验）提供 (6x3) 预先计算的光栅图块，每个包含约 200,000 个点，生成每个点需要约 17 秒。通过单击一个点，通过在 < 1 秒内拉取最近位置的所有历史值来制作图表。
为长篇道歉，欢迎所有评论/建议。
您的阅读查询需要更新到什么程度？
如果地图只需要显示最近的测量值，您可以按时间对数据库进行分区。这将减少您对地图的查询负载。
对于给定点的历史，您可以通过 x 和 y 保存第二个商店以显示历史。这可以通过每晚刷新/更新来完成，因为历史数据不会改变。
然后，您可以以更粗略的分辨率预先计算平均值，以便与不同缩放级别的地图进行集成。这将减少要为大地图区域检索的点数（缩小）。更精细的分辨率将用于查询更小的区域的更大的地图。如果您真的需要加快速度，您可以将图块计算为 blob 并在您的应用程序中解释它们。
因为这些会涉及一些聚合信息的重新计算，所以查询结果会有一些延迟。根据可接受的延迟程度，您可以使用这种方法来优化读取。
好的，所以你的点需要计算一段时间的平均值。通过这种计算，我猜您的实际查询从 22 万亿项中下降了很多，因为可以预先计算栅格值以进行查询。
您可以按位置分片。将地球划分为一个网格，并将该网格中的每个方块放置在一台服务器上。既然你提到了云，那将非常适合云。当然，您需要手动合并来自多个服务器的结果。
这样您就可以使用您喜欢的任何数据库解决方案。它本身不需要可扩展。
各个方格将具有不同数量的数据。您可以为它们使用不同大小的机器（因为这是云），或者您将多个小分片放在同一台机器上。
这种分片方案非常适合您执行的查询类型，因为每个查询只需要接触很少的分片。按时间分片更糟糕，因为每个查询都必须触及所有时间分片。随机分片也有同样的问题。
总而言之，这是一个简单的分片案例，因为查询模式非常适合分片方案。
实际上，我想知道您是否完全需要一个数据库。也许您可以将地球划分为 1000x1000 或更小的图块，并在 blob 存储中为每个图块存储一个平面文件。Blob 存储根本不介意 100 万个 Blob。
使用这种存储方案，执行查询在概念上非常容易。您也可以以多种网格分辨率冗余存储数据。