一、导读#
Hi All！我们一起学点有意思的！NoSQL！欢迎订阅白日梦Elasticsearch专题系列文章。按计划这个专题一共有四篇文章。所有文章公众号首发。
所有文章公众号首发!
所有文章公众号首发!
所有文章公众号首发!
所有文章公众号首发!
Notice！！！白日梦并不能保证通过这四篇文章让你掌握ES，但是！我会用大白话串讲ES的一些概念、和花哨的玩法。起码可以把你对Elasticsearch的陌生度降到最低，等有一天你自己业务需要使用ES时，会因为提前读了白日梦的ES笔记而快速上手。
为写这篇文章我还华为云上购置了一台2C4G的服务器，欢迎关注白日梦，我们一起学点实用的！有趣的技术！
1.1、认识ES#
关系型数据库：
像MySQL这种数据库就是传统的关系型数据库。它有个很直观的特点：每一张数据表的列在创建表的时候就需要确定下来。比如你创建一个user表，定义了3列id、username、password。这时如果你的实体类中多了一个age的字段，那这个实体是不能保存进user表的。（当然后续你可以通过DDL修改添加列或者减少列。让实体类的属性和表中的列一一对应）。
非关系型数据库：
非关系型数据库也就是我们常听说的NoSQL。常见的有：MongoDB、Redis、Elasticsearch。
且不说性能方面，单说使用方面NoSQL这种非关系类型的数据库都支持你往它里面存储一个json对象，这个json有多少个字段并不是它关系的，拿上面的例子来说，只要你给他一个对象，不管有没有age、它都能帮你存储进去。
关于ES更多的知识点我们在下文中展开，再说一下ES常见的使用场景和特性：
站内搜索：
如果你的公司想做自己的站内搜索，那ES再合适不过了。作为非关系型数据库的ES允许你往它里面存储各种格式不确定的Json对象，还为你提供了全文本搜索和分析引擎。它使您可以快速，近乎实时地（1 s）存储，搜索和分析大量数据。一个字：快！
日志采集系统：
Elasticsearch是Elastic公司的核技术，并且Elastic公司还有其他诸如：Logstash、Filebeat、Kibana等技术栈。常见的公司里面使用的日志管理系统就可以使用ELK+Filebeat搭建起来，Filebeat收集日志推送到Logstash做处理，然后Logstash将数据存储入ES，最终通过Kibana展示日志。
可扩展性：
Elasticsearch天生就是分布式的，既能以单机的形式运行一台性能很差的服务器上。它也可以形成一个成百上千节点的集群。并且它自己会管理集群中的节点，在ES中我们可以随意的添加、摘除节点，集群自己会将数据均摊在各个节点上。
1.2、安装、启动ES、Kibana、IK分词器#
- 安装很简单，所以详细过程不会写到文章中。
- 安装启动教程、ES、Kibana、IK分词器安装包都以百度网盘的方式分享给大家，后台回复：es 可领取
福利：账号借用#
好消息！！！如果你嫌安装ES麻烦，想使用现成的ES学习，可以免费白嫖白日梦的搭建在公网上的ES实例（有效期还有340多天，预计到2022年初才过期哦）。关注此公号后台回复：白嫖 可得到账号密码。
Notice！！！我不能保证它一定是安全可用哦，毕竟IP直接暴露在公网上是极有可能被黑的。如果你发现服务不可用，可以跟我说一下。我提前做好了镜像，可快速将系统回复如初。（为了安全，我也会不定期更新IP、账号密码）所以大家拿它用来学习还行，不要往上面放重要的数据哈！
关注白日梦后台回复：白嫖 ，即可领取账号密码。
关注白日梦后台回复：白嫖 ，即可领取账号密码。
关注白日梦后台回复：白嫖 ，即可领取账号密码。
另外我也推荐大家阅读原文，json的格式会好看很多！
二、核心概念#
因为这是第一篇基础篇，对小白友好一些，所以需要先了解一些基本概念，你可以耐折性子读一下，都不难理解的哈。
2.1、Near Realtime (NRT)#
ES号称对外提供的是近实时的搜索服务，意思是数据从写入ES到可以被Searchable仅仅需要1秒钟，所以说基于ES执行的搜索和分析可以达到秒级。
2.2、Cluster#
集群：集群是一个或多个node的集合，它们一起保存你存放进去的数据，用户可以在所有的node之间进行检索，一般的每个集群都会有一个唯一的名称标识，默认的名称标识为 elasticsearch ，这个名字很重要，因为node想加入cluster时，需要这个名称信息。
确保别在不同的环境中使用相同的集群名称，进而避免node加错集群的情况，一颗考虑下面的集群命名风格logging-stage和logging-dev和logging-pro。
2.3、Node#
单台server就是一个node，它和cluster一样，也存在一个默认的名称。但是它的名称是通过UUID生成的随机串，当然用户也可以定制不同的名称，但是这个名字最好别重复。这个名称对于管理来说很在乎要，因为需要确定，当前网络中的哪台服务器，对应这个集群中的哪个节点。
node存在一个默认的设置，默认的，当每一个node在启动时都会自动的去加入一个叫elasticsearch的节点，这就意味着，如果用户在网络中启动了多个node，它们会彼此发现，然后组成集群。
在单个的cluster中，你可以拥有任意多的node。假如说你的网络上没有其它正在运行的节点，然后你启动一个新的节点，这个新的节点自己会组建一个集群。
2.4、Index#
Index是一类拥有相似属性的document的集合，比如你可以为消费者的数据创建一个index，为产品创建一个index，为订单创建一个index。
index名称(必须是小写的字符)， 当需要对index中的文档执行索引、搜索、更新、删除、等操作时，都需要用到这个index。
理论上：你可以在一个集群中创建任意数量的index。
2.5、Type#
Type可以作为index中的逻辑类别。为了更细的划分，比如用户数据type、评论数据type、博客数据type
在设计时尽最大努力让拥有更多相同field的document划分到同一个type下。
2.6、Document#
document就是ES中存储的一条数据，就像mysql中的一行记录一样。它可以是一条用户的记录、一个商品的记录等等
2.7、一个不严谨的小结:#
为什么说这是不严谨的小结呢? 就是说下面三个对应关系只能说的从表面上看起来比较相似。但是ES中的type其实是一个逻辑上的划分。数据在存储是时候依然是混在一起存储的(往下看下文中有写)，而mysql中的不同表的两个列是绝对没有关系的。
| Elasticsearch | 关系型数据库 |
| Document | 行 |
| type | 表 |
| index | 数据库 |
2.8、Shards & Replicas#
2.8.1、问题引入:#
如果让一个Index自己存储1TB的数据，响应的速度就会下降。为了解决这个问题，ES提供了一种将用户的Index进行subdivide的骚操作，就是将index分片，每一片都叫一个Shards，进而实现了将整体庞大的数据分布在不同的服务器上存储。
2.8.2、什么是shard?#
shard分成replica shard和primary shard。顾名思义一个是主shard、一个是备份shard， 负责容错以及承担部分读请求。
shard可以理解成是ES中最小的工作单元。所有shard中的数据之和，才是整个ES中存储的数据。 可以把shard理解成是一个luncene的实现，拥有完整的创建索引，处理请求的能力。
下图是两个node，6个shard的组成的集群的划分情况：
你可以看一下上面的图，图中无论java应用程序访问的是node1还是node2，其实都能获取到数据。
2.8.3、shard的默认数量#
新创建的节点会存在5个primary shard，注意！后续不然能再改动primary shard的值，如果每一个primary shard都对应一个replica shard，按理说单台es启动就会存在10个分片，但是现实是，同一个节点的replica shard和primary shard不能存在于一个server中，因此单台es默认启动后的分片数量还是5个。
2.8.4、如何拓容Cluster#
首先明确一点： 一旦index创建完成了，primary shard的数量就不可能再发生变化。
因此横向拓展就得添加replica的数量， 因为replica shard的数量后续是可以改动的。也就是说，如果后续我们将它的数量改成了2， 就意味着让每个primary shard都拥有了两个replica shard， 计算一下: 5+5*2=15 集群就会拓展成15个节点。
如果想让每一个shard都有最多的系统的资源就增加服务器的数量，让每一个shard独占一个服务器。
2.8.5、举个例子:#
上图中存在上下两个node，每个node中都有一个 自己的primary shard和其它节点的replica shard，为什么是强调自己和其它呢? 因为ES中规定，同一个节点的replica shard和primary shard不能存在于一个server中，而不同节点的primary shard可以存在于同一个server上。
当primary shard宕机时，因为它对应的replicas shard在其它的server没有受到影响，所以ES可以继续响应用户的读请求。通过这种分片的机制，并且分片的地位相当，假设单个shard可以处理2000/s的请求，通过横向拓展可以在此基础上成倍提升系统的吞吐量，天生分布式，高可用。
此外: 每一个document肯定存在于一个primary shard和这个primary shard 对应的replica shard中， 绝对不会出现同一个document同时存在于多个primary shard中的情况。
