共计 4054 个字符，预计需要花费 11 分钟才能阅读完成。
我的 Elasticsearch 系列文章，逐渐更新中，欢迎关注
0A. 关于 Elasticsearch 及实例应用
00.Solr 与 ElasticSearch 对比
01.ElasticSearch 能做什么？
02.Elastic Stack 功能介绍
03. 如何安装与设置 Elasticsearch API
04. 如果通过 elasticsearch 的 head 插件建立索引_CRUD 操作
05.Elasticsearch 多个实例和 head plugin 使用介绍
06. 当 Elasticsearch 进行文档索引时，它是如何工作的?
07.Elasticsearch 中的映射方式—简洁版教程
08.Elasticsearch 中的分析和分析器应用方式
09.Elasticsearch 中构建自定义分析器
10.Kibana 科普 - 作为 Elasticsearhc 开发工具
11.Elasticsearch 查询方法
12.Elasticsearch 全文查询
13.Elasticsearch 查询 - 术语级查询
14.Python 中的 Elasticsearch 入门
15. 使用 Django 进行 ElasticSearch 的简单方法
第 16 篇 - 关于 Elasticsearch 的 6 件不太明显的事情
另外 Elasticsearch 入门，我强烈推荐 ElasticSearch 搭建手册给你，非常想尽的入门指南手册。
Elasticsearch 是被广泛采用的搜索引擎。Netflix，Microsoft，eBay，Facebook 等大公司都在使用它。开始工作很容易，但从长远来看却很难掌握。在本文中，我们分享了有关 Elasticsearch 的六个不太明显的知识，值得在您的系统中使用它之前了解。
1. 弹性堆叠
Elasticsearch 最初是作为独立产品开发的。它的唯一作用是提供可扩展的搜索引擎，该引擎可以从任何语言使用。因此，它是使用分布式模型在最核心的地方创建的，并使用 REST API 与之通信。
在早期采用阶段之后，发明了新工具来与 Elasticsearch 一起使用。它从用于可视化和数据分析的 Kibana 和用于日志收集的 Logstash 开始。当前有许多工具都是在 Elastic 公司的照顾下开发的：
- Elasticsearch- 您知道，对于搜索，
- Kibana- 数据分析和可视化，
- Logstash- 服务器端数据处理管道，
- 节拍 - 单一用途的数据托运人，
- Elastic Cloud- 托管 Elasticsearch 集群，
- 机器学习 - 用于发现数据模式，
- APM —应用程序性能监控，
- Swiftype- 一键式站点搜索。
工具的数量每年都在增长，这使公司能够实现新的目标并创造新的机会。
2. 两种数据集
基本上，您可以在 Elasticsearch 中索引（即存储）所需的任何数据。但是实际上有两类，它们严重影响了群集的配置和管理方式：静态数据和时间序列数据。
静态数据是可能增长或变化缓慢的数据集。像目录或物品清单。您可以将它们视为存储在常规数据库中的数据。博客文章，图书馆书籍，订单等。您可能希望在 Elasticsearch 中对此类数据编制索引，以实现快速的快速搜索，而这使常规 SQL 数据库不堪一击。
另一方面，您可以存储时间序列数据集。这些事件可以是与通常迅速增长的时间相关的事件，例如日志文件或指标。您基本上可以在 Elasticsearch 中为它们建立索引，以进行数据分析，模式发现和系统监视。
根据您存储的数据类型，应该以不同的方式对集群建模。对于静态数据，应选择固定数量的索引和分片。它们不会很快增长，并且您始终希望在数据集中的所有文档中进行搜索。
对于时间序列数据，您应该选择有时间限制的滚动索引。您将更多地查询最近的数据，最终甚至会删除或至少存档过时的文档，以节省机器成本。
3. 搜索分数
Elasticsearch 的主要目的是提供一个搜索引擎。目标是提供最匹配的文档。但是，Elasticsearch 实际上如何知道它们是什么？
对于每个搜索查询，Elasticsearch 都会计算相关性得分。分数基于 tf-idf 算法，该算法代表术语频率 - 反向文档频率。
该算法基本上计算出两个值。第一个 - 术语频率 - 表示文档中给定术语的使用频率。第二个参数是反文档频率，它表示给定术语在所有文档中的唯一性。
例如，如果我们有两个文档：
To be or not to be, that is the question.
To be. I am. You are. He, she is.问题一词的 TF 是
for document 1: 1/10 (1 occurrence out of 10 terms)
for document 2: 0/9 (0 occurrences out of 9 terms).另一方面，将 IDF 计算为整个数据集的单个值。它是所有文档与包含搜索词的文档的比率。
在我们的例子中是：
log（2/1）= 0.301（2- 所有文档数，1- 包含疑问词的文档数）。
最后，两个文档的 tf-idf 得分均作为两个值的乘积计算得出：
● 文件 1：1/10 x 0.301 = 0.1 * 0.301 = 0.03
● 文件 2：0/9 x 0.301 = 0 * 0.301 = 0.00
现在我们看到文档 1 的相关性值为 0.03，而文档 2 的相关性为 0.00。因此，文档 1 将在结果列表中提供更高的服务。
4. 数据模型
Elasticsearch 在性能方面有两个好处。它是水平可扩展的，并且非常快。后者来自哪里？它基于数据存储的事实。
当您为文档建立索引时，它将通过三个步骤：字符过滤器，标记生成器和标记过滤器。它们用于规范化文档。例如文档：
To be or not to be, that is the question. 可能实际存储为：
to be or not to be that is the question如果删除了标点符号并且所有术语都小写。
这还没有结束。它可以存储为
question如果应用停用词过滤器，该过滤器会删除所有常见语言术语，例如：to，be，或 not，即 the。
所以这是索引部分。但是，搜索文档时将应用相同的步骤。查询也将针对字符进行过滤，标记化并针对令牌进行过滤。然后，Elasticsearch 会搜索带有标准化术语的文档。Elasticsearch 中的字段存储在反向索引结构中，这使拾取匹配文档的速度非常快。
可以为每个字段定义特定的过滤器。定义分为称为分析器的结构。可以使用多个分析仪分析一个字段以实现不同的目标。例如，可以使用英语分析仪，德语分析仪等进行分析。然后在搜索阶段，您可以定义要扫描的字段类型，然后得到结果。
通过应用这种行为，ElasticSearch 可以比常规数据库更快地提供结果。
5. 分片规划
现在是新手最常问到的 Elasticsearch 问题。我应该有多少个碎片和索引？为什么会出现这个问题？只能在创建索引的开始就设置分片的数量。
因此，答案实际上取决于您拥有的数据集。经验法则是，分片应包含 20–40 GB 的数据。碎片来自 Apache Lucene（这是引擎盖下使用的搜索引擎）。考虑到 Apache Lucene 用于反向索引和快速搜索的所有结构以及开销，因此拥有小的碎片（如 100 MB 或 1 GB）毫无意义。
Elastic 顾问建议的大小为 20–40 GB。请记住，分片不能进一步划分，并且始终位于单个节点上。这样大小的分片也可以很容易地移动到其他节点，也可以在集群中复制（如果需要）。具有这种分片容量可以为您建议在速度和内存消耗之间进行权衡。
当然，在您的特定情况下，性能指标可能会有所不同，因此请记住，这只是一个建议，您可能希望实现其他性能目标。
为了知道每个索引应该有多少个分片，您可以简单地估算一下，方法是：将多个文档建立索引到一个临时索引中，并查看它们在一段时间内消耗了多少内存，以及您期望在其中拥有多少个内存。时间（在时间序列数据集中）或根本（在静态数据集中）。
不要忘记，即使您错误配置了分片或索引的数量，也始终可以将数据重新索引到设置了不同分片数量的新索引。
最后但并非最不重要的。您始终可以一次查询多个索引。例如，您可以为具有每日保留时间的基于日志的数据提供滚动索引，只需在一个查询中索要自上个月起的所有天数。查询具有 1 个分片的 30 个索引与查询具有 30 个分片的 1 个索引具有相同的性能影响。
6. 节点类型
Elasticsearch 节点可以扮演多个角色。默认情况下（这对小型集群很有用），它们可以为所有集群提供服务。我正在写的角色是：
● 主节点，
● 数据节点
● 摄取节点
● 仅协调节点。
每个角色都有其后果。主节点负责集群范围的设置和更改，例如创建或删除索引，添加或删除节点以及向节点分配分片。
每个群集至少应包含 3 个符合主机要求的节点，并且实际上不需要有更多的节点。从所有符合主机资格的节点中，一个被选为主节点，其作用是执行群集范围的操作。纯粹需要其他两个节点来实现高可用性。主节点对 CPU，RAM 和磁盘存储的要求较低。
数据节点用于存储和搜索数据。因此，它们对所有资源都有很高的要求：CPU，RAM 和磁盘。您拥有的数据越多，期望值就越高。
接收节点用于在实际建立索引之前对文档进行预处理。他们拦截批量查询和索引查询，应用转换，然后将文档传递回索引或批量 API。他们需要低磁盘，中 RAM 和高 CPU。
仅协调节点用作客户端请求的负载平衡器。他们知道特定文档可以驻留在哪里，并且仅向这些节点提供搜索请求。然后他们对接收到的结果执行分散和分类操作。对它们的要求是低磁盘，中或高 RAM 和中或高 CPU。
每个节点可以充当上面列出的一个或多个角色。协调角色由任何类型的节点完成。为了拥有仅协调节点，您必须禁用该节点上的所有其他角色。
现在是流行的问题。配置大型集群的首选方式是什么？以下是建议：
- 三个主节点 - 不暴露于世界，并维护群集状态和群集设置，
- 几个仅用于协调的节点 - 它们侦听外部请求，并充当整个集群的智能负载平衡器，
- 多个数据节点 - 根据数据集需求，
- 几个接收节点（可选）—如果您正在执行“接收管道”，并且希望减轻其他节点对预处理文档的影响。
具体数量取决于您的特定用例，并且必须根据性能测试确定大小。
