众所周知，ES的 index_API 和 update_API, 去更新一个文档的某个属性的时候，其实都是需要把整个文档重新load回来，去替换某部分的字段，最终这个文档是需要重新建索引。这是和Lucene 索引文件的 append_only 特性有关。
这个特性其实是为了最大限度取得建索引的性能来决定的，但是在非常多的场景里，我们往往只是频繁的更新某个field，或者是大批量的去更新某个field，这个特性则必须把整个文档重新索引，反而又严重的影响了整体的索引性能。
本来也是心存疑虑，Lucene 索引文件只写不修改这个能理解，但是为什么不是每个 doc_value 之间相互隔离呢，Lucene 的index API 非得传入整个Document 呢?
翻查了许多的文档，其实从ES 1.x 开始则陆陆续续有人提问相关问题，这篇文章主要是把一些讨论收集起来，去思考一下为什么Lucene直到现在还没有提供基于单个 docvalue 的update 操作。
可能有人最先想到的是Solr，Solr所谓基于field的 update，但是也是有先决条件的，它要求每个field都需要设置 store 属性，那其实本质上来说，它还是把所有字段重新获取回来重新索引了，和Elasticsearch的机制没有本质区别，只不过ES 自己搞了一个 _source 字段来搞这事而已。
https://stackoverflow.com/questions/11791803/update-a-new-field-to-existing-document
先看看为什么Lucene 其实是不支持只update 一个字段？
首先在StackOverflow 上，有个人是非常精辟就回答了这个问题
https://stackoverflow.com/questions/12185406/why-lucene-doesnt-support-any-type-of-update-to-an-existing-document
这个说法是有点道理的，因为很多时候建索引是相对于整个文档而已，牵一发动全身，对于修改了文档的某个地方，其实为了避免出问题，最好的办法还是重新索引整个文档。
后来我又找到了一个人提了一个比较好的idea，他建议Lucene 去把所有的字段归纳成 hot-search-fields 和 cold-search-fields 然后可以自行根据策略去决定分别去update 这两部分的索引。
其实这应该就是一个这种的方案，不过就是该要做的工作，使用是要做，因为，如果这样实现的话，其实还是需要在Lucene 上引入向前segment 追加查询文档的能力（为什么Lucene需要这样做，我在下面会说明）
field family segment design : hot-search-field with more frequent segment merge. #31464
后来ES的作者也回答了这种设计本质来说Lucene 是不支持的。这篇issue上面同事也引了另外一个人的提问，同样提出这样的问题。这里就不再介绍。
接下来我想说的，上面的帖子最后被duplicate到一篇原始的需求，在这篇帖子里，ES的开发者们进行了详细的讨论（只可惜最后这是落下一些 open questions，仍然没有进去实施阶段）但是讨论还是很细致的，因此我打算逐个部分贴出来讨论一下。
这段话比最开始那段解释，更详细的解释了为什么ES并不支持单个field的更新，因为Lucene 的索引还是基于segment 文件来走，写好一个加载一个，而查询的命中是基于segment 的，那就意味着，如果一个文档的字段跟新被写进去了新的 segment 去了，要在新的segment 去过滤文档的属性，其他字段也必须存在，而内部segment则采用一个不断自增的 doc_id 去实现 append_only的逻辑。
想象一下，如果去掉了这个逻辑，那么就意味着，要查找一个文档，必须每个字段都记录它最后保存的segment，而segment中的倒排文档数据结构则是用posting-list，这个结果几乎无法快速拆解和搬迁，因此可以认为是不迁移的，最终这样搞的话则会对搜索的效率大打折扣了。
那知道为什么Lucene 不能做到的话，下面可以看看几种选择，还有利弊，ES作者是高度概括，大家可以看看
一种方式无非就是用多个type 和parent/child 做个正交分解，但是这样的查询效率并不高，而且在高版本其实会带来兼容问题，作者明确是不爽这个方式。
第二种方式就是要实现基于docvalue 更新，则需要重写整个segment的实现，看样子短时间Lucene 是不太愿意做。
最后就是要实现向前追踪了。
帖子后面还有一些讨论，大家有兴趣可以去看看，总结就是目前来看，方案还是有些利弊，至于Lucene 要向那个方向来实现，还是拭目以待吧（这个issue 仍然Open状态）！
