es 过亿数据查询咨询

seedhk 2026-06-04 17:06 1

前提:


1 亿左右的数据,数据来源是设备的轨迹数据(gps ,速度,温度等信息),设备端按 5s 左右一次上报


查询需求:



  1. 能支持查询 3 400 台设备的最新轨迹数据

  2. 查询单个设备的轨迹信息(这个简单)


我自己尝试搭建了 3 个节点的 es ,每个节点 4g 左右内存,发现执行需求 1 时,大概需要 2-5s 左右,查询语句:


curl -X GET "http://192.168.1.210:9200/test_index/_search?pretty" \
-H 'Content-Type: application/json' \
-d '{
"query": {
"terms": {
"serialNumber": [省略 sn]
}
},
"collapse": {
"field": "serialNumber"
},
"size": 300
}'


mapping 信息:


{
"settings": {
"number_of_shards": 3,
"number_of_replicas": 1,
"index": {
"sort.field": "createTime",
"sort.order": "desc"
}
},
"mappings": {
"properties": {
"serialNumber": {
"type": "keyword"
},
"createTime": {
"type": "date",
"format": "strict_date_optional_time||epoch_millis||yyyy-MM-dd HH:mm:ss.SSS||yyyy-MM-dd HH:mm:ss"
},
"longitude": {
"type": "double"
},
"latitude": {
"type": "double"
}
}
}
}


请问可以做到需求 1 查询 3-400 台设备,耗时到 1s 左右吗?

