Elasticsearch-分布式搜索引擎

朱雀 2021-09-21 11:30 587阅读 0赞

微信搜索：“二十同学” 公众号，欢迎关注一条不一样的成长之路

分布式搜索引擎技术——Elasticsearch

1. Elasticsearch是什么？

Elasticsearch是一个基于Apache Lucene(TM)的开源的高扩展的分布式搜索引擎 。

它可以做什么:

  • 分布式实时文件存储，并将每一个字段都编入索引，使其可以被搜索。
  • 实时分析的分布式搜索引擎。
  • 可以扩展到上百台服务器，处理PB级别的结构化或非结构化数据。

什么时候要用它：

  1. 搜索的数据对象是大量的非结构化的文本数据。
  2. 文件记录量达到数十万或数百万个甚至更多。
  3. 支持大量基于交互式文本的查询。
  4. 需求非常灵活的全文搜索查询。
  5. 对高度相关的搜索结果的有特殊需求，但是没有可用的关系数据库可以满足。
  6. 对不同记录类型、非文本数据操作或安全事务处理的需求相对较少的情况。

2. Elasticsearch 核心概念

1） 近实时（NRT） Elasticsearch是一个接近实时的搜索平台。这意味着，往索引插入一个文档直到这个文档能够被搜索到有一个轻微的延迟（通常是1秒）。

2） 集群（cluster） 集群由一个或多个节点组成，当有多个节点时，其中有一个为主节点，这个主节点是可以通过选举产生的，主从节点是对于集群内部来说的。es的一个概念就是去中心化，字面上理解就是无中心节点，这是对于集群外部来说的，因为从外部来看es集群，在逻辑上是个整体，你与任何一个节点的通信和与整个es集群通信是等价的。

3） 节点（node） 运行了单个实例的ES主机称为节点，它是集群的一个成员，可以存储数据、参与集群索引及搜索操作。类似于集群，节点靠其名称进行标识，默认为启动时自动生成的随机Marvel字符名称。用户可以按需要自定义任何希望使用的名称，但出于管理的目的，此名称应该尽可能有较好的识别性。节点通过为其配置的ES集群名称确定其所要加入的集群。

4）分片（shards） 代表索引分片，es可以把一个完整的索引分成多个分片（shards），这样的好处可以横向扩展，存储更多数据，让搜索和分析等操作分布到多台服务器上去执行，提升吞吐量和性能。分片的数量只能在索引创建前指定，并且索引创建后不能更改。

5）副本（replica） 任何一个服务器随时可能故障或宕机，此时shard可能就会丢失，因此可以为每个shard创建多个replica副本。replica可以在shard故障时提供备用服务，保证数据不丢失，多个replica还可以提升搜索操作的吞吐量和性能。primary shard（建立索引时一次设置，不能修改，默认5个），replica shard（随时修改数量，默认1个），默认每个索引10个shard，5个primary shard，5个replica shard，最小的高可用配置，是2台服务器。

6）索引 (index) 包含一堆有相似结构的文档数据，比如可以有一个用户信息索引，商品信息索引，订单信息索引等，一个索引由一个名字来标识（必须全部是小写字母的），并且当我们要对对应于这个索引中的文档进行索引、搜索、更新和删除的时候，都要使用到这个名字。索引类似于关系型数据库中Database的概念。在一个集群中，如果你想，可以定义任意多的索引。

7）类型（type） 每个索引里都可以有一个或多个type，type是index中的一个逻辑数据分类，一个type下的document，都有相同的field，比如博客系统，有一个索引，可以定义用户数据type，博客数据type，评论数据type等。类型类似于关系型数据库中Table的概念。

8）文档（document） document是es中的最小数据单元，一个document可以是一条客户数据，一条商品分类数据，一条订单数据，通常用JSON数据结构表示，每个index下的type中，都可以去存储多个document。一个document里面有多个field，每个field就是一个数据字段。

和关系型数据库的简单对应




























关系型数据库 Elasticsearch
DataBase Index
Table Type
ROW Document
Column Field
Schema Mapping

注意：在Elasticsearch6.x版本中，不建议使用type，而且在7.X版本中将会彻底废弃type

为何要去除 type 的概念？

主要因为 Elasticsearch 设计初期，是直接查考了关系型数据库的设计模式，存在了 type（数据表）的概念。但是，其搜索引擎是基于 Lucene 的，这种 “基因”决定了 type 是多余的。 Lucene 的全文检索功能之所以快，是因为 倒序索引 的存在。而这种 倒序索引 的生成是基于 index 的，而并非 type。多个type 反而会减慢搜索的速度。

3. Elasticsearch特点

