坂田网站的建设,五星花园网站建设兼职,wordpress跟随插件,网站后台管理系统后缀Elasticsearch 全文检索的复杂性
为了理解为什么全文搜索是一个很难解决的问题#xff0c;让我们想一个例子。 假设你正在托管一个博客发布网站#xff0c;其中包含数亿甚至数十亿的博客文章#xff0c;每个博客文章包含数百个单词#xff0c;类似于 CSDN。
执行全文搜索… Elasticsearch 全文检索的复杂性
为了理解为什么全文搜索是一个很难解决的问题让我们想一个例子。 假设你正在托管一个博客发布网站其中包含数亿甚至数十亿的博客文章每个博客文章包含数百个单词类似于 CSDN。
执行全文搜索意味着任何用户都可以搜索 “java” 或 “学习编程” 之类的内容并且你需要在几毫秒内找出出现这些单词的所有博客文章。 不仅如此你还需要根据多种因素对这些博客文章进行评分例如这些单词在这些帖子中出现的频率或者每个帖子有多少拍手或评论或者你可能想在顶部显示最近写的帖子或者你可能想突出显示某些顶级内容创建者或者你可能想将这些单词出现在标题中的帖子放在更高的位置等等。
另外你知道用户可能会意外地犯错因此你需要处理这个问题。 你还需要考虑单词的顺序“学习 Java” 应该与 “Java 学习” 具有相似的含义但有时顺序会更重要例如 “二氧化碳” 可能与 “化碳二氧” 有很大不同 ”这只是一个例子我不知道这是不是一个词我不懂化学。
仅仅匹配单词也是行不通的。 有些词比其他词为帖子提供了更多的上下文。 例如当用户搜索 “Java” 时标题为 “学习 Java” 的博客文章是相关结果但当用户仅搜索 “学习” 时相关性就不那么高了。 当用户搜索 “编程” 时这也是一篇相关的博客文章即使该词从未出现在博客文章中
这些挑战极其复杂乍一看它们似乎几乎无法搜索但你打开一个订餐应用程序在数千家餐厅的数万种菜肴中进行搜索或者搜索执行特定工作的人员 每天在 Linkedin 上数亿用户中发挥作用或在数十亿博客文章中搜索特定主题。
Elasticsearch 是一个旨在解决这个问题的数据库。 让我们看看它是如何工作的。 理解术语
在开始使用 Elasticsearch 之前我们应该先熟悉一下术语。 为了更好地理解事情让我们举个例子。 假设你在 Elasticsearch 上存储博客文章。 Nodes
节点只是单独的 Elasticsearch 进程。 通常你会在每台机器上运行一个 Elasticsearch 进程因此更容易将它们视为单独的服务器。 这些进程中的每一个都独立于其他进程运行并且仅通过公共网络连接。 Elasticsearch 通常作为大型分布式系统运行这意味着你通常会运行多台机器或节点。 一旦所有这些节点一起运行它们就可以形成一个“集群 (cluster)”。 集群不仅仅是各个部分的总和 它不仅仅是一定数量的孤立运行的节点。 相反节点知道它们是集群的一部分并在执行不同操作时相互通信。 在某种程度上Elasticsearch 集群是一个全新的实体。
Elasticsearch 集群有大量的职责例如存储文档、搜索这些文档、执行不同的分析和聚合任务、备份数据等。它还必须进行自我管理例如确保哪些节点是健康的哪些节点是健康的 因此在任何大型集群中为不同的操作域提供不同的节点非常重要。
虽然可能存在许多这样的区别但其中一个明显的区别是存储数据并执行繁重的数据密集型任务的节点例如搜索和拥有管理集群的专用节点、确保节点健康、决定将哪个文档发送到哪个节点等。创建这种区别很重要因为这些节点甚至可能需要不同的硬件资源。 数据节点可能需要更大的机器具有更高性能的网络和磁盘以及大量内存而执行更多管理任务的节点可能有完全不同的要求。
存储数据和搜索的节点可以是 “数据 (data)” 节点执行更多管理任务的节点可以称为 “主 (master)” 节点。 有关节点的更多描述请阅读文章 “Elasticsearch 中的一些重要概念: cluster, node, index, document, shards 及 replica”。事实上除了 data 及 master 节点之外Elasticsearch 还有其它类型的节点。 索引和文档
文档是你存储在 Elasticsearch 中的简单 JSON 对象。 它们与关系数据库中的行或 MongoDB 中的单个文档同义。
对于我们的示例单个文档可能如下所示 -
{_id: 9a91473c-522e-4174-bf7f-f55293b8e526,post_title: Learning about Elasticsearch,author_name: Zhang san,.....
}
索引是相似文档的集合。 它们与关系数据库中的表其中每一行都是单个项目和 MongoDB 中的集合同义。
因此对于我们的示例我们将有一个存储博客文章的索引。 我们称之为 blog_posts。 如果我们想存储一些其他数据比如说用户我们可以创建另一个索引用户。 blog_posts 索引存储各种博客文章文档每个文档都包含与博客文章相关的字段而 users 索引存储包含 user_name、email 等字段的用户文档。 Shards - 分片
索引中的文档被分为多个分片。 每个分片存储索引文档的某个子集。 稍后我们会理解为什么将文档划分为多个分片很重要但现在我们先关注分片的工作原理。
例如假设我们有一些 blog_posts 文档。 如果我们为此索引创建三个分片例如分片 A、分片 B、分片 C那么我们所有的文档都将分为这三个分片。 然后这些分片将驻留在集群中的不同数据节点中。 这很重要因为将这些文档分布到多个分片中可以为你带来多种优势
搜索可以并行化。 当用户想要执行搜索时将搜索所有文档。 如果在单个服务器上搜索所有文档这将非常耗时。 分片允许你将文档分布在多个服务器上从而允许在不同的硬件上并行执行单个搜索。其他查询例如插入文档在 Elasticsearch 中称为索引或通过特定 ID 检索文档将分布在所有节点之间。
然而我们的架构仍然不完整。 如果一个节点死亡它存储的分片以及这些分片上的数据将永远丢失。
让我们看看主分片 (primary shard) 和副本分片 (replica shard) 以更好地理解这一点。 主分片、副本分片和不同分片distinct shards
只是对到目前为止我们已经介绍过的内容的快速修订单个分片包含多个文档。 例如 每个分片都位于一个特定的节点上 到目前为止我们架构的一个问题是如果某个特定节点假设 10.192.0.3挂掉或变得不可用“分片 A”中的数据将永远丢失。 为了解决这个问题我们引入 “副本分片” 和 “主分片” 的概念。 主分片是我们到目前为止一直在讨论的分片现在将它们标记为“主Primary” 副本分片 (replica shards) 是仅存储主分片与存储关联的相同文档的分片。 因此副本分片只是 “复制” 或复制特定的主分片。 在上图中你可以看到每个主分片都有一个关联的副本分片并且每个副本分片存储与主分片相同的文档。 在这里我们每个主分片有一个副本分片但我们也可以将这个数字修改为更大 —— 每个主分片可以有两个副本。 现在我们继续每个主分片一个副本。
这些副本分片不需要与主分片位于同一节点上每个副本位于与其主分片不同的节点上是有意义的。 主分片和副本分片都分布在集群的所有节点上。 在上图中每个分片的主分片和副本分片存在于不同的节点上。 单节点故障不会导致数据不可用。 例如如果节点 10.192.0.3 不可用则分片 A 和分片 B 的数据都不会丢失。 分片 A 的数据在节点 10.192.0.2 上仍然可用同样分片 B 的数据在节点 10.192.0.1 上仍然可用。
这意味着我们的集群可以在单个节点丢失的情况下幸存下来。 然而我们的集群可能无法在失去两个节点的情况下幸存下来。 例如10.192.0.3 和10.192.0.2 节点同时丢失将导致分片 A 的文档完全不可用。 我们可以配置更高的复制例如每个主分片使用两个副本来缓解这种情况。 但现在我们继续每个主分片一个副本。
最后我们来看看 “不同分片distinct shards”。 不同分片只是一个术语用于将相同的主分片和副本分组在一起。 因此在我们当前的示例中我们有三个主分片、三个副本分片每个主分片 1 个副本、六个总分片三个主分片 三个副本和三个不同的分片 将主分片及其相应的副本分片分组为单个 “不同分片” 如此重要的原因将会变得清晰。 重申一下“不同分片” 只是分片的逻辑分组并且确实影响了我们到目前为止所绘制的架构。 我们来看几个真实的查询示例
为了结束架构讨论让我们看看搜索查询和获取查询在我们的示例集群中如何工作。 第一步…
让我们看看执行搜索或获取查询时会发生什么。
这就是我们集群现在的样子 客户端 API 向这些节点中的任何一个发送搜索或获取查询。 它发送查询的节点成为 “协调器coordinator” 节点。 更大的集群甚至可能有专用的协调器节点专用协调器节点是不具有任何节点角色的节点它只可以接收客户端的请求但我们现在不需要这样做。在文章的开始部分我们可以看到一个更为详细的架构图。 该协调器节点负责接收请求、与其他节点通信如果需要、组合从多个节点接收到的结果并返回结果。 搜索
搜索时搜索查询必须命中所有不同的分片。 这是因为所有分片都使用它们所保存的文档单独在本地执行搜索。
然后协调器节点将与多个节点通信以从每个不同的分片获取数据。 回想一下在我们的示例中每个主分片有一个副本因此查询仅命中集群中的一半分片主分片或副本分片。 有关详细的如何完成一个请求请阅读文章 “Elasticsearch数据是如何被读取的”。 根据 id 来进行查询
当通过 ID 对特定文档执行查询时协调器节点已经知道哪个分片将保存该文档因此无需命中所有节点。 它只是将请求转发到存储数据的节点并将响应发送回客户端。这是因为每当一个文档进来后根据文档的 id 会自动进行 hash 计算并存放于计算出来的 shard 实例中这样的结果可以使得所有的 shard 都比较有均衡的存储而不至于有的 shard 很忙。
shard_num hash(_routing) % num_primary_shards
我们可以根据文档的 id 来计算出来是哪一个 shard。 结论
这是对 Elasticsearch 架构的非常简单的介绍。希望大家能对 Elasticsearch 的集群架构有一个比较清楚的认识。更多关于 Elasticsearch 的术语及概念介绍请详细阅读文章 “Elasticsearch 中的一些重要概念: cluster, node, index, document, shards 及 replica”。
