关于elasticsearch:搜索引擎Elasticsearch简介实践

3次阅读

共计 4427 个字符,预计需要花费 12 分钟才能阅读完成。

前言

之前在寻找日志收集搜寻解决方案时,最常看到的便是 ELK:Elasticsearch + Logstash + Kibana 计划。只管因为它对服务器资源要求很高转而应用 了 Loki,但也对它初步钻研过。明天,就对其中的 Elasticsearch 深刻理解一番。

Elasticsearch 介绍

Elasticsearch 是一个开源的搜索引擎,咱们能够用它来解决文本、天文空间(如坐标)、结构化(如 DB 里的表)、非结构化(如报表、图片)等数据,而后通过简略的 REST API 对其搜寻。它的最大特点就在于 分布式 以及 实时速度,可部署到数百甚至上千台服务器上,以便咱们存储解决海量的数据,而且其速度依然能达到秒级。

它的底层应用的是 Apache Lucene。Apache Lucene 是一个高性能、功能强大的搜索引擎库,不过它只是一个库,须要应用 Java 能力集成到应用程序中。因而,Elasticsearch 对其进行了封装,屏蔽了底层的复杂性,对外只提供了简略的 RESTful API。

当 Elasticsearch 接管到像 Logstash 这种工具传输过去的数据后便会以文档的模式去剖析提取索引,压缩数据,按配置的分片规定将数据平均存储。在实现这些后,咱们就能够进行可视化查问了,例如应用 Kibana 面板查看。

因为 Elasticsearch 具备了易用性、实时剖析、全文搜寻、散布部署、高可用等个性,所以除了用来做日志的解决剖析外,还能够利用在平安剖析、指标剖析、性能监控等场景需要。

Elasticsearch 基本概念

文档(Document)

和传统的 DB 不一样,Elasticsearch 不是将数据存储为列式的二维表,而是
采纳 Json 格局存储每一条数据,即文档是以键值对存在的字段汇合。如下就能够是一条文档:

{
    "name":         "John Smith",
    "age":          42
}

咱们也能够把文档了解为根对象,每条文档都会由惟一 \_id 标识它,如果咱们在插入文档时没有指定 \_id,则 Elasticsearch 将会主动生成一个。

索引(Index)

Elasticsearch 之所以能进行实时搜寻,最重要的就在于拿到文档数据后会对 json 里的所有字段建设索引,而且依据字段的不同类型建设不同的索引数据结构,例如 text 类型的字段会建设倒排索引,而数字和天文类型的字段会存储在 BKD 树里。这里重点介绍下倒排索引。

有倒排就有正排,咱们先来看看正排索引,所谓的正排,咱们能够简略的认为间接依据文档 \_id 获取到文档内容,只有你晓得文档 \_id。

文档 \_id 文档内容
1 Elasticsearch 简介
2 Elasticsearch 实际

而倒排索引就不一样了,它会依据字段的内容进行分词提取出多个单词,而后依据单词建设起和文档 \_id 的关联关系。后续就能够通过单词 -> 文档 \_id -> 文档内容来搜寻了。

单词 文档 \_id
Elasticsearch 1, 2
简介 1
实际 2

实际上像上述表格的第一列里的单词被称之为 term,而第二列被称之为 Posting List。在 Elasticsearch 里会对 term 进行优化以便疾速寻找,同时还会其进行压缩,以缩小存储空间。

映射类型(Mapping Types)

当文档被创立时,每个文档都会存储在一个独自的索引中,并且配以一个映射类型,以示意其文档类型,例如 twitter 索引可领有 user 类型和 tweet 类型。

每个映射类型都能够有本人的字段,例如 user 类型能够有一个 full_name、user_name、email 字段,而 tweet 类型能够有 content、user_name、tweeted_at 字段。

实际上,user_name 字段在这两个映射类型里是共用存储的,这意味着,这个字段只能以一种数据类型而存在。如果咱们想让 user 类型的 user_name 是 string 类型,想让
tweet 类型的 user_name 是 boolean 类型,是办不到的。

而且映射类型多了还会导致数据稠密烦扰 Lucene 的压缩文档能力。因而在 Elasticsearch 6.x 版本里只容许一个索引蕴含一个映射类型,在 7.x 版本里映射类型的概念则已被移除,变成 _doc 固定类型。

集群(Cluster)、节点(Node)

一个 ElasticSearch 实例称之为节点,当有多个实例节点一起协同工作时便称之为集群

分片(Shard)

ElasticSearch 解决的数据是十分大的,为了缩小单个实例的压力,会将数据平衡的存储在各个节点上,而一个分片就是一个底层的工作单元,它保留了全副数据中的一部分。当咱们集群扩容或放大时,Elasticsearch 会主动的在各节点中迁徙分片,使得数据依然均匀分布在集群里。

一个分片能够是主分片或者是正本分片,正本分片其实就是主分片的拷贝,即所谓的冗余备份,避免硬件故障数据失落。

ElasticSearch 装置

应用 docker 装置将非常简单,咱们只须要拉取镜像:

docker pull elasticsearch:7.2.0