提供强大的索引能力，一切设计都是为了提高搜索的性能

  • 分布式实时文件存储，可将每一个字段存入索引，使其可以被检索到。
  • 实时分析的分布式搜索引擎。
  • 可以扩展到上百台服务器，处理PB级别的结构化或非结构化数据。也可以运行在单台PC上

  • 支持插件机制，分词插件、同步插件、Hadoop插件、可视化插件等。

    分布式：索引分拆成多个分片，每个分片可有零个或多个副本。

    集群中的每个数据节点都可承载一个或多个分片，并且协调和处理各种操作；

    负载再平衡和路由在大多数情况下自动完成。

4.Elasticsearch是如何做到快速索引的

关键的：倒排索引

倒排索引（Inverted Index）也叫反向索引，有反向索引必有正向索引。通俗地来讲，正向索引是通过key找value，反向索引则是通过value找key。

简单了解一些概念：

Term（单词）：一段文本经过分析器分析以后就会输出一串单词，这一个一个的就叫做Term（直译为：单词）

Term Dictionary（单词字典）：顾名思义，它里面维护的是Term，可以理解为Term的集合

Term Index（单词索引）：为了更快的找到某个单词，我们为单词建立索引

Posting List（倒排列表）：倒排列表记录了出现过某个单词的所有文档的文档列表及单词在该文档中出现的位置信息，每条记录称为一个倒排项(Posting)。根据倒排列表，即可获知哪些文档包含某个单词。

一个倒排索引由文档中所有不重复词的列表构成，对于其中每个词，有一个包含它的文档列表。

例如，假设我们有两个文档，每个文档的 content 域包含如下内容：

  1. The quick brown fox jumped over the lazy dog
  2. Quick brown foxes leap over lazy dogs in summer

为了创建倒排索引，我们首先将每个文档的 content 域拆分成单独的 词（我们称它为 词条 或 tokens），创建一个包含所有不重复词条的排序列表，然后列出每个词条出现在哪个文档。结果如下所示：

  1. Term      Doc_1  Doc_2
  2. -------------------------
  3. Quick   |       |  X
  4. The     |   X   |
  5. brown   |   X   |  X
  6. dog     |   X   |
  7. dogs    |       |  X
  8. fox     |   X   |
  9. foxes   |       |  X
  10. in      |       |  X
  11. jumped  |   X   |
  12. lazy    |   X   |  X
  13. leap    |       |  X
  14. over    |   X   |  X
  15. quick   |   X   |
  16. summer  |       |  X
  17. the     |   X   |
  18. ------------------------

现在，如果我们想搜索 quick brown ，我们只需要查找包含每个词条的文档：

  1. Term      Doc_1  Doc_2
  2. -------------------------
  3. brown   |   X   |  X
  4. quick   |   X   |
  5. ------------------------
  6. Total   |   2   |  1

两个文档都匹配，但是第一个文档比第二个匹配度更高。如果我们使用仅计算匹配词条数量的简单 相似性算法 ，那么，我们可以说，对于我们查询的相关性来讲，第一个文档比第二个文档更佳。

但是，我们目前的倒排索引有一些问题：

  • Quick 和 quick 以独立的词条出现，然而用户可能认为它们是相同的词。
  • fox 和 foxes 非常相似, 就像 dog 和 dogs ；他们有相同的词根。
  • jumped 和 leap, 尽管没有相同的词根，但他们的意思很相近。他们是同义词。

使用前面的索引搜索 +Quick +fox 不会得到任何匹配文档。（记住，+ 前缀表明这个词必须存在。）只有同时出现 Quick 和 fox 的文档才满足这个查询条件，但是第一个文档包含 quick fox ，第二个文档包含 Quick foxes 。

我们的用户可以合理的期望两个文档与查询匹配。我们可以做的更好。

如果我们将词条规范为标准模式，那么我们可以找到与用户搜索的词条不完全一致，但具有足够相关性的文档。例如：

  • Quick 可以小写化为 quick 。
  • foxes 可以 词干提取 —变为词根的格式— 为 fox 。类似的， dogs 可以为提取为 dog 。
  • jumped 和 leap 是同义词，可以索引为相同的单词 jump 。

现在索引看上去像这样：

  1. Term      Doc_1  Doc_2
  2. -------------------------
  3. brown   |   X   |  X
  4. dog     |   X   |  X
  5. fox     |   X   |  X
  6. in      |       |  X
  7. jump    |   X   |  X
  8. lazy    |   X   |  X
  9. over    |   X   |  X
  10. quick   |   X   |  X
  11. summer  |       |  X
  12. the     |   X   |  X
  13. ------------------------

这还远远不够。我们搜索 +Quick +fox 仍然 会失败，因为在我们的索引中，已经没有 Quick 了。但是，如果我们对搜索的字符串使用与 content 域相同的标准化规则，会变成查询 +quick +fox ，这样两个文档都会匹配！

发表评论

表情：
评论列表 （有 0 条评论，587人围观）

还没有评论，来说两句吧...

相关阅读