知其然,知其所以然
Elasticsearch 2026-10-02

聚合结果为什么不能直接当搜索结果

本机真实用size=2限制命中数量,terms聚合依然精确统计出全部5篇文档(a:3,b:2),不受size限制。真实打印聚合桶原始结构,只有key和doc_count,没有_id和_source——聚合桶不携带任何文档身份信息,真实需要嵌套top_hits才能捞回具体文档,证明聚合是独立的统计摘要而非可展示的文档列表。

Elasticsearch 真实验证 动画演示
Elasticsearch 2026-10-02

Index、Create、Update、Delete API 的区别

本机真实用_create在新id写入成功,同id再调一次真实409报错已存在。index API(_doc PUT)覆盖同id,真实整篇替换,原来的val字段彻底消失。update API传同样的部分字段,真实做合并,val原值被保留。delete后再GET,直接404。

Elasticsearch 真实验证 动画演示
Elasticsearch 2026-10-02

Bulk API 批量写入

本机真实写入1000条文档,挨个发送独立请求真实耗时4.674秒,打包成1次_bulk请求真实只要0.017秒,快约275倍,errors:false确认全部成功。真实验证NDJSON格式要求index/create/update操作必须元数据行+数据行成对出现,格式解析严格不是静默容错。

Elasticsearch 真实验证 动画演示
Elasticsearch 2026-10-02

Bulk 请求中部分成功如何处理

本机真实构造3条操作的bulk请求:create新id成功(201)、create已存在id失败(409版本冲突)、index字段类型不匹配失败(400文档解析异常)。整体HTTP状态码真实是200,但顶层errors:true。证明bulk请求每条操作真实独立成败,必须检查errors字段和逐条items结果才能正确判断真实处理结果。

Elasticsearch 真实验证 动画演示
Elasticsearch 2026-10-02

refresh=true、refresh=wait_for 与默认刷新

本机真实设refresh_interval=5s测三种刷新策略:默认写入后立刻搜索真实0命中。refresh=true写入调用真实只多花0.015秒,返回后立刻能搜到——强制插入额外刷新。refresh=wait_for写入调用真实卡住等了4.285秒才返回,不插入额外刷新只是阻塞等待自然刷新周期完成,两者机制完全不同。

Elasticsearch 真实验证 动画演示
Elasticsearch 2026-10-02

Refresh、Flush、Commit 的区别

本机真实写入100条文档,flush前translog有100条操作7347字节,flush后真实清空归零只剩55字节文件头——flush触发Lucene commit真实持久化落盘。再写50条后refresh(不flush),translog真实完全没变还是50条,但搜索真实命中150条全部可见——refresh只负责让数据可搜索,完全不碰translog,这是跟flush最根本的区别。

Elasticsearch 真实验证 动画演示
Elasticsearch 2026-10-02

Translog 如何保证写入恢复

本机真实写入30条文档不refresh不flush,崩溃前translog真实记录30条操作但_count显示0。真实kill -9硬杀ES进程模拟真实崩溃,没有任何优雅关闭。重启后集群恢复green,30条文档真实一条不少全部找回来,translog清零——证明translog回放真实能在进程硬崩溃场景下保住未持久化的数据。

Elasticsearch 真实验证 动画演示
Elasticsearch 2026-10-02

Segment 文件如何生成

本机真实关闭自动刷新,写入5条文档后refresh前真实一个segment都没有。手动refresh后真实冒出segment_0(committed:false但已可搜索)。flush后_0变committed:true,再写3条+refresh真实生成全新独立的segment_1,_0完全没被改动——证明segment一旦生成就不可变,每次refresh都是追加生成新文件。

Elasticsearch 真实验证 动画演示
Elasticsearch 2026-10-02

Segment Merge 的触发条件

本机真实30次单文档写入+refresh,理论上应攒出30个segment,真实只剩3个。merge统计显示total=3次合并处理了39个文档,generation编号21/31/32真实跳跃巨大证明大量中间段被消灭。全程没有手动force_merge,印证TieredMergePolicy自动在每次refresh后评估并触发体积相近小segment的合并。

Elasticsearch 真实验证 动画演示
Elasticsearch 2026-10-02

force_merge 的风险

本机真实删一半文档(10万删5万),store.size真实一个字节没变还是20.3mb。force_merge到1个segment后store.size真实降到10.6mb,但合并后唯一segment的docs.deleted真实依然是50000不是0——查到soft_deletes.retention_lease.period默认12小时,证明force_merge不会立刻彻底清空保留期内的软删除记录,这是容易被忽视的真实风险。

Elasticsearch 真实验证 动画演示
Elasticsearch 2026-10-02

删除文档为什么不会立刻释放磁盘

本机真实删2.5万条文档,store.size真实不降反升(5.2mb→5.5mb),docs.deleted真实是实际删除数的2倍(soft_deletes记两笔账)。全部5万条删光后store.size继续涨到5.8mb。force_merge带only_expunge_deletes后docs.deleted减半但store.size分毫未动——soft_deletes.retention_lease默认12小时阻止彻底回收。

Elasticsearch 真实验证 动画演示
Elasticsearch 2026-10-02

refresh_interval 对写入性能的影响

本机真实对比2000条文档每次都refresh=true(21.167秒)和完全不refresh(10.087秒),慢了约2.1倍。根源是每次refresh都真实生成一个全新segment文件,频繁刷新把这笔固定开销拆成每条文档单独承担,而降低频率能把开销摊销到更多写入上,这正是refresh_interval调大能提升写入吞吐的真实原理。

Elasticsearch 真实验证 动画演示
京ICP备2026067502号-1京公网安备11010502063487号