ES 中物联网数据获取最新一条，那种写法性能最好？

[tairan2006]

目前 schema 设计的是每台设备每天建一个 index，比如 iot_env_info_1_2020.02.07 ，id 是时间戳（@timestamp ）。在 index template 里面 alias 所有 info_env_info*为 info_env_info 。

物联网比较常用的查询是显示设备最新一条数据。最简单查询就是按@timestamp对 iot_env_info_1*排倒序，size=1，就完事了。

还有一种写法，是用_cat/indices/info_env_info_1*?format=json&s=index:desc，先看这个设备建立了哪些索引，按名称排倒序，取出第一个。然后对这个特定的索引按时间戳排倒序取出第一条。

理论上后者需要查询的数据更少，但是比较尴尬的是_cat 这个 API 不支持分页，取出的是全量索引，一年 365 天，存个几年之后这个返回数据量还是有点大，费内存…

个人对 es 的排序机制不是很明确，请教一下用第一种写法在数据量大的时候性能下降明显么？不太想做无谓的优化。

手残，应该是 iot_env_info*，有的 iot 打成 info 了😂

[tairan2006]

当然最简单的还是直接缓存设备最新一条数据到 redis 里，这个就不用说了(￣▽￣")

[misaka19000]

改成按月拆分索引

[tairan2006]

@misaka19000 这样也行，10 秒采集一次的话，单索引一个月也就 26 万左右，Emmm

[misaka19000]

@tairan2006 #3 才 26 万数据？那整一个索引得了

[misaka19000]

一个索引一年也才 300 万数据

[luofan004]

@misaka19000 +1

[tairan2006]

@misaka19000 拆分还要考虑方便删除旧数据，比如只给用户保留最近半年的数据…毕竟有的项目设备上千个

[YouLMAO]

物联网，opentsdb

[est]

看看 routing ？

[Morriaty]

再弄个 iot_hot 别名指向最近七天（具体时间看业务）不就行了吗，建议看下 es7 之后的 ILM 索引生命周期管理（冷热分离）

[tairan2006]

@Morriaty 需求是最新一条…有的设备可能好几天没数据（比如过年把设备断电了…）

[tairan2006]

@est 小厂，就一个副本…靠 routing 提高性能好像不太可行？

[est]

@tairan2006 看下上面说的那个 ILM 冷热分离。感觉有戏。

[tairan2006]

@est 这个我研究过 ，感觉最多用个 delete…

[Morriaty]

@tairan2006 #11 ilm 除了时间策略，还有 doc 数策略，超过多少条才触发 rollover

[AS4694lAS4808]

改成_cat/indices/info_env_info_1*?h=index&format=json&s=index:desc 这样呢？一年的索引名也就十多 KB
无脑方法，大神请无视

[tairan2006]

@Morriaty 嗯 物联数据其实还好 大部分采样周期是固定的，用时间没啥问题…

[tairan2006]

@AS4694lAS4808 我改成按月建 index 了，这样比较均衡。

[AS4694lAS4808]

@tairan2006 我公司用的 aws 双核 16G 的多个实例，每个索引几亿条 IOT 日志数据，查起来都挺快的。。其实第一种感觉可以放心的用

[tairan2006]

@AS4694lAS4808 那更好:-D

[Anshay]

这个业务需求，我的做法是根据时间拿到涉及到的索引传进去。因为是按天，不建议用别名。所有查询根据时间自动传入涉及索引。
我做的业务和贵司类似，踩过挺多坑。

[strawberryBug]

试试这种，创建索引的时候就倒序存储，这样倒序查询的时候就不会从最早的数据开始扫描。
PUT my-index-000001
{
"settings": {
"index": {
"sort.field": "date",
"sort.order": "desc"
}
}
}
官网链接（ https://www.elastic.co/guide/en/elasticsearch/reference/master/index-modules-index-sorting.html)

[lithium4010]

够用的话越简单越好

[tairan2006]

@strawberryBug 这个我知道，和我想问的不冲突。这算是单个索引内的优化…