elasticsearch的索引数据(elasticsearch 索引类型)

「必备技能」Elasticsearch索引全生命周期管理（附代码）

索引(Index)是Elasticsearch中最重要的概念之一，也是整个Elasticsearch操作的基础，Elasticsearch提供了Index APIs用于Elasticsearch生命周期的管理，包括索引的创建、查询、删除和设置，索引的冻结和解冻、拆分和收缩等，掌握索引的管理是Elasticsearch开发、运维的基础能力，也有助于后期对于Elasticsearch的优化。

创建一个索引可以使用Elasticsearch提供的API，其格式如下：

其中 为要创建的索引的名称,是一个必须的参数，所有的字母都必须是小写形式。在创建索引的同时还可以进行相关的设置：

一个不做任何设置的，单纯创建索引的请求如下：

响应体中 “acknowledged” 为true代表索引已经成功在Elasticsearch集群中创建， “shards_acknowledged” 为true则代表在请求超时之前所有的索引分片的副本分片也全部准备完毕。当然，即使 “acknowledged” 和 "shards_acknowledged" 都为false，只能代表超时之前没有完成，后续集群还是可能最终成功创建了索引。

创建索引的API还支持Query Parameters和Request Body，其中的参数均是 可选的参数 。

Query Parameters支持以下参数：

Request Body也支持三个参数：

以下代码示例同时指定了Query Parameters和Request Body ：

通过Get index API，可以查询一个或者多个索引的相关信息，其API格式如下：

其中target可以是数据流、索引，还可以是一个别名，多个索引之间使用逗号分隔，target还支持模糊查询（*），如果查询所有的索引，可以使用 * 或者 _all 。如果集群开启了安全权限控制，那么要查询索引信息需要获得 view_index_metadata 或者 manage 的索引操作权限。以下为查询的具体案例：

Get index API支持带url查询参数，这些参数都是可选参数，主要有以下几个：

首先需要明确索引本身是不能被修改的，当我们说修改索引时，实际上是指修改索引的别名、字段映射（mapping）和配置（settings）。

首先说明一下别名的作用。Elasticsearch提供了别名的功能，一个别名可以添加多个索引，方便通过操作一个别名实际上操作到多个具体的索引，例如每年建一个索引，分别有index-2019,index-2020,index-2021,index-2022共4个索引，这4个索引都关联了别名index-year,当需要查询最近4年的数据的时候，可以使用index-year同时查询这4个年份的索引。

别名的修改，实际上是从索引上删除别名，再重新添加新的别名，将这两个动作放在一起，保证其原子性，确保不会存在别名被删除的瞬间产生没有指向任何索引的问题。

以下代码为将my-index从索引my-index-000001解除，然后重新绑定在索引my-index-000002上。

mapping指定了索引的数据结构，字段类型，修改索引的mapping，可以修改原有字段的名称、类型，添加新的字段等。以下为添加新的email字段，类型为keyword。

支持多个索引、data stream和别名，支持模糊搜索，使用 * 或者 _all 可以指定所有的data stream和别名。

以下为修改settings的案例，设置索引有2个主分片，2个副本。

删除索引将会删除其对应的文档、分片和集群中的元数据信息，索引的操作是一个高危操作，需要慎重，如果集群开启了安全权限控制，那么要删除索引，需要获得 delete_index 或者 manage 的索引操作权限。

不能删除数据流（data stream）的写索引，要删除当前写索引，必须对data stream进行rollover，创建新的写索引。

删除索引的API如下：

是必须参数，指定索引名称，多个索引可以用逗号分割，不支持使用别名，默认情况下也不支持使用模糊匹配，确实需要使用模糊匹配的，需要将集群参数 action.destructive_requires_name 设置为false。 Delete Index API类似Get Index API，同样支持URL查询参数，这些参数包括 allow_no_indices 、 expand_wildcards 、 ignore_unavailable 、 master_timeout 、 timeout ，含义类似，不再赘述。 以下是删除索引的案例代码：

默认情况下，索引一旦被创建出来就是打开的状态，但是在某些情况下可能需要关闭索引，例如一些老旧不需要使用到的索引，仍然占用一定的空间，并且集群仍然需要一定的维护开销，关闭索引将阻塞所有对这个索引的读/写操作，关闭的索引不必维护索引或搜索文档的内部数据结构，从而可以减少集群上开销。