而后启动:

docker run --name elasticsearch -p 9200:9200 -p 9300:9300 -e "discovery.type=single-node" -d elasticsearch:7.2.0

验证是否装置胜利:

curl http://localhost:9200

ElasticSearch 应用

ElasticSearch 提供了敌对的 API 接口供内部应用。所以,当咱们想往 ElasticSearch 输出数据、搜寻数据便能够通过 HTTP + JSON 的形式进行。甚至咱们能够间接应用 curl 命令来和 ElasticSearch 交互,例如统计文档数量:

curl -XGET 'http://localhost:9200/_count?pretty' -d '{"query": {"match_all": {}
    }
}
'

在接管到申请,Elasticsearch 解决实现后将会返回一个 HTTP 状态码(例如:200 OK)和一个 JSON 格局的返回值,例如:

{
    "count" : 0,
    "_shards" : {
        "total" : 5,
        "successful" : 5,
        "failed" : 0
    }
}

为了书写方面,前面的申请将以简略模式出现,不再形容所有雷同的局部:主机名、端口号以及 curl 命令自身。例如以下简略格局:

GET /_count
{
    "query": {"match_all": {}
    }
}

事实上,如果咱们应用 kibana 的控制面板,就会发现它就是这么要求命令输出的。另外,ElasticSearch 的版本有很多,有的版本差别将十分大,上面的应用都是是针对 7.20 版本的,请知悉。

创立

文档的创立须要指定三个元数据:\_index(文档的归集所在)、\_type(文档的归类)、\_id(文档的惟一标识)。其中,\_index 是一个逻辑上的命名空间,示意具备雷同个性的文档汇合,这个汇合将会依据所有字段进行优化索引,在底层存储上则会被散发解决。

须要留神的是,因为 7.x 版本后的 _type 曾经固定为 _doc 了,所以如果咱们想要创立文档的话,能够这么发送命令:

POST my-index-000001/_doc/
{
  "@timestamp": "2099-11-15T13:12:00",
  "message": "GET /search HTTP/1.1 200 1070000",
  "user": {"id": "kimchy"}
}

此时,ElasticSearch 将会响应:

{
  "_shards": {
    "total": 2,
    "failed": 0,
    "successful": 2
  },
  "_index": "my-index-000001",
   "_type": "_doc",
  "_id": "W0tpsmIBdwcYyG50zbta",
  "_version": 1,
  "_seq_no": 0,
  "_primary_term": 1,
  "result": "created"
}

能够看到 ElasticSearch 将为咱们主动生成了 _id 字段,如果咱们的程序领有本人的标识字段,那么能够本人定义 _id 的值:

PUT /my-index-000001/_doc/1
{
  "@timestamp": "2099-11-15T13:12:00",
  "message": "GET /search HTTP/1.1 200 1070000",
  "user": {"id": "kimchy"}
}

返回如下:

{
  "_shards": {
    "total": 2,
    "failed": 0,
    "successful": 2
  },
  "_index": "my-index-000001",
   "_type": "_doc",
  "_id": "1",
  "_version": 1,
  "_seq_no": 0,
  "_primary_term": 1,
  "result": "created"
}

这样的话,如果咱们晓得文档 _id,那么就也这样获取数据了:

获取

GET /my-index-000001/_doc/1

将返回如下:

{
  "_index": "my-index-000001",
  "_type": "_doc",
  "_id": "1",
  "_version": 1,
  "_seq_no": 0,
  "_primary_term": 1,
  "found": true,
  "_source": {
      "@timestamp": "2099-11-15T13:12:00",
      "message": "GET /search HTTP/1.1 200 1070000",
      "user": {"id": "kimchy"}
    }
}

搜寻

当然,大多数时候咱们是不晓得文档 id 具体值的,所以咱们得用上面 _search 来搜寻:

GET /my-index-000001/_search?q=1.1

其中,q 示意查问任一字段蕴含 1.1 的记录。

如果咱们想要更加功能丰富的查问,那么咱们能够生成一个残缺的 body 发送过来:

{
    "query": {
        "match" : {"message" : "1.1"}
    },
    "size": 2,
    "_source": ["message", "user"],
}

下面示意查问 2 条记录,并且只返回字段 messageuser

更新

如果咱们想要更新文档的话,能够应用上面命令:

POST /<index>/_update/<_id>

删除

如果咱们想要删除文档的话,能够应用上面命令:

DELETE /<index>/_doc/<_id>

对于更多 API 命令大伙能够查看下官网的 API:REST APIs

总结

优良的开源框架总是能以敌对的产品状态面向开发者,毫无疑问,Elasticsearch 就具备了这个个性。它屏蔽了底层简单的逻辑概念,对外只裸露了简略易用的 API。让咱们的程序能疾速集成、疾速利用,或者这就是一个开源框架被宽泛应用的基操吧!


感兴趣的敌人能够搜一搜公众号「阅新技术」,关注更多的推送文章。
能够的话,就顺便点个赞、留个言、分享下,感激各位反对!
阅新技术,浏览更多的新常识。

正文完
 0