写在后面
有一个问题被关注的比拟少,就是 ES 对本地磁盘的占用状况。有人可能感觉这个问题的答案不言而喻,不就是 ES 软件自身占用的空间,还有索引数据长久化占用的磁盘空间,另外就是一些日志了。
事实上,对于 ES 占用磁盘空间的问题远比这个要简单的多。本篇文章就想聚焦这个问题,深刻 ES 的底层原理来剖析磁盘的占用状况。
注释
是否执行剖析
首先对于一个索引,其中的字段在写入是,写入剖析对磁盘是有影响的。那么什么是写入剖析? 当咱们 index 一个文档时,如果不指定分析器,默认应用的是standard
,能够做个测试,看下默认的分析器执行的后果。
GET /_analyze
{
"analyzer": "standard",
"text": "Text to analyze"
}
咱们能够为字段独自指定 analyzed
或者 not_analyzed
,比方:
PUT /my_index
{
"mappings": {
"my_type": {
"properties": {
"status_code": {
"type": "string",
"index": "not_analyzed"
}
}
}
}
}
- not_analyzed: 将字段的原始值放入索引中,作为一个独立的 term,它是除 string 字段以外的所有字段的默认值。
- analyzed:string 字段的默认值,会先进行剖析后,再把剖析的 term 后果存入索引中。
剖析的目标次要是为了建设倒排索引,进行全文检索剖析。如果没有这个需要能够关掉。
_all 字段和_source 字段
很多时候,咱们查问文档会发现返回的后果里,带有一个 _source
字段,外面是全副字段的内容。_source
字段默认是存储的,这个会占用磁盘空间。
什么状况下不必保留 _source
字段?比方如果某个字段内容十分多,咱们的业务场景只须要能对该字段进行搜寻,能够思考敞开 _source
字段,咱们搜寻到文档 id 后,再通过文档 id 去数据库拿到这个字段的内容。这样能够节俭很多空间。如何敞开呢?
PUT my-index-000001
{
"mappings": {
"_source": {"enabled": false}
}
}
_all
字段默认是敞开的,如果要开启 _all
字段,索引就更大,占用磁盘空间当然就更大。_all
字段开启实用于不指定搜寻某一个字段,依据关键词,搜寻整个文档内容。
Doc values
Doc Values 通过序列化把数据结构长久化到磁盘,咱们能够充分利用操作系统的内存,而不是 JVM 的 Heap。
Doc Values 默认对所有字段启用,除了 analyzed strings。也就是说所有的数字、地理坐标、日期、IP 和不剖析(not_analyzed)字符类型都会默认开启。
Doc Values 的作用是开启的字段能够反对排序,聚合等能力,如果业务场景确定不须要这样的能力能够显示的把这个性能禁掉,从而节俭磁盘空间。
PUT my_index
{
"mappings": {
"my_type": {
"properties": {
"session_id": {
"type": "string",
"index": "not_analyzed",
"doc_values": false
}
}
}
}
}
正本机制
这个其实不必多说。ES 的正本分片机制,目标是实现高可用,然而就义了空间。每个正本其实都是主分片的残缺拷贝,在文档数量十分大的时候,这个对磁盘的占用是相当可观的。
测试比照
看上图,从上往下看,磁盘占用根本是始终在缩小。很直观的看出下面讲的那些因素对 ES 磁盘的占用影响。
参考:
- https://www.elastic.co/cn/blo…