特别注意：关闭索引的操作会消耗大量磁盘空间，在生产上也是一个需要特别注意的操作。可以通过集群设置API将 cluster.indices.close.enable 设置为false来禁用索引的关闭，默认为true。

当一个索引被打开或者关闭，master节点负责重启分片，这些分片都会经历recovery过程，打开或者关闭索引后都会自动进行分片数据的复制，以保证有足够的副本分片以保证高可用性。

默认情况下只支持匹配全名称的特定的索引，但是如果设置了参数 action.destructive_requires_name 为false，则可以使用*或者_all指代所有的索引，但这种情况下一旦有一个索引匹配失败则会报错，不建议开启。

open API用于重新打开被关闭的索引，如果目标是一个data stream，则打开这个data stream背后对应的所有的索引。

默认情况下只支持匹配全名称的特定的索引，但是如果设置了参数 action.destructive_requires_name 为false，则可以使用 * 或者 _all 指代所有的索引，但这种情况下一旦有一个索引匹配失败则会报错。

索引收缩和拆分是指收缩或者拆分索引的主分片数量。首先，我们要明白为什么需要进行索引的收缩和拆分呢？

在 elasticsearch 中，主节点管理分片是很大的工作量，降低集群整体分片数量可以降低 recovery 时间，减小集群状态的大小，降低集群的维护消耗。在很多情况下，经历了一段时间的运行以后，一些冷索引不会再有数据写入，将一些小分片合并可以降低集群的维护成本。

另一方面，如果在业务运行过程中发现前期的预估不足，业务量较大导致单个分片过大，则需要进行索引的拆分扩大主分片的数量。

一、索引收缩

Elasticsearch从5.0版本起提供了 shrink API，用于针对一些小索引缩小索引分片数。实际上并不对源索引进行操作，而是使用与源索引相同的配置创建一个新索引，仅仅降低分片数，索引分片缩小完成后，源索引可删除。

一个索引要能够被shrink API进行分片缩小，需要满足以下三个条件：

为了使分片分配更容易，可以先删除索引的复制分片，等完成了shrink操作以后再重新添加复制分片。

可以使用以下代码，实现删除所有的副本分片，将所有的主分片分配到同一个节点上，并且设置索引状态为只读：

重新分配源索引的分片可能需要一段时间，可以使用_cat API跟踪进度，或者使用集群 健康 API通过 wait_for_no_relocating_shards 参数等待所有分片完成重新分配。

当完成以上步骤以后就可以进行shrink操作了，以下为_shrink API的格式：

以下案例将索引my-index-000001缩小主分片到shrunk-my-index-000001索引。

特别注意：由于添加新文档时使用对分片数量取余获取目标分片，因此目标索引中请求的主分片数量必须是源索引中主分片数量的一个因子。例如，包含8个主分片的索引可以收缩为4个、2个或1个主分片，或者包含15个主分片片的索引可以收缩为5个、3个或1个主分片。如果索引中的分片数量是一个质数，那么它只能收缩为一个主分片。

如果当前索引是是一个data stream的写索引，则不允许进行索引收缩，需要对data stream进行rollover，创建一个新的写索引，才可以对当前索引进行收缩。

整个索引收缩的过程如下：

同样地，Elasticsearch还提供了Split API，用于将索引拆分到具有更多主分片的新索引。Split API的格式如下：

要完成整个Split的操作需要满足以下条件：

以下API请求可以将索引设置为只读：

如果当前索引是是一个data stream的写索引，则不允许进行索引拆分，需要对data stream进行rollover，创建一个新的写索引，才可以对当前索引进行拆分。

以下是使用Split API进行索引拆分的请求案例, Split API支持 settings 和 aliases 。

index.number_of_shards 指定的主分片的数量 必须是源分片数量的倍数。

索引拆分可以拆分的分片的数量由参数 index.number_of_routing_shards 决定，路由分片的数量指定哈希空间，该空间在内部用于以一致性哈希的形式在各个 shard 之间分发文档。 例如，将 number_of_routing_shards 设置为30（5 x 2 x 3）的具有5个分片的索引可以拆分为 以2倍 或 3倍的形式进行拆分。换句话说，可以如下拆分：

5 10 30（拆分依次为2和3）

5 15 30（拆分依次为3和2）

5 30（拆分6）

