wangxuelei036的博客

1.主节点（Master node）　主节点的主要职责是负责集群层面的相关操作，管理集群变更，如创建或删除索引，跟踪哪些节点是群集的一部分，并决定哪些分片分配给相关的节点。主节点也可以作为数据节点，但稳定的主节点对集群的健康是非常重要的，默认情况下任何一个集群中的节点都有可能被选为主节点，索引数据和搜索查询等操作会占用大量的cpu，内存，io资源，为了确保一个集群的稳定，分离主节点和数据节点是一个比较好的选择。通过配置node.master:true(默认)使节点具有被选举为Master的资格.

下面本文将针对一些常规的地方讲诉一些优化技巧，主要从设计、通信、设备几个方面，涉及数据结构、磁盘I/O、CPU性能、网络通信开销、内存资源等

在ES的默认设置下，是综合考虑数据的可靠性，搜索实时性，写入速度等因素的。当离开默认设置，追求极致写入速度时，很多是以牺牲可靠性和搜索实时性为代价的。有时候，业务上对数据可靠性和搜索实时性要求不高，反而对写入速度要求很高，此时可以调整一些策略，最大化写入速度。综合来说可以从以下几个方面入手：加大translog flush间隔，目的是降低iops,writeblock (可靠性降低) 加大index refresh间隔，除了降低I/O，更重要的是降低segment merge频率 调整bulk

深度分页问题大致可以分为两类随机深度分页：随机跳转页面 滚动深度分页：只能一页一页往下查询本文得search After 处理的时滚动深度分页的问题在旧版本中，ES为深度分页有scroll search 的方式，官方的建议并不是用于实时的请求，因为每一个 scroll_id 不仅会占用大量的资源（特别是排序的请求），而且是生成的历史快照，对于数据的变更不会反映到快照上。这种方式往往用于非实时处理大量数据的情况，比如要进行数据迁移或者索引变更之类的。那么在实时情况下如果处理深度分页的问题呢？es

一个index的数据会被分为多片，每片都在一个shard中。所以说，一个document，只能存在于一个shard中。 当客户端创建document的时候，es此时就需要决定说，这个document是放在这个index的哪个shard上。 这个过程，就称之为document routing，数据路由。当ES散列文档的ID时 就会发生文档的路由，来决定文档应该索引到哪个分片中，这可以由你指定也可以让ES生成

深度分页问题大致可以分为两类随机深度分页：随机跳转页面滚动深度分页：只能一页一页往下查询

ES 打分机制也就是文档的相关性评价，确定文档和查询有多么相关的过程被称为打分（scoring）。尽管精确地理解Elasticsearch是如何计算文档得分这一点并不是必须的，但是对于如何适用ES来说，它仍然是非常有帮助的。

别名是索引之上得抽象，非常强大和灵活。别名的生命周期是存于集群状态之中，由主节点管理。这意味着，如果有一个称为idaho的别名，指向了名为土豆的索引，那么负载就是集群状态映射中额外的键，将名称idaho映射为具体的索引名称-土豆。这就意味着，和额外的索引相比，别名更加轻量级，维护数千个别名都不会负面地影响集群。不过，我们反对创建数十万甚至是上百万的别名，因为到了这个临界点，即使最小的单个映射条目都会引起集群状态膨胀为一个很大的规模。由于每次集群状态发生变化时，整个状态都需要发送到每个节点，所以创建一个新集群

TF-IDF算法介绍TF-IDF(term frequency–inverse document frequency)是一种用于信息检索与数据挖掘的常用加权技术。TF意思是词频(Term Frequency)，IDF意思是逆文本频率指数(Inverse Document Frequency)。TF-IDF是一种统计方法，用以评估一字词对于一个文件集或一个语料库中的其中一份文件的重要程度。字词的重要性随着它在文件中出现的次数成正比增加，但同时会随着它在语料库中出现的频率成反比下降。TF-IDF的主要

在Elasticsearch的早期版本中，过度的合并将会拖慢集群，以至于索引和搜索请求慢得无法接收，或者是所有得节点都无法响应，这都是因为合并时对I/O产生了压力，导致新分段得写入很缓慢。此外，由于I/O得等待，CPU得负载也会很高。因此，Elasticsearch使用了存储限流，来限制合并可以使用得I/O吞吐量。默认情况下有一个节点层级得设置，称为:indices.store.throttle.max_bytes_per_sec。这个限制在很多应用中对于稳定性很好，如果你有高速得机器和许多所有，即

ES的读取分为GET和Search两种操作，这两种读取操作有较大的差异，本章我们主要分析下GET/MGET读取操作。GET/MGET必须指定三元组：_index、_type、_id（http://127.0.0.1:9200/_index/_type/_id），也就是说，根据文档id从正排索引中获取内容。

每个软件应用为了方便排查运行时出现的问题或者一些做一些数据记录，都会提供相应的日志记录，Elasticsearch也不例外，Elasticsearch日志记录通过3类日志类型进行记录：（1）主要日志（cluster-name.log）:记录了Elasticsearch运行时所发生一切的综合信息，例如，某个查询失败或一个新的节点加入集群（2）慢搜索日志（cluster-name_index_search_slowlog.log）:当某个查询运行得很慢时，Elasticsearch会在这里进行记录。默认