求友们帮助，大量 GPS 轨迹数据利用 MongoDB 数据库如何存储呢（SpringBoot+ MonoDB)

这也不多，我曾经在关系型里都能存到几十亿条，你这非关系型问题更不大了
有一点需要调整：查询最新位置没必要进入历史表，用缓存或者单独一个表去更新存储最新即可。

最多平均每秒 50 条，极端情况每 10 秒同时来 500 条。用 .txt 都行吧。MongoDB 随便怎么都行吧。问题是 http 协议不适合干这个吧。这个体量 http 也不是不行。

针对需求 1 ，建议搞个网关服务用于专门对接数据，可高可用设计；
数据流： http 接口-》网关服务：接收到轨迹数据简单处理-〉消息中间件（如 mq ）-》相关服务再消费入库

@opengps 感谢您的解答。你的意思是 MongoDB 一个集合存所有的设备轨迹数据嘛？如果达到几十亿条查询轨迹速度咋样，
最新位置存表里那不是要频繁更新吗

MongoDB 不是有专门存储地理空间数据的类型吗

这种数据时序数据库是不是更合适， 像 influxdb 这样的

api -> kafka -> mongodb 完事

同 6 楼，这种处理带时间标签的数据是时序数据库更合适。

1 直接用 nginx 收，打日志到本地，nginx 也可以做多台保证高可用，反正只要收到的数据都打到日志了，数据不可能丢。后面你怎么处理都随便了，日志传到 kafka ，还是直接读都行，看你们架构怎么设计了。

2 暂时没什么建议，对 mongo 不熟

恰巧做过车辆网云平台，之前采取的是 gateway -> kafka ，存储用的是 hbase ，mongodb 只存最新的数据。
hbase 用 vin+timestamp 做 rowkey 。
其他更多的细节记不太清了，六七年前做的了。

其实有如果目标定了是 MongoDB ，可以在预期量级下模拟测试下

@xwayway 涉及到你说的区域查车和当前位置直接从 mongo 查询应该就能满足，轨迹查询应该也是单台车的吧，这个时候去 hbase 查就行了。

@Allenxup 历史轨迹单独存，这张表很大，但用途非常单一，仅仅用于需要使用历史数据的场景，结构也足够简单，仅仅支持单设备特定时间查询，仅仅支持写入效率，就已经足够了
nosql 的我没写，参考下我之前关系型结构的博客： https://www.opengps.cn/Blog/View.aspx?id=284

需求 1：直接网关+分布式 api+mq+mongodb ;
需求 2：建议分三个集合吧，最新车辆基本信息及最新位置信息、历史轨迹（可以把数据定期归档主要用来撕逼）、轨迹数据。至于三个需求：
第一个看轨迹数据具体需求是否需要筛选你这么多数据加载到前端也不好处理，确认轨迹查询具体规则在 mq 处理的时侯可以直接筛选下重复数据生成一个车辆轨迹相关的文档。
第二和第三个直接查询最新位置信息就可以，

1. 换 MQTT 感觉 IoT 场景用 MQTT 的挺多的吧
2.这个的话 MongoDB 是有针对时序数据的 collection 做单独优化的 但是具体性能位置
然后你要的那几个查询 MongoDB 都有原生的查询函数 起码你代码写起来很简单

1.现在问题是只要数据接收接口挂了，就无法接收到数据了，要如何保证数据不丢失呢？

这个接口原来直接写 mongoDB 的话，改为写 kafka ，然后开异步线程从 kafka 消费写入 MongoDB 。

2.我记得 MongoDB 在大数据量下性能不咋地。每天大概新增 500*16*36(每小时)=83W 数据。每月大概是 2000w 新增。这种数据量我也建议上 Hbase 。只不过 Hbase 的话查询有限制，不能像关系型数据一样查询。

我提供一个 Mongodb 写数据性能的实际体验吧。
之前写了一个小的日志收集，提供的 gRPC 传输，2c4g 的 Mgo ，一天至少写 2-3 千万的数据，但是这个是多集合写。
分担到单集合有些峰值差不多在 5-7 百万数据，CPU 使用波动幅度很小，是因为做了集合分片的。

你的需求就用 mongo ，随便用，本身他也支持 GPS 的查询。 实在担心，自己 router 做一个集合分片即可。
没必要使用 mongodb 自带的 Sharding ，运维成本又上去了。

再回到你说的数据不丢失，这已经有很多成熟的解决方案了，匹配自己的技术栈和架构，找最简单的就行，如果发送端有最基本的重试，那么加一个 gateway 就是最实在的！