index.number_of_routing_shards 是一个静态配置，可以在创建索引的时候指定，也可以在关闭的索引上设置。其默认值取决于原始索引中主分片的数量，默认情况下，允许按2的倍数分割 最多1024 个分片。但是，必须考虑主分片的原始数量。例如，使用5个分片创建的索引可以被分割为10、20、40、80、160、320，或最多640个分片。

如果源索引只有一个主分片，那么可以被拆分成为任意数量的主分片。

2.2、索引拆分的工作过程

2.3、为什么Elasticsearch不支持增量的重新分片？

大多数的键值存储都支持随着数据的增长实现自动分片的自动扩展，为什么Elasticsearch不支持呢？

最经典的方案在于新增一个分片，然后将新的数据存储到这个新增加的分片，但是这种方案在Elasticsearch中可能会造成索引的瓶颈，整体的结构会变得比较复杂，因为Elasticsearch需要去定位文档到底归属于在哪一个分片，这意味着需要使用不同的哈希方案重新平衡现有数据。

键值存储系统解决这个问题的方案一般是使用一致性哈希，当分片数从N增加到N+1时，一致性哈希只需要对1/N的key进行重新分配，例如redis集群的方案就是蕾丝如此。

但是Elasticsearch分片的底层实际上上是Lucene的索引，而从Lucene索引删除一小部分的数据，通常比键值存储系统的成本要高得多。所以Elasticsearch选择在索引层面上进行拆分，使用硬链接进行高效的文件复制，以避免在索引间移动文档。

对于仅追加数据而没有修改、删除等场景，可以通过创建一个新索引并将新数据推送到该索引，同时添加一个用于读操作的涵盖旧索引和新索引的别名来获得更大的灵活性。假设旧索引和新索引分别有M和N个分片，这与搜索一个有M+N个分片的索引相比没有任何开销。

2.4、如何监控Split的进度

使用Split API进行索引拆分，API正常返回并不意味着Split的过程已经完成，这仅仅意味着创建目标索引的请求已经完成，并且加入了集群状态，此时主分片可能还未被分配，副本分片可能还未创建成功。

一旦主分片完成了分配，状态就会转化为 initializing ，并且开始进行拆分过程，直到拆分过程完成，分片的状态将会变成 active 。

可以使用 _cat recovery API 来监控Split进程，或者可以使用集群 健康 API通过将 wait_for_status 参数设置为黄色来等待所有主分片分配完毕。

Elasticsearch Clone API可以用于Elasticsearch索引数据的复制和备份。

二、索引克隆API

索引克隆不会克隆源索引的元数据，包括别名、ILM阶段定义、CCR follower相关信息，克隆API将会复制除了index.number_of_replicas和index.auto_expand_replicas之外的所有配置，这两个特殊的配置可以在克隆API的请求中显式指定。Clone API的格式如下：

索引满足可以克隆的条件是：

参照之前讲过的内容，仍然可以通过将 index.blocks.write 设置为true来确保索引是可读的状态。以下是克隆API的案例：

注意： index.number_of_shards 的值必须与源索引的主分片数量一致。

三、索引克隆的过程

四、监控克隆的进度

使用Clone API进行索引的克隆，API正常返回并不意味着Clone的过程已经完成，这仅仅意味着创建目标索引的请求已经完成，并且加入了集群状态，此时主分片可能还未被分配，副本分片可能还未创建成功。

一旦主分片完成了分配，状态就会转化为 initializing ，并且开始进行克隆过程，直到克隆过程完成，分片的状态将会变成 active 。

可以使用 _cat recovery API 来监控Clone进程，或者可以使用集群 健康 API通过将 wait_for_status 参数设置为黄色来等待所有主分片分配完毕。

rollover API是Elasticsearch提供的一个很好用的功能。我们都知道在MySQL中一旦数据量比较大，可能会存在分库分表的情况，例如根据时间每个月一个表。rollover功能就类似这种情况，它的原理是先创建一个带别名的索引，然后设定一定的规则（例如满足一定的时间范围的条件），当满足该设定规则的时候，Elasticsearch会自动建立新的索引，别名也自动切换指向新的索引，这样相当于在物理层面自动建立了索引的分区功能，当查询数据落在特定时间内时，会到一个相对小的索引中查询，相对所有数据都存储在一个大索引的情况，可以有效提升查询效率。

