ElasticSearch入门之ES产生的背景, restful通俗解释 01

「爱情、让人受尽委屈。」 2021-11-04 10:36 319阅读 0赞

# 1. 搜索的核心及目前主流搜索网站做法 #

**搜索的核心: 创建索引和查询索引**  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjY0MTkwOQ_size_16_color_FFFFFF_t_70]  
首先我们谈几个公司，如雷贯耳的：百度、谷歌、维基百科；这些公司都有一个相似性就是门户网站，可以提供我们通过关键字搜索，然后快速的检索出我们想要的信息；

*  网页百度展示  
    比如我们检索啊策策，百度后台就会按照这个关键字进行查找（里面有搜索库，以及爬虫库），然后按照权重来进行从上打下的排序，给我们高亮的展示出现
 *  京东或者淘宝展示  
    随便搜索东西，就会高精度的展示我们想要的；就会根据关键词进行海量数据的快速的检索  
    比如我们查找：”护手霜“ ， 那么这期间内部会经过大体的：1、分词（护手，手霜，护等）2、根据这些词去海量的数据中检索 3、然后根据权重把检索出来的信息进行排序展示给我们

# 2. 传统做法及其弊端 #

那么对于一般的公司，初期是没有那么多数据的，所以很多公司更倾向于使用传统的数据库：mysql；比如我们要查找关键字”啊策策“，那么查询的方式大概就是:**select \* from table where field like ‘%啊策策%’**; 但是随着业务发展，数据会不断的膨胀，那么问题就来了；mysql单表查询能力即便经过了优化，它的极限也就是400W左右的数据量。而且还会经常出现查询超时的现象；

然后很多公司开始对数据库进行横向和纵向的扩容，开始进行数据库表的“拆分”：横向拆分和纵向拆分；但是即便这样操作，仍然会出现很多问题，比如：

1、数据库会出现单点故障问题，于是先天主从复制关系，于是增加了运维成本.  
2、因为对表的拆分，增加了后期维护的难度，同样也是增加了运维成本.  
3、即便做了大量的维护，但对于大数据的检索操作，依然很慢，完全达不到期望值.

# 3. ElasticSearch应运而生 #

*  首先登场的是**Luence**, 全文检索工具, 但是**lucene对外暴露出的可用接口**对于开发人员来说，操作是非常的复杂，而且没有效率的；  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjY0MTkwOQ_size_16_color_FFFFFF_t_70 1]
 *  接下来是**Solr**, 在**Luence**的基础上进一步封装, 有了一个叫做**Solr**的高性能分布式检索服务框架, 但是, solr有一个致命的缺点: **在建立索引期间,solr的搜索能力会极度下降, 这就在一定程度上造成了solr在实时索引上效率不高.**
 *  最后**ElasticSearch**应运而生. 同样是已Luence为基础, 并且吸收了前两代的教训而开发的分布式多用户能力的**全文搜索引擎**. 并且**ElasticSearch**是基于**restful web接口**进行发布的, 对于开发人员操作起来相当方便; 同时,**es**扩展节点方便,可用于**存储和检索海量数据**, 接近实时搜索能力,自定发现节点, 同时分片,副本机制保障数据不丢之.

# 4. 扩展–什么是restful风格? #

REST不是"rest"这个单词，而是**Resource Representational State Transfer**的缩写：通俗来讲就是：资源在网络中以某种表现形式进行状态转移。分开来讲：  
1.Resource：资源，即数据（网络的核心）。  
2.Representational：某种表现形式，比如用JSON，XML，JPEG等；  
3.State Transfer：状态变化。通过HTTP动词实现。

## 4.1 详解 ##

*  REST描述的是在网络中client和server的一种交互形式；REST本身不实用，实用的是如何设计 RESTful API（REST风格的网络接口；
 *  Server提供的RESTful API中，URL中只使用名词来指定资源，原则上不使用动词。“资源”是REST架构或者说整个网络处理的核心。  
    用HTTP协议里的动词来实现资源的添加，修改。
 *  Server和Client之间传递某资源的一个表现形式，比如用JSON，XML传输文本，或者用JPG，WebP传输图片等。
 *  用 HTTP Status Code传递Server的状态信息。比如最常用的 200 表示成功，500 表示Server内部错误等。

Web端不再用之前典型的PHP或JSP架构，而是改为前段渲染和附带处理简单的商务逻辑。Web端和Server只使用上述定义的API来传递数据和改变数据状态。格式一般是JSON。  
对于资源的具体操作类型，由HTTP动词表示。常用的HTTP动词有下面五个（括号里是对应的SQL命令）：  
1.GET（SELECT）： 从服务器获取资源(一项或多项)  
2.POST（CREATE）： 在服务器新建一个资源  
3.PUT（UPDATE）： 在服务器更新资源（客户端提供改变后的完整资源）  
4.PATCH（UPDATE）： 在服务器更新资源（客户端提供改变的属性）  
5.DELETE（DELETE）：从服务器删除资源。  
比如：  
GET /zoos：列出所有动物园  
POST /zoos：新建一个动物园  
GET /zoos/ID：获取某个指定动物园的信息  
PUT /zoos/ID：更新某个指定动物园的信息（提供该动物园的全部信息  
PATCH /zoos/ID：更新某个指定动物园的信息（提供该动物园的部分信息）  
DELETE /zoos/ID：删除某个动物园  
GET /zoos/ID/animals：列出某个指定动物园的所有动物  
DELETE /zoos/ID/animals/ID：删除某个指定动物园的指定动物

## 4.2 REST的优点 ##

1.客户-服务器（Client-Server）客户端服务器分离  
提高用户界面的便携性（操作简单）  
通过简化服务器提高可伸缩性（高性能，低成本）  
允许组件分别优化（可以让服务端和客户端分别进行改进和优化）

2.无状态（Stateless）  
从客户端的每个请求要包含服务器所需要的所有信息  
提高可见性（可以单独考虑每个请求）  
提高了可靠性（更容易从局部故障中修复）  
提高可扩展性（降低了服务器资源使用）

3.缓存（Cachable）  
服务器返回信息必须被标记是否可以缓存，如果缓存，客户端可能会重用之前的信息发送请求。  
优点:减少交互次数,减少交互的平均延迟。

4.分层系统（Layered System）  
系统组件不需要知道与他交流组件之外的事情。封装服务，引入中间层。  
优点:限制了系统的复杂性,提高可扩展性。

5.统一接口（Uniform Interface）  
优点:提高交互的可见性,鼓励单独改善组件。

6.支持按需代码（Code-On-Demand）  
优点:提高可扩展性

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjY0MTkwOQ_size_16_color_FFFFFF_t_70]: /images/20211104/fdf6ab7325134ce0a1462fd2f869ad32.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjY0MTkwOQ_size_16_color_FFFFFF_t_70 1]: /images/20211104/cd35a93a188a4b3d84396ca20f731f2e.png