@hopingtop #17 再补一个查询体验，只要时间范围做好，命中索引 不长的复合索引，根据日志的查询感官来说，单集合 5000W 数据，可以做到 秒级返回。

存不用特考 一一即可

我以前用 mongodb 2.x 版本做管理 2000 台一例 表十不成

用 ck 吧,查的快

@roundgis 十亿数据查询轨迹速度如何？

@Desdemor ck 是啥

@Allenxup ClickHouse 哇

@Desdemor 明白了，感谢

@Allenxup 我们也有类似的业务,查询那是相当的快了,你可以先存到 redis,然后批量写入

@opengps 有个问题请教，轨迹数据 WGS84 坐标转百度坐标，放前端转还是后端转比较好呢

@Allenxup 我建议是放在后端，这样可以用额外的 webapi 去进行处理，前端只管使用数据成果即可。
我之前是同时存储 2 份数据，这样遇到比如计算里程的时候，直接使用原始坐标可以更高的理论准确度。实际用下来却发现意义不大，虽然两套标准并没有线性关系，但是在较多点的场景下，互相填补之后的里程计算结果基本就接近均匀坐标了

@opengps 我这边也是放后端处理，但是在轨迹坐标转换部分耗时比较长，导致查询轨迹耗时 6s 左右，有什么解决办法吗

@Allenxup 那你得自己验证下了，思路：
1 ，硬盘速度跟上，看下磁盘队列有没有占满或者拉长
2 ，sql 索引使用情况，比如我早期版本关系型数据库，天然就给查询只提供一种方式，一定会命中索引
3 ，sql 一次读取量大小，sql 查询效率之外，那就是看你数据从硬盘到内存的总大小是不是满速传输依然需要 6 秒了，可以根据需要缩减需要返回的字段数量
4 ，其他处理，有没有额外在程序里过滤或者排序，或者替换补充数据等等，能回归到原始的硬盘读写，就不要去费劲转换
5 ，网络传输，服务器到客户端经过的网络带宽跟你序列化之后的结果集大小换算下耗时

@Allenxup 刚注意到附言，我都是入库时候先纠偏在入库，因为只查询一个点，所以单个流程里耗时很低

另外，大家可能不知道，早期的方案多数人不是用联网查百度 webapi,而是自己采集的本地纠偏数据库，现在限制并发了总量了，采集不动了。

@opengps 感谢解答。你的意思是坐标转换后再入库吗

@Allenxup 是的。几乎所有核心功能全是在后端完成，包括围栏之类的

@opengps 但是考虑到以后如果换其他地图的话就麻烦了，不太灵活

上一个消息队列，分别用消费者处理业务。包括你得坐标转化。

@Allenxup 所以需要存原始坐标，毕竟有些地图标准只支持单向转化，你可以自己决定备用转化字段的存储结果是什么标准的。在所有的资源中，存储换效率是最低成本的

之前用过 clickhouse 存轨迹,存了 6000w 吧,用 10 个左右条件去查结果 30w 量级的数据,秒出,就是要自己想想怎么合并请求入库,官方推荐每秒最多 100 次 insert 操作

1.本地存储临时文件，定时上传，失败重试
2.服务端异步消息，或者直接 mongodb 都行
只要本地不丢失，都没问题。

@Allenxup 尽量保存原始记录，不要跟百度绑死了，api 计费规则修改为按次计费也不是不可能。

而且不管是 Android iOS 还是浏览器端都支持 WGS84 坐标绘制的，保存 BD09LL 或 GCJ02 完全没有意义

geomesa

当然用 mysql 存：用 kafka 收数据，用 mysql 落盘

你们这个公司规模很小吧，要尽可能的降低技术维护成本， 统一存储。

WGS84 坐标使用百度 API 转百度坐标耗时比较长:
建议直接谷歌搜索“WGS84 坐标转换百度坐标 JS 方法”，已经有精确度蛮高的民间转换方法了

@guxin0123 那我如果使用百度地图，每次查询轨迹都需要转换坐标了，比较耗时，有什么办法解决吗

@Allenxup 三天的秒

直接用百度地图鹰眼轨迹就行吧, https://lbsyun.baidu.com/products/yingyan 定位点数据灌进去, 有网页或接口可以查询轨迹, 还可以纠偏和抽稀

@Allenxup 不需要转换 api 里面有使用 wgs84 坐标格式的选项

@guxin0123 百度地图可以直接使用 wgs84 坐标？

@Allenxup 看错了 Android sdk 可以使用 GCJ02 其他的要自己转

wgs84->gcj02 gcj02->bd09

有相关 Java 代码 是 csdn 上的

aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZlaW5pZmkvYXJ0aWNsZS9kZXRhaWxzLzEyMDU0NzEyNw==