rollover API会为data stream或者索引别名创建一个新的索引。（在Elasticsearch 7.9之前，一般使用索引别名的方式来管理时间序列数据，在Elasticsearch之后data stream取代了这个功能，它需要更少的维护，并自动与数据层集成）。

rollover API的效果依据待滚动的索引别名的情况不同而有不同的表现：

使用rollover API的时候如果指定新的索引的名称，并且原索引以“-”结束并且以数字结尾，那么新索引将会沿用名称并且将数字增加，例如原索引是 my-index-000001 那么新索引会是 my-index-000002 。

如果对时间序列数据使用索引别名，则可以在索引名称中使用日期来跟踪滚动日期。例如，可以创建一个别名来指向名为 的索引，如果在2099年5月6日创建索引，则索引的名称为 my-index-2099.05.06-000001 。如果在2099年5月7日滚动别名，则新索引的名称为 my-index-2099.05.07-000002 。

rollover API的格式如下：

rollover API也支持Query Parameters和Request Body，其中Query parameters支持 wait_for_active_shards 、 master_timeout 、 timeout 和 dry_run ,特别说一下 dry_run ，如果将 dry_run 设置为 true ，那么这次请求不会真的执行，但是会检查当前索引是否满足 conditions 指定的条件，这对于提前进行测试非常有用。

Request Body支持 aliases 、 mappings 和 settings （这三个参数只支持索引，不支持data stream）和 conditions 。

特别展开讲一下 conditions 。这是一个可选参数，如果指定了 conditions ，则需要在满足 conditions 指定的一个或者多个条件的情况下才会执行滚动，如果没有指定则无条件滚动，如果需要自动滚动，可以使用ILM Rollover。

conditions 支持的属性有：

以下为rollover一个data stream的一个案例：

响应信息如下：

以下为rollover一个索引别名的一个案例：

2. 请求rollover API

如果别名的索引名称使用日期数学表达式，并且按定期间隔滚动索引，则可以使用日期数学表达式来缩小搜索范围。例如，下面的搜索目标是最近三天内创建的索引。

索引的冻结是Elasticsearch提供的一个用于减少内存开销的操作，这个功能在7.14版本中被标记为 Deprecated ，在Version 8以后，已经对堆内存的使用进行了改进，冻结和解冻的功能不再适用。

这里简单地进行操作演示，如果是7.x版本仍然可以作为参照。

一、索引冻结

索引被冻结以后除了在内存中维护其元数据之外，在集群上几乎没有任何的开销。被冻结以后，索引是只读的，所有的写操作都将会被阻塞，例如文档的写入、merge合并等。

API格式如下：

以下为索引冻结操作的代码案例：

注意，冻结索引将关闭该索引，并在同一个API调用中重新打开它，这将导致在短时间内主分配没有被分配，并导致集群变为红色，直到再次完成分配。

二、索引解冻

对应索引的冻结，解冻的API格式如下：

以下为索引解冻操作的代码案例：

Elasticsearch提供了Resolve index API用于辅助进行索引的解析，根据提供的索引/别名/数据流的名称或者模式匹配，查询出当前集群中匹配的索引的信息。以下为API的格式：

案例如下：

这个API的作用多为辅助，实际使用不多，细节的参数可以参考官方的文档。

跟我一起奋斗成为Elastic专家

elasticsearch 索引配置

"dynamic": "false",

? //关闭自动添加字段，关闭后索引数据中如果有多余字段不会修改mapping,默认true

{

? "dynamic": "false",

? "_id": {

? ? "index": "not_analyzed",

? ? "store": "no"

? },

? //设置文档标识符可以被索引，默认不能被索引。可以设置为"_id": {

? ? "path": "book_id"

? },

? 这样将使用字段book_id作为标识符"_all": {

? ? "enabled": "false"

? },

? //禁用_all字段，_all字段包含了索引中所有其他字段的所有数据，便于搜索。默认启用"_source": {

? ? "enabled": "false"

? },

? //禁用_source字段，_source字段在生成索引过程中存储发送到elasticsearch的原始json文档。elasticsearch部分功能依赖此字段(如局部更新功能),

? 因此建议开启。默认启用"_index": {

? ? "enabled": "true"

? },

? //启用_index字段，index字段返回文档所在的索引名称。默认关闭。"_timestamp": {

? ? "enabled": "true",

? ? "index": "not_analyzed",

? ? "store": "true",

? ? "format": "YYYY-mm-dd"

