第16篇-关于Elasticsearch的6件不太明显的事情

我的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件不太明显的事情
17.使用Python的初学者Elasticsearch教程
18.用ElasticSearch索引MongoDB,一个简单的自动完成索引项目
19.Kibana对Elasticsearch的实用介绍
20.不和谐如何索引数十亿条消息
21.使用Django进行ElasticSearch的简单方法

另外Elasticsearch入门，我强烈推荐ElasticSearch新手搭建手册和这篇优秀的REST API设计指南 给你，这两个指南都是非常想尽的入门手册。

 

 

Elasticsearch是被广泛采用的搜索引擎。Netflix，Microsoft，eBay，Facebook等大公司都在使用它。开始工作很容易，但从长远来看却很难掌握。在本文中，我们分享了有关Elasticsearch的六个不太明显的知识，值得在您的系统中使用它之前了解。

1.弹性堆叠
Elasticsearch最初是作为独立产品开发的。它的唯一作用是提供可扩展的搜索引擎，该引擎可以从任何语言使用。因此，它是使用分布式模型在最核心的地方创建的，并使用REST API与之通信。
在早期采用阶段之后，发明了新工具来与Elasticsearch一起使用。它从用于可视化和数据分析的Kibana和用于日志收集的Logstash开始。当前有许多工具都是在Elastic公司的照顾下开发的：

1. Elasticsearch-您知道，对于搜索，
2. Kibana-数据分析和可视化，
3. Logstash-服务器端数据处理管道，
4. 节拍-单一用途的数据托运人，
5. Elastic Cloud-托管Elasticsearch集群，
6. 机器学习-用于发现数据模式，
7. APM —应用程序性能监控，
8. 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。

每个节点可以充当上面列出的一个或多个角色。协调角色由任何类型的节点完成。为了拥有仅协​​调节点，您必须禁用该节点上的所有其他角色。

现在是流行的问题。配置大型集群的首选方式是什么？以下是建议：

1. 三个主节点-不暴露于世界，并维护群集状态和群集设置，
2. 几个仅用于协调的节点-它们侦听外部请求，并充当整个集群的智能负载平衡器，
3. 多个数据节点-根据数据集需求，
4. 几个接收节点（可选）—如果您正在执行“接收管道”，并且希望减轻其他节点对预处理文档的影响。

具体数量取决于您的特定用例，并且必须根据性能测试确定大小。