Elasticsearch 速查实战:索引、Query DSL 与聚合一次理清

每次接手一个新的 Elasticsearch 集群,我都得在 Kibana Dev Tools 里把同一批命令重新敲一遍:看 mapping、试查询、查集群状态。后来我把这些高频动作整理成一份可搜索的速查,边查边敲,省下大量翻文档的时间。这篇把里面最值钱的几块写清楚:索引怎么建、查询 DSL 怎么挑、聚合怎么用、运维时哪几条命令必须随手会。

索引与 mapping:开头定错后面全是坑

新建索引第一件事是显式写 shard 数,别用默认值。时序和日志场景每个 shard 控制在 10 到 50GB,搜索场景 20 到 40GB。每节点 shard 数大约不超过 20 乘以 heap 的 GB 数,一个 30GB heap 的节点放 600 个 shard 左右,不是 6000。

mapping 上最容易出事的是字符串字段。字符串几乎都该建成 text 加一个 keyword 子字段:全文检索走 text,精确过滤和排序走 field.keyword。另外两条我每次都加:用户传入的 JSON 一律 dynamic:strict,挡住 mapping 爆炸;同一个数组元素要同时满足多个条件时,object 必须用 nested,否则条件会跨元素错配。

match、term、bool:全文检索和精确匹配别用错

这三个搞清楚,Query DSL 就通了一半。

• match 是全文检索,会用字段的分析器把查询串分词,再匹配倒排索引。搜"运维手册"这种自然语言用它。
• term 是精确匹配,不分词。但 text 字段入库时被小写加分词了,所以在 text 字段上 term:{"name":"Apple"} 会一条都查不到。精确匹配要走 name.keyword。
• bool 把条件组合起来:must 影响打分,must_not 排除,should 是可选加分,filter 不打分还能被缓存。能放 filter 的 WHERE 条件都放 filter,又快又省。

一段真实查询:近 24 小时的 error 日志

下面这段我几乎天天用,粘进 Dev Tools 就能跑:在 filter 里用 range 配 date math 圈出时间窗,term 精确过滤级别,顺手做一个按分钟的 date_histogram 看趋势。

GET /logs-*/_search
{
  "size": 0,
  "query": {
    "bool": {
      "filter": [
        { "term": { "level.keyword": "error" } },
        { "range": { "@timestamp": { "gte": "now-24h/h", "lte": "now/h" } } }
      ]
    }
  },
  "aggs": {
    "per_minute": {
      "date_histogram": { "field": "@timestamp", "fixed_interval": "1m" }
    }
  }
}

size 设 0 表示只要聚合结果不要原始文档。这条同时演示了 bool filter、term 精确匹配、range 时间窗和聚合,是日志分析最常见的骨架。

聚合与运维:看板和救火都靠它

聚合适合数据已经在 ES、按维度分组、要在百万到十亿级文档上拿亚秒级响应的场景。group-by 用 terms,时序用 date_histogram,分布用 range 或 histogram,指标用 stats 或 percentiles。要做"每个类别 top10 卖家带营收",用 terms 套 top_hits 再加一个 sum 子聚合就能搞定大部分。但聚合不擅长精确去重(cardinality 是近似的)和跨文档 JOIN,这两类该换数据库。

运维上有几条命令我设成肌肉记忆:集群一直黄,先 GET /_cluster/allocation/explain 看哪个副本分不出去;磁盘到 85% 会停分新 shard,到 95% 直接把节点上所有索引锁成只读;深翻页别用 from + size 翻过 10000,改用带 sort 的 search_after。

把这些查询和命令放进可搜索的速查框,中文搜"聚合""分词""集群"都能直接定位。完整的 80 多条带例子和坑都在 Elasticsearch 速查表 里。整条数据栈我还配了 Redis 速查表 和 PostgreSQL 速查表,换组件时少切上下文。

---

Made by Toolora · Updated 2026-06-13