ElasticSearch入门 - 概述

素颜马尾好姑娘i 2022-06-06 12:07 98阅读 0赞

> ElasticSearch是一个基于Lucene的搜索服务器。它提供了一个分布式多用户能力的全文搜索引擎，基于RESTful web接口。Elasticsearch是用Java开发的，并作为Apache许可条款下的开放源码发布，是当前流行的企业级搜索引擎。设计用于云计算中，能够达到实时搜索，稳定，可靠，快速，安装使用方便。  
> 我们建立一个网站或应用程序，并要添加搜索功能，但是想要完成搜索工作的创建是非常困难的。我们希望搜索解决方案要运行速度快，我们希望能有一个零配置和一个完全免费的搜索模式，我们希望能够简单地使用JSON通过HTTP来索引数据，我们希望我们的搜索服务器始终可用，我们希望能够从一台开始并扩展到数百台，我们要实时搜索，我们要简单的多租户，我们希望建立一个云的解决方案。因此我们利用Elasticsearch来解决所有这些问题以及可能出现的更多其它问题。

### 回忆往事 ###

> 许多年前，一个刚结婚的名叫 Shay Banon 的失业开发者，跟着他的妻子去了伦敦，他的妻子在那里学习厨师。 在寻找一个赚钱的工作的时候，为了给他的妻子做一个食谱搜索引擎，他开始使用 Lucene 的一个早期版本。
> 
> 直接使用 Lucene 是很难的，因此 Shay 开始做一个抽象层，Java 开发者使用它可以很简单的给他们的程序添加搜索功能。 他发布了他的第一个开源项目 Compass。
> 
> 后来 Shay 获得了一份工作，主要是高性能，分布式环境下的内存数据网格。这个对于高性能，实时，分布式搜索引擎的需求尤为突出， 他决定重写 Compass，把它变为一个独立的服务并取名 Elasticsearch。
> 
> 第一个公开版本在2010年2月发布，从此以后，Elasticsearch 已经成为了 Github 上最活跃的项目之一，他拥有超过300名 contributors(目前736名 contributors )。 一家公司已经开始围绕 Elasticsearch 提供商业服务，并开发新的特性，但是，Elasticsearch 将永远开源并对所有人可用。
> 
> 据说，Shay 的妻子还在等着她的食谱搜索引擎…

### 为什么使用ElasticSearch呢？ ###

*最开始的时候，我们项目使用的搜索仅仅只是使用Mysql进行简单的搜索，如果使用一个不能索引的like语句，严重的拉低了MySQL的性能。这时候我们就直接把目光定位到了ElasticSearch。*

#### ElasticSearch的优点： ####

*  分布式搜索服务
 *  提供Restful API
 *  底层基于Lucene
 *  采用多shard的方式保证数据的安全
 *  提供自动的resharding的功能
 *  很多大型网站都使用它作为搜索引擎，如github..

#### 如果在项目中使用，需要解决的问题： ####

*  索引，对于需要搜索的数据，如何建立合适的索引，还需要根据特性语言使用不用的analyze等
 *  搜索，ElasticSearch提供了非常强大的搜索功能，如何写出高效的搜索语句？
 *  数据源，我们所有的数据是存放在MySQL的，MySQL是唯一的数据源，如何将MySQL的数据导入到ElasticSearch？

> 对于1和2，因为我们的数据都是从MySQL生成，index的field是固定的，主要做的工作就是根据业务场景设计好对应的mapping以及search语句就可以了，当然实际不可能这么简单，需要我们不断的调优。
> 
> 而对于3，则是需要一个工具将MySQL的数据导入Elasticsearch，因为我们对搜索实时性要求很高，所以需要将MySQL的增量数据实时导入，笔者唯一能想到的就是通过row based binlog来完成。而近段时间的工作，也就是实现一个MySQL增量同步到Elasticsearch的服务。

### 基本概念 ###

#### 数据层面 ####

*  Index：Elasticsearch用来存储数据的逻辑区域，它类似于关系型数据库中的db概念。一个index可以在一个或者多个shard上面，同时一个shard也可能会有多个replicas。
 *  Document type：为了查询需要，一个index可能会有多种document，也就是document type，但需要注意，不同document里面同名的field一定要是相同类型的。
 *  Document：Elasticsearch里面存储的实体数据，类似于关系数据中一个table里面的一行数据。  
    document由多个field组成，不同的document里面同名的field一定具有相同的类型。document里面field可以重复出现，也就是一个field会有多个值，即multivalued。
 *  Mapping：存储field的相关映射信息，不同document type会有不同的mapping。

