数据库设计 – 具有快速(<1s)读取查询性能的大型(> 22万亿项)地理空间数据集

前端之家收集整理的这篇文章主要介绍了数据库设计 – 具有快速(<1s)读取查询性能的大型(> 22万亿项)地理空间数据集前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我正在为大型地理空间数据集设计新系统,这需要快速的读取查询性能.因此,我想看看是否有人认为有可能或者有关于合适的DBMS,数据结构或替代方法的经验/建议,以便在以下情况下达到所需的性能

将从已处理的卫星雷达数据中不断产生数据,这些数据将具有全球覆盖范围.根据全球的卫星分辨率和土地覆盖率,我估计完整的数据集可以产生全球750亿个不同位置的数值.在单个卫星的寿命期间,输出将在这些位置中的每一个处产生多达300个值(因此总数据集> 22万亿个值).这是针对一颗卫星,并且已经有第二颗卫星,在新的几年内计划另外两颗.所以会有很多数据!单个数据项非常简单,仅包含(经度,纬度,值),但由于项目数量的原因,我估计单个卫星可以产生高达100TB的数据.

书面数据永远不需要更新,因为只有在处理新的卫星采集时才会增加.写入性能并不重要,但读取性能至关重要.该项目的目标是能够通过简单的界面(例如谷歌地图上的图层)可视化数据,其中每个点都具有基于其平均值,渐变或某些功能彩色值. (在帖子结尾演示).

根据这些要求,数据库需要具有可扩展性,我们可能会关注云解决方案.系统需要能够处理地理空间查询,例如“靠近(lat,lon)的点”和“(Box)内的点”,并且具有< 1s用于定位单个点,多边形包含多达50,000个点(尽管最多可达200​​,000个点). 到目前为止,我在1.11亿个位置拥有大约7.5亿个数据项的测试数据集.我已经试过了一个postgres / postGIS实例,它运行正常,但没有分片的可能性,我不这样做,这将能够应对数据增长.我还试用了一个mongoDB实例,这似乎也好了所以远,并且通过分片,可能足以与数据量一起扩展.我最近学到了一些关于elasticsearch的知识,所以对此有任何意见都会对我有所帮助. 这是我们想要使用完整数据集实现的快速动画:

这个gif(来自我的postgres试用版)提供(6×3)预先计算的光栅图块,每个图块包含~200,000个点,每个点生成约17秒.点击一个点,通过拉出<中最近的位置的所有历史值来制作图表. 1秒. 对于长篇大论道歉,欢迎提出所有意见/建议.

解决方法

你可以按位置分片.将地球划分为网格,并将该网格中的每个正方形放在一台服务器上.既然你提到了云,那就非常适合云.当然,您需要手动合并来自多个服务器的结果.

这样你可以使用任何类似的数据库解决方案.它不需要自行扩展.

各个方块将具有不同数量的数据.您可以为它们使用不同大小的计算机(因为这是云),或者在同一台计算机上放置多个小碎片.

这种分片方案非常适合您执行的查询,因为每个查询只需要触摸很少的分片.时间分片更糟糕,因为每次查询都必须触及所有时间分片.随机分片具有相同的问题.

总而言之,这是一个简单的分片情况,因为查询模式非常适合分片方案.

实际上,我想知道你是否需要一个数据库.也许你可以将地球划分为1000×1000或更小的地块,并在每个地块的blob存储中有一个平面文件. Blob存储根本不介意1M blob.

使用此存储方案,在概念上执行查询非常容易.您也可以将数据冗余存储在多个网格分辨率中.

猜你在找的MsSQL相关文章