? },

? //启用时间戳并设置。时间戳记录文档索引时间，使用局部文档更新功能时，时间戳也会被更新。默认未经分析编入索引但不保存。"_ttl": {

? ? "enabled": "true",

? ? "default": "30d"

? },

? //定义文档的生命周期,

? 周期结束后文档会自动删除。"_routing": {

? ? "required": "true",

? ? "path": "name"

? }//指定将name字段作为路由，且每个文档必须指定name字段。"properties": {

? ? "id": {

? ? ? "type": "long",

? ? ? //公共属性"store": "yes",

? ? ? //数值特有属性"precision_step": "0"//指定为该字段生成的词条数，值越低，产生的词条数越多，查询会更快，但索引会更大。默认4

? ? },

? ? "name": {

? ? ? "type": "string",

? ? ? //公共属性"store": "yes",

? ? ? "index": "not_analyzed",

? ? ? //analyzed: 编入索引供搜索、no: 不编入索引、not_analyzed(string专有): 不经分析编入索引"boost": "1",

? ? ? //文档中该字段的重要性，值越大表示越重要，默认1"null_value": "jim",

? ? ? //当索引文档的此字段为空时填充的默认值，默认忽略该字段"include_in_all": "xxx"//此属性是否包含在_all字段中,

? ? ? 默认为包含//字符串特有属性"analyzer": "xxx",

? ? ? //定义用于索引和搜索的分析器名称，默认为全局定义的分析器名称。可以开箱即用的分析器: standard,

? ? ? simple,

? ? ? whitespace,

? ? ? stop,

? ? ? keyword,

? ? ? pattern,

? ? ? language,

? ? ? snowball"index_analyzer": "xxx",

? ? ? //定义用于建立索引的分析器名称"search_analyzer": "xxx",

? ? ? //定义用于搜索时分析该字段的分析器名称"ignore_above": "xxx"//定义字段中字符的最大值，字段的长度高于指定值时，分析器会将其忽略

? ? },

? ? "published": {

? ? ? "type": "date",

? ? ? //公共属性"store": "yes",

? ? ? //日期特有属性"precision_step": "0",

? ? ? //指定为该字段生成的词条数，值越低，产生的词条数越多，查询会更快，但索引会更大。默认4"format": "YYYY-mm-dd"//指定日期格式，默认为dateOptionalTime

? ? }

? }

}'? ?

ElasticSearch数据存储内容

很多使用Elasticsearch的同学会关心数据存储在ES中的存储容量，会有这样的疑问：xxTB的数据入到ES会使用多少存储空间。这个问题其实很难直接回答的，只有数据写入ES后，才能观察到实际的存储空间。比如同样是1TB的数据，写入ES的存储空间可能差距会非常大，可能小到只有300~400GB，也可能多到6-7TB，为什么会造成这么大的差距呢？究其原因，我们来探究下Elasticsearch中的数据是如何存储。文章中我以Elasticsearch 2.3版本为示例，对应的lucene版本是5.5，Elasticsearch现在已经来到了6.5版本，数字类型、列存等存储结构有些变化，但基本的概念变化不多，文章中的内容依然适用。

Elasticsearch对外提供的是index的概念，可以类比为DB，用户查询是在index上完成的，每个index由若干个shard组成，以此来达到分布式可扩展的能力。比如下图是一个由10个shard组成的index。

shard是Elasticsearch数据存储的最小单位，index的存储容量为所有shard的存储容量之和。Elasticsearch集群的存储容量则为所有index存储容量之和。

一个shard就对应了一个lucene的library。对于一个shard，Elasticsearch增加了translog的功能，类似于HBase WAL，是数据写入过程中的中间数据，其余的数据都在lucene库中管理的。

所以Elasticsearch索引使用的存储内容主要取决于lucene中的数据存储。

下面我们主要看下lucene的文件内容，在了解lucene文件内容前，大家先了解些lucene的基本概念。

lucene包的文件是由很多segment文件组成的，segments_xxx文件记录了lucene包下面的segment文件数量。每个segment会包含如下的文件。

下面我们以真实的数据作为示例，看看lucene中各类型数据的容量占比。

写100w数据，有一个uuid字段，写入的是长度为36位的uuid，字符串总为3600w字节，约为35M。

数据使用一个shard，不带副本，使用默认的压缩算法，写入完成后merge成一个segment方便观察。