> 对于上面几个概念呢，在我们使用MySQL数据库中有对应的理解：Index就是一个DB，Document type就是一个table，Document 就是table中的一行数据，Field就是一行数据中的一个字段的数据。  
> 其实拿生活中的事物进行理解就是：书籍（Index），书的类别（Document type），具体的一本书（Document），这样就好理解了吧。

#### 服务层面 ####

*  Node： 一个server的实例。
 *  Cluster： 多个node组成的cluster
 *  Shard： 数据分片，一个Index可能会存在于多个shards，不同shards可能在不同的nodes
 *  Replica：shard的备份，有一个primary shard，其余的叫做replica shards。

Elasticsearch之所以能动态resharding，主要在于它最开始就预先分配了多个shards（貌似是1024），然后以shard为单位进行数据迁移。这个做法其实在分布式领域非常的普遍，codis就是使用了1024个slot来进行数据迁移。

因为任意一个index都可配置多个replica，通过冗余备份的方式保证了数据的安全性，同时replica也能分担读压力，类似于MySQL中的slave。

### Restful API ###

Elasticsearch提供了Restful API，使用json格式，这使得它非常利于与外部交互，虽然Elasticsearch的客户端很多，但笔者仍然很容易的就写出了一个简易客户端用于项目中，再次印证了Elasticsearch的使用真心很容易。

Restful的接口很简单，一个url表示一个特定的资源，譬如/blog/article/1，就表示一个index为blog，type为aritcle，id为1的document。

而我们使用http标准method来操作这些资源，POST新增，PUT更新，GET获取，DELETE删除，HEAD判断是否存在。

推荐使用强大的发送请求的工具Postman：  
![这里写图片描述][SouthEast]

### 索引和搜索 ###

虽然Elasticsearch能自动判断field类型并建立合适的索引，但笔者仍然推荐自己设置相关索引规则，这样才能更好为后续的搜索服务。

我们通过定制mapping的方式来设置不同field的索引规则。

而对于搜索，Elasticsearch提供了太多的搜索选项，就不一一概述了。

索引和搜索是Elasticsearch非常重要的两个方面，直接关系到产品的搜索体验，但笔者现阶段也仅仅是大概了解了一点，后续在详细介绍。

### 同步MySQL数据 ###

Elasticsearch是很强大，但要建立在有足量数据情况下面。我们的数据都在MySQL上面，所以如何将MySQL的数据导入Elasticsearch就是笔者最近研究的东西了。

虽然现在有一些实现，譬如elasticsearch-river-jdbc，或者elasticsearch-river-mysql，但笔者并不打算使用。

elasticsearch-river-jdbc的功能是很强大，但并没有很好的支持增量数据更新的问题，它需要对应的表只增不减，而这个几乎在项目中是不可能办到的。

elasticsearch-river-mysql倒是做的很不错，采用了python-mysql-replication来通过binlog获取变更的数据，进行增量更新，但它貌似处理MySQL dump数据导入的问题，不过这个笔者真的好好确认一下？话说，python-mysql-replication笔者还提交过pull解决了minimal row image的问题，所以对elasticsearch-river-mysql这个项目很有好感。只是笔者决定自己写一个出来。

为什么笔者决定自己写一个，不是因为笔者喜欢造轮子，主要原因在于对于这种MySQL syncer服务（增量获取MySQL数据更新到相关系统），我们不光可以用到Elasticsearch上面，而且还能用到其他服务，譬如cache上面。所以笔者其实想实现的是一个通用MySQL syncer组件，只是现在主要关注Elasticsearch罢了。

项目代码在这里go-mysql-elasticsearch，现已完成第一阶段开发，内部对接测试中。

go-mysql-elasticsearch的原理很简单，首先使用mysqldump获取当前MySQL的数据，然后在通过此时binlog的name和position获取增量数据。

一些限制：

binlog一定要变成row-based format格式，其实我们并不需要担心这种格式的binlog占用太多的硬盘空间，MySQL 5.6之后GTID模式都推荐使用row-based format了，而且通常我们都会把控SQL语句质量，不允许一次性更改过多行数据的。  
需要同步的table最好是innodb引擎，这样mysqldump的时候才不会阻碍写操作。  
需要同步的table一定要有主键，好吧，如果一个table没有主键，笔者真心会怀疑设计这个table的同学编程水平了。多列主键也是不推荐的，笔者现阶段不打算支持。  
一定别动态更改需要同步的table结构，Elasticsearch只能支持动态增加field，并不支持动态删除和更改field。通常来说，如果涉及到alter table，很多时候已经证明前期设计的不合理以及对于未来扩展的预估不足了。  
更详细的说明，等到笔者完成了go-mysql-elasticsearch的开发，并通过生产环境中测试了，再进行补充。

将在下一篇中进行ElasticSearch的安装和使用。

[SouthEast]: /images/20220606/d53a6cc82c7940878fa50c40ec8a03ee.png