本章内容
如何选择正确的目录实现，使得ElasticSearch能够以高效的方式访问底层I/O系统。
如何配置发现模块来避免潜在的问题。
如何配置网关模块以适应我们的需求。
恢复模块能带来什么，以及如何更改它的配置。
如何查看段信息。
ElasticSearch的缓存是什么样的，它的职责是什么，如何使用以及更改它的配置。
存储模块是一个在配置集群时容易被忽视的模块，然而它非常重要。该模块允许用户控制索引的存储方式，例如，可以持久化存储(存储在磁盘上)或非持久化存储(存储在内存中)。
存储类型
ElasticSearch提供了4种可用的存储类型。通过index.store.type属性进行设置：
内存存储（memory）
内存存储是唯一一个不是基于Apache Lucene目录的存储类型，它允许我们把全部索引都保存在内存中，因此文件并没有存储在硬盘上。
当使用内存存储类型（memory）时，我们也能在一定程度上控制缓存，这一点非常重要。注意以下设置都是节点级别的:
cache.memory.direct:定义内存存储是否应该被分配到Java虚拟机堆内存之外，默认为true。一般情况下应该保持为默认值，从而能避免堆内存过载。
cache.memory.small_buffer_size:定义小缓冲区的大小，默认值是1KB。小缓冲区是用来容纳段(segment )信息和已删除文档信息的内部内存结构。
cache.memory.large_buffer_size:定义大缓冲区的大小，默认值是1MB。大缓冲区是用来容纳除段信息和已删除文档信息外的索引文件的内部内存结构。
cache.mernory.small_cache_size:定义小缓存的大小，默认值是10MB。小缓存是用来缓存段信息和已删除文档信息的内部内存结构。
cache.memory.large_cahce_size:定义大缓存的大小，默认值是500MB。大缓存是用来缓存除段信息和已删除文档信息外的索引文件的内部内存结构。
为为知笔记建立本地索引，使用内存存储是很不错的选择。
默认存储类型
ElasticSearch默认使用基于文件系统的存储类型。虽然针对不同的操作系统往往会选择不同的存储类型，但终究都使用了基于文件系统的存储类型。例如，ElasticSearch在32位的Windows系统上使用simplefs类型，在Solaris和64位的Windows系统上使用mmapfs，其他系统则使用niofs。
Zen发现(Zen discovery)是ElasticSearch自带的默认发现机制。Zen发现默认使用 多播来发现其他的节点。
有时多播会由于各种原因而失效，或者在一个大型集群中使用多播发现会产生大量不 必要的流量，这可能都是不想使用多播的合理理由。在这些情况下，Zen发现使用了第二种发现方法:单播模式。
多播
前面提到过，多播(Multicast)这是ElasticSearch的默认模式。当节点还没有加人任何集群时(如节点刚刚启动或重启)，它会发出一个多播的ping请求，这相当于通知所有可见的节点和集群，它已经可用并准备好加入集群了。
Zen发现模块的多播部分有如下设置:
单播
像前面描述的那样关闭了多播后，你就可以安全地使用单播(Unicast)了。当节点不是集群中的一部分时(如刚刚重启，启动或由于某些故障脱离集群)，它会发送一个ping请求给配置文件所指定的那些地址，通知所有的节点它准备好要加人集群了。
单播的配置非常简单，如下所示:
一般来说，单播发现的主机列表不需要是集群中所有ElasticSearch节点的完整列 表，因为新节点一旦与列表中任何一个节点相连，就会知晓组成集群的其他全部节点的信息。
最小主节点数
对发现模块来说，一个最重要的属性是discovery.zen.minimum_master_nodes属性。它 允许我们设置构建集群所需的最小主节点(master node)候选节点数。这让我们避免了由于某些错误(如网络问题)而出现令人头疼的局面(即多个集群同名)。
Zen发现错误检测
ElasticSearch在工作中执行两个检测流程。第一个流程是由主节点向集群中其他节点 发送ping请求来检测它们是否工作正常。第二个流程刚好相反，由每个节点向主节点发送请求来验证主节点是否正在运行并能履行其职责。然而，如果网络速度很慢，或者节点部署在不同的地点，那么默认的配置也许就不合适了。
因此ElasticSearch的发现模块提供了以下可以修改的设置:
可配置的属性
ElasticSearch 的节点可以扮演不同的角色，它们可以作为数据节点(存储数据的节点)，也可以作为主节点，其中主节点(一个集群中只有一个)除了处理查询请求外，还负责集群管理。当然节点也可以配置为既不是主节点也不是数据节点，在这种情形下，该节点将只作为执行用户查询的聚合节点。ElasticSearch默认每个节点都是数据节点和候选主节点，但是这是可以改变的。为了取消某节点的主节点候选资格，你需要在elasticsearch.yml文件中将node.master属性设为false。为了让某节点成为非数据节点，你需要在elasticsearch.yml文件中将node.data属性设为false。
除此之外，ElasticSearch还允许我们使用下面的属性来控制网关模块的行为:
随着Elasticsearch 0.2。版(以及0.19的某些版本)的发布，除了默认的本地类型，其他类型的网关都已弃用，并建议不再使用，因为在新版的Elasticsearch中，它们都会被移除。如果要避免重新索引全部数据，那么你应当使用本地网关类型，这也是为什么我们不讨论其他网关类型的原因。
本地网关类型使用节点上可用的本地存储来保存元数据、映射和索引。为了使用本地网关，需要有充足的磁盘空间来容纳数据(数据全部写人磁盘，而非保存在内存缓存中)。
本地网关的持久化不同于其他当前存在(但是已经弃用)的网关类型。向本地网关的写操作是以同步的方式进行的，以确保在写人过程中没有数据丢失。
默认
gateway.type=local
备份本地网关
例如当升级集群时，希望出错后能够进行回滚。为了实现这个目的，你需要执行下面的操作:
集群级的恢复配置
恢复配置大多针对的是集群级别，它允许我们设置恢复模块使用的通用规则，可设置 以下属性:
Note
所有前面提到过的设置都可以通过集群的更新API来更新，或者在elasticsearch.yml文 件里设置。
为了深人观察Lucene索引段，ElasticSearch提供了segments API，我们可以通过向 _segments REST端点发送HTTP GET请求来访问它。例如，要查看集群中所有索引的所有段信息，应当执行下面的命令:
curl -XGET 'localhoat:9200/_segments'curl -XGET 'localhoat:9200/mastering/_segments'
在本节中，我们将重点了解过滤器缓存和字段数据缓存 。
过滤器缓存是负责缓存查询中使用的过滤器的执行结果的。 如以下查询： 
过滤器缓存的种类
在ElasticSearch中有两种类型的过滤器缓存:索引级和节点级，即我们可以选择配置索引级或节点级(默认选项)的过滤器缓存。
不建议索引级过滤器缓存
由于我们不一定能预知给定索引会分配到哪里 （实际上是指索引的分片和副本)，进而无法预测内存的使用，所以不建议使用索引级的过滤器缓存。
索引级过滤器缓存的配置
ElasticSearch允许我们使用下面的属性来配置索引级过滤器缓存的行为:
节点级的过滤器缓存配置
节点级过滤器缓存是默认的缓存类型，它应用于分配到给定节点上的所有分片(设置 index.cache.filter.type属性为node，或者不设置这个属性)。ElasticSearch允许我们使用indices.cache.filter.sixe属性来配置这个缓存的大小，既可以使用百分数。
节点级过滤器缓存是LRU类型(最近最少使用)缓存，这意味着为了给新记录腾出空 间，在删除缓存记录时，使用次数最少的那些会被删除。
字段数据缓存在我们的查询涉及切面计算或基于字段数据排序时使用。ElasticSearch所做的是加载相关字段的全部数据到内存中，从而使ElasticSearch能够快速地基于文档访问这些值。需要注意的是，从硬件资源的角度来看，构建字段数据缓存代价通常很高，因为字段的所有数据都需要加载到内存中，这需要消耗I/O操作和CPU资源。特别注意高基数的字段(拥有大量不同词项的字段)。
索引级字段数据缓存配置
不建议使用索引级字段数据缓存
与索引级过滤器缓存类似，我们并不建 议使用它。原因就是很难预测哪个分片或索引会分配到哪个节点上，因此我们无法预估缓存每个索引需要的内存大小，而这会带来内存使用方面的问题。
节点级字段数据缓存配置
过滤
除了前面提到的配置项以外，ElasticSearch还允许我们选择性地将某些字段值加载到 字段数据缓存中。这在某些情况下非常有用，尤其是在做基于字段数据排序或切面计算时。 ElasticSearch支持两种类型三种形式的字段数据过滤，即基于词频、基于正则表达式，以及基于两者的组合。
为了引人字段数据缓存过滤信息，需要在映射文件的字段定义部分额外添加两个对象: fielddata对象及其子对象filter。
基于词频过滤
{
"book":{
"properties":{
"tag":{
"type":"string",
"index":"not_analyzed",
"fielddata":{
"filter":{
"frequency":{
"min":0.01,
"max":0.2,
"min_segment_size":100
}
}
}
}
}
}
}基于正则表达式过滤
除了基于词频的过滤，也可以基于正则表达式过滤。这时只有匹配特定正则表达式的 词项会加载到字段数据缓存中。
{
"book":{
"properties":{
"tag":{
"type":"string",
"index":"not_analyzed",
"fielddata":{
"filter":{
"regex":"^#.*"
}
}
}
}
}
}基于词频过滤和基于正则表达式过滤同时使用
这是一种and的关系。同时符合这两种情况的词项才会被缓存。注意，没有被缓存的词项，在涉及切面计算或基于字段数据排序时是查不到的！要特别注意！
查询期间重建字段数据缓存
字段数据缓存虽然不是在索引期间构建的，但却可以在查询期间重建，于是我们可 以在运行时改变过滤行为，并具体通过使用映射API更新fielddata配置节来实现。 然而，需谨记在改变字段数据缓存过滤设置后清空缓存，这可以通过使用清理缓存 API来实现，详情可参考5.4.3节。
前面已经提到，在改变字段数据过滤以后需要清除缓存，这点很关键。
单一索引缓存、多索引缓存和全部缓存的清除
清空全部缓存的最简单的做法是执行下面的命令:
curl -XPOST 'localhoat:9200/_cache/clear'curl -XPOST 'localhoat:9200/mastering/_cache/clear'清除特定缓存
清除缓存除了前面提到的方法，我们也可以只清除一种指定类型的缓存。下面列出的 就是可以被单独清除的缓存类型:
例如，要清除mastering索引的字段数据缓存，并保留filter缓存和bloom缓存，则可 以执行下面的命令:
curl -XPOST 'localhost:9200/mastering/_cache/clear?field_data=true&filter=false&bloom=false'清除字段相关的缓存
除了清除全部或特定的缓存，我们还可以清除指定字段的缓存。为了实现这个，我 们需要的请求中增加fields参数，参数值为所要清除缓存的相关字段名，多个字段名用逗号分隔。例如，要清除mastering索引里title和price字段的缓存:
curl -XPOST 'localhost:9200/mastering/_cache/clear?fields=title,price'
京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有 