使用线上默认的配置，uuid存为不分词的字符串类型。创建如下索引：

首先写入100w不同的uuid，使用磁盘容量细节如下：

可以看到正排数据、倒排索引数据，列存数据容量占比几乎相同，正排数据和倒排数据还会存储Elasticsearch的唯一id字段，所以容量会比列存多一些。

35M的uuid存入Elasticsearch后，数据膨胀了3倍，达到了122.7mb。Elasticsearch竟然这么消耗资源，不要着急下结论，接下来看另一个测试结果。

我们写入100w一样的uuid，然后看看Elasticsearch使用的容量。

这回35M的数据Elasticsearch容量只有13.2mb，其中还有主要的占比还是Elasticsearch的唯一id，100w的uuid几乎不占存储容积。

所以在Elasticsearch中建立索引的字段如果基数越大(count distinct)，越占用磁盘空间。

我们再看看存100w个不一样的整型会是如何。

从结果可以看到，100w整型数据，Elasticsearch的存储开销为13.6mb。如果以int型计算100w数据的长度的话，为400w字节，大概是3.8mb数据。忽略Elasticsearch唯一id字段的影响，Elasticsearch实际存储容量跟整型数据长度差不多。

我们再看一下开启最佳压缩参数对存储空间的影响：

结果中可以发现，只有正排数据会启动压缩，压缩能力确实强劲，不考虑唯一id字段，存储容量大概压缩到接近50%。

我们还做了一些实验，Elasticsearch默认是开启_all参数的，_all可以让用户传入的整体json数据作为全文检索的字段，可以更方便的检索，但在现实场景中已经使用的不多，相反会增加很多存储容量的开销，可以看下开启_all的磁盘空间使用情况：

开启_all比不开启多了40mb的存储空间，多的数据都在倒排索引上，大约会增加30%多的存储开销。所以线上都直接禁用。

然后我还做了其他几个尝试，为了验证存储容量是否和数据量成正比，写入1000w数据的uuid，发现存储容量基本为100w数据的10倍。我还验证了数据长度是否和数据量成正比，发现把uuid增长2倍、4倍，存储容量也响应的增加了2倍和4倍。在此就不一一列出数据了。

文件名为：segments_xxx

该文件为lucene数据文件的元信息文件，记录所有segment的元数据信息。

该文件主要记录了目前有多少segment，每个segment有一些基本信息，更新这些信息定位到每个segment的元信息文件。

lucene元信息文件还支持记录userData，Elasticsearch可以在此记录translog的一些相关信息。

文件后缀：.si

每个segment都有一个.si文件，记录了该segment的元信息。

segment元信息文件中记录了segment的文档数量，segment对应的文件列表等信息。

文件后缀：.fnm

该文件存储了fields的基本信息。

fields信息中包括field的数量，field的类型，以及IndexOpetions，包括是否存储、是否索引，是否分词，是否需要列存等等。

文件后缀：.fdx, .fdt

索引文件为.fdx，数据文件为.fdt，数据存储文件功能为根据自动的文档id，得到文档的内容，搜索引擎的术语习惯称之为正排数据，即doc_id - content，es的_source数据就存在这

索引文件记录了快速定位文档数据的索引信息，数据文件记录了所有文档id的具体内容。

索引后缀：.tip,.tim

倒排索引也包含索引文件和数据文件，.tip为索引文件，.tim为数据文件，索引文件包含了每个字段的索引元信息，数据文件有具体的索引内容。

5.5.0版本的倒排索引实现为FST tree，FST tree的最大优势就是内存空间占用非常低 ，具体可以参看下这篇文章：

;cmd=Build+it 为FST图实例，可以根据输入的数据构造出FST图

生成的 FST 图为:

文件后缀：.doc, .pos, .pay

.doc保存了每个term的doc id列表和term在doc中的词频

全文索引的字段，会有.pos文件，保存了term在doc中的位置

全文索引的字段，使用了一些像payloads的高级特性才会有.pay文件，保存了term在doc中的一些高级特性

文件后缀：.dvm, .dvd

索引文件为.dvm，数据文件为.dvd。

lucene实现的docvalues有如下类型：

其中SORTED_SET 的 SORTED_SINGLE_VALUED类型包括了两类数据 ： binary + numeric， binary是按ord排序的term的列表，numeric是doc到ord的映射。