探究：Elasticsearch 文档的 _id 是 Lucene 的 docid 吗？

Lucene's index is composed of segments, each of which contains a subset of all the documents in the index, and is a complete searchable index in itself, over that subset.  As documents are written to the index, new segments are created and flushed to directory storage.  Segments are immutable;  updates and deletions may only create new segments and do not modify existing ones.  Over time, the writer merges groups of smaller segments into single larger ones in order to maintain an index that is efficient to search, and to reclaim dead space left behind by deleted (and updated) documents.

Each document is identified by a 32-bit number, its "docid," and is composed of a collection of Field values of diverse types (postings, stored fields, doc values, and points).  Docids come in two flavors: global and per-segment.  A document's global docid is just the sum of its per-segment docid and that segment's base docid offset.  External, high-level APIs only handle global docids, but internal APIs that reference a LeafReader, which is a reader for a single segment, deal in per-segment docids.

Docids are assigned sequentially within each segment (starting at 0). Thus the number of documents in a segment is the same as its maximum docid;  some may be deleted, but their docids are retained until the segment is merged.  When segments merge, their documents are assigned new sequential docids.  Accordingly, docid values must always be treated as internal implementation, not exposed as part of an application, nor stored or referenced outside of Lucene's internal APIs.

Each document has an _id that uniquely identifies it, which is indexed so that documents can be looked up either with the GET API or the ids query. The _id can either be assigned at indexing time, or a unique _id can be generated by Elasticsearch. This field is not configurable in the mappings.

Most search applications using Apache Lucene assign a unique id, or primary key, to each indexed document. While Lucene itself does not require this (it could care less!), the application usually needs it to later replace, delete or retrieve that one document by its external id.

public AbstractIdFieldType() {super(NAME, isIndexed:true, isStored:true, hasDocValue:false, TextSearchInfo.SIMPLE_MATCH_ONLY, Collections.emptyMap());}

# get 操作
GET my-index-000001/_doc/2

# search 操作
GET my-index-000001/_search
{
  "query": {
    "terms": {
      "_id": [ "2" ] 
    }
  }
}