最新回复 (57)
  • dode 06-04 17:11
    1
    都是时序数据,查的时候,限制数据在最新二十分钟内,应该就可以命中缓存了吧
  • tf2 06-04 17:13
    2
    无脑建议 "number_of_shards": 10 先试试。
  • ca2oh4 06-04 17:14
    3
    那应该用时序数据库可能更合适一下吧
  • ca2oh4 06-04 17:15
    4
    另外 4GB 内存对于 ES 来说有点少,建议一个节点至少 64GB
  • luciankaltz 06-04 17:15
    5
    都是时序数据,为什么不放时序数据库呢
    还是你要对着某个文本字段做全文索引?
  • ca2oh4 06-04 17:15
    6
    如果内存紧张,多节点不如单节点
  • seedhk 楼主 06-04 17:16
    7
    @dode 因为可能会有部分设备很久没有上报,也需要展示这些数据,所以没法加时间范围限制
  • seedhk 楼主 06-04 17:21
    8
    @tf2 加到这么多分片会更快吗?
  • seedhk 楼主 06-04 17:22
    9
    @ca2oh4 #3
    @luciankaltz 我去看看时序数据库,谢谢
  • AutumnVerse 06-04 17:23
    10
    lat lng 不要用 double 存,有专门的 location 类型。

    不过单看你这个查询,索引和查询语句都没问题,不应该这么慢,应该是 es 哪里配置有问题。不过你这个内存确实太小了,线上 es 服务器,基本上 200g 内存起步
  • fjkfwz406 06-04 17:27
    11
    调大 shards ,按照 serialNumber router 到一个 shard 上,可以避免查多个 shard 然后 merge 的消耗
  • opengps 06-04 17:29
    12
    车辆定位,是个前同行
  • seedhk 楼主 06-04 17:30
    13
    @AutumnVerse lat 和 lng 因为不会涉及查询,还需要改成 location 吗?
    您说的具体配置问题可能是哪里问题? 内存如果换成 3 个节点每个 8g ,是否会好一些?
  • seedhk 楼主 06-04 17:31
    14
    @fjkfwz406 shards 数据增加吗?
    另外测试过 serialNumber route 到一个 shard 上的,速度也快不起来
  • seedhk 楼主 06-04 17:31
    15
    @opengps 请问下您之前涉及这块需求了吗? 是如何处理的
  • opengps 06-04 17:35
    16
    @seedhk #15 你只是要查询最新,那可以从源头上解决,直接内存里缓存所有设备的最后一条数据,而不是去数据库执行查询
  • shalou8023 06-04 17:35
    17
    可以考虑下时序数据库 Clickhouse 之类的
  • awesomePower 06-04 17:38
    18
    我试了下,用数据库也很快。随机生成一亿两千万数据,字段比你的例子还多两个。用随机 300 个 serialNumber 查一下,只要 0.3 秒
  • nc 06-04 17:39
    19
    每个节点内存太小了,ES 的数据要全部放到内存里最好。
  • 1018ji 06-04 17:40
    20
    机器性能不行,白搭
  • promise2mm 06-04 17:44
    21
    磁盘什么规格?就你这点内存,大概率磁盘查了

    profile 看一下时间耗在哪里
  • seedhk 楼主 06-04 17:44
    22
    @awesomePower 请问是什么数据库,也是轨迹数据直接查最新吗?什么配置
  • seedhk 楼主 06-04 17:45
    23
    @promise2mm
  • seedhk 楼主 06-04 17:46
    24
    @promise2mm 本地电脑测试,用的是 nvme 垃圾固态,节点跑在 3 个 vmware 搭建的 ubuntu 上
  • fmumu 06-04 17:48
    25
    设备最新一条数据可以缓存起来
  • awesomePower 06-04 17:48
    26
    @seedhk ClickHouse 这种,干这个挺合适的。数据库服务器 4G 内存太太小了,最好 32G 以上
  • yshan 06-04 17:51
    27
    查询条件加上 时间限制呢
  • wxm 06-04 17:52
    28
    内存太小了
  • sead 06-04 18:01
    29
    ClickHouse +1
  • wxVIP 06-04 18:16
    30
    这肯定用时序数据库啊,ES 不太适合这种场景。ClickHouse ++++++
  • AutumnVerse 06-04 18:16
    31
    @seedhk 你需求不是说是轨迹信息吗,那你不涉及 gis 相关的计算吗?比如某个设备是否出了某个区域,或者聚合热力图之类的,或者查询某个点附近的设备,如果不涉及任何 gis 计算,那你确实怎么存都无所谓。

    就算没有 gis 计算需求,建议别给自己挖坑,一步到位直接 location 类型存,不然以后遇到 gis 需求你这类型坑死人

    硬件配置我也不懂,我这里有专门的 es 运维,配置这种事情都是运维去干的。
  • AutumnVerse 06-04 18:20
    32
    另外,楼上说 ck 是合理的。但是吧,基于你现在的状况,不建议上 ck

    1.几亿条数据而已,但凡是个数据库都能干,上 ck 这点数据量纯粹高射炮打蚊子

    2.ck 硬件要求高得离谱,动不动要上百核的机器

    3.ck 查 qps 支持很低,他是数据计算引擎,而不是查询引擎,就这种简单查询完全没必要上 ck
  • liangc230323 06-04 18:48
    33
    @AutumnVerse 不是说 64G 吗,再往上内存太大,边际收益递减
  • misaka19000 06-04 18:53
    34
    内存太低
  • xcrossed 06-04 19:17
    35
    无脑上时序数据库,es 不适合这个场景,
  • vindurriel 06-04 19:20
    36
    加上 sort 试试 另外 size 300 也可以调调
  • roundgis 06-04 19:50
    37
    这个量 10 年前搞过

    当时纯用 mongodb 就解决了
  • irvinghua 06-04 20:01
    38
    ES 的应用场景其实很窄,就只擅长文档检索。OLAP 这行业发展很缓慢,导致 ES 和 Hive 这种狭窄领域的特长生,被很多人拿来当 OLAP 领域的通才用。直到最近 7 、8 年才百花齐放,出现了很多很好用的 OLAP 工具。你这种是属于典型的日志型分析数据,应该交给日志数据专长生 clickhouse 来做。其实更推荐 Doris 这个真正的通才,做日志查询,点查,聚合查,ads 报表查,文档查询,一个工具全搞定。

    不过说实话,你这个机器配置太寒碜了(估计 CPU 核数也不太多),直接上 clickhouse 或者 Doris ,跑起来很艰难,再说你这数据已经非常小了。没必要上这么重型工具。1 亿数据 mysql 就完全能搞定。把你设备上报的数据先接入 MQ ,再写个工具消费 mq 数据后,在 redis 里维护这几百台设备位置信息的 list 队列,你的程序只负责维护每个队列直接 LPUSH ,加 LTRIM 。redis 查询,那基本就是 ms 级别查询。
  • Jh1n 06-04 21:24
    39
    我也搞过类似的用的 doris 数据库存的,数据比你的多,效果还行
  • hiboshi 06-04 21:47
    40
    首先你这 4G 的配置确实太小了,充其量测试环境都达不到,4G 的配置 堆内存吃一半 还要剩下还要分给 Filesystem Cache ,内存太小了。

    其实你这场景使用时序数据库比较合适或者 doris 也行。doris 配置要求比较高。
  • hallDrawnel 06-04 22:06
    41
    时序数据可以换一个廉价的方案,不用 ES 也行的。
  • lff0305 06-04 22:23
    42
    serialNumber 这个字段多长?是否超过了 ES 索引的长度?
  • laminux29 06-04 22:38
    43
    不说软硬件配置信息,不说 CPU 、内存、网络、存储等使用率,不说具体的数据结构,你是打算让大家给你算一卦嘛。
  • songray 06-04 23:21
    44
    做过类似的,不需要 clickhouse ,用 duckdb 就行了
  • zhuzhibin 06-05 00:39
    45
    小弟半桶水 提点建议 上面很多老哥也说了方案很多 可以不用在一棵树上吊死 例如程序上中间件去设计解决 这个数据库放 MySQL 索引优化一下都感觉不至于这么慢 另外如果一定 ES 当作数据库查询 文档也🉑维护一个 flag 最新标识 每次上报的时候重新计算一下 这样你最终查询 DSL 就是 terms sn and flag 为最新 应该也可以解决?
  • root71370 06-05 01:36
    46
    终于又看到开始讨论技术的帖子了
  • des 06-05 07:59
    47
    @songray duckdb 只能单点吧,你们怎么弄的?
  • Geon97 06-05 09:01
    48
    ES 想做到 1s 左右有点困难,况且不太适合这个场景,还是换数据库吧 ClickHouse 或者时序数据库
  • songray 06-05 10:06
    49
    @des 就单点写入和查询啊,为啥一定要多接入点和分布式呢
  • Wyearn 06-05 11:30
    50
    加硬件内存,加 ES 节点,就能解决。
  • Wyearn 06-05 11:30
    51
    @Geon97 可以的,只要硬件资源跟得上,是可以 1s 的。
  • ycl10875222 06-05 12:07
    52
    可以看下 duckdb 查这个真的是毛毛雨
  • winglight2016 06-05 15:45
    53
    ES 唯一适配的场景就是:有全文检索的需求,也就是反向索引。lz 这个需求,postgresql 足矣,机器资源要求也不会很高。现在才 1 亿数据,即使增长到 10 亿,postgresql 也能撑住。数据再多就不要自己做了,找云平台提供方案,比你自己研究更靠谱。
  • nofishing 06-05 15:54
    54
    可以补充一下业务场景
  • kur0d3s 06-05 16:45
    55
    看看 clickhouse

    用 pg 的话不要看 timescaledb 是坑
  • sampeng 06-05 17:34
    56
    服务器配置太低了。。这个配置只能跑跑 promethes= =
  • des 06-06 10:58
    57
    @kur0d3s timescaledb 咋了
* 帖子来源V2EX
返回