Elasticsearch 吹牛逼系列

大口吃饭大口吐

于 2021-04-11 13:44:12 发布

阅读量93

点赞数

分类专栏： ELK

本文链接：https://blog.csdn.net/qq_37485347/article/details/115597889

版权

ELK 专栏收录该内容

5 篇文章 0 订阅

订阅专栏

底层是开源库Apache Lucene，java将Lucene 直接集成到应用程序中，便成了ES
采用java编写（JDK1.8），所以，这是一个java程序
横向扩展，可支持PB级的结构化或非结构化数据处理，存储容量不足时加节点(加机器)即可解决
一个分布式的实时文档存储，每个字段可以被索引与搜索
通讯方式为 HTTP RESTful API

存储

默认情况下，Elasticsearch里面有2份内容，一份是原始文档，也就是_source字段里的内容，我们在Elasticsearch中搜索文档，查看的文档内容就是_source中的内容。另一份是倒排索引，倒排索引中的数据结构是倒排记录表，记录了词项和文档之间的对应关系。

文档索引到Elasticsearch的时候，默认情况下是对所有字段创建倒排索引的(动态mapping解析出来为数字类型、布尔类型的字段除外)，某个字段是否生成倒排索引是由字段的index属性控制的

集群

cluster 集群，node 节点，shard 分片
示例三台机器
10.0.40.193:9300 (主)
10.0.40.200:9300
10.0.40.237:9300

关于扩容
真正的扩容能力是来自于水平扩容——为集群添加更多的节点，并且将负载压力和稳定性分散到这些节点中

空集群

通常我们单机学习时，启动了一个单独的节点，不包含任何的数据和索引 =>> 包含空内容节点的集群

一个运行中的 Elasticsearch 实例称为一个节点，而集群是由一个或者多个拥有相同 cluster.name 配置的节点组成，它们共同承担数据和负载的压力。当有节点加入集群中或者从集群中移除节点时，集群将会重新平均分布所有的数据。当一个节点被选举成为主节点时，它将负责管理集群范围内的所有变更，例如增加、删除索引，或者增加、删除节点等
作为用户，我们可以将请求发送到集群中的**任何节点 **，包括主节点。每个节点都知道任意文档所处的位置，并且能够将我们的请求直接转发到存储我们所需文档的节点。无论我们将请求发送到哪个节点，它都能负责从各个包含我们所需文档的节点收集回数据，并将最终结果返回給客户端【意味着随便选一台服务器任意一个节点发送HTTP请求，数据都可以交互】

集群健康

通过http方法查看
curl get http://10.0.40.200:9200/_cluster/health
curl get http://10.0.40.193:9200/_cluster/health
curl get http://10.0.40.237:9200/_cluster/health

status 字段是我们最关心的,会出现 green(所有的主分片和副本分片都正常运行), yellow(所有的主分片都正常运行，但不是所有的副本分片都正常运行) 或者 red(有主分片没能正常运行) 三种。其它几个参数自行查阅文档

Kibana控制台查看
通过配置好的kibana可查看集群状态并可查看具体的运行状态例如cpu,内存等
http://kibana.test.netjoy.com/app/monitoring#/elasticsearch/nodes?_g=(cluster_uuid:‘2zktGqGWS1SNnJ85Uo0JoA’)

数据的存储

索引保存相关数据的地方，索引实际上是指向一个或者多个物理分片的逻辑命名空间注意，是逻辑空间，不是物理真实数据存放空间

一个分片是一个底层的工作单元 ,它仅保存了全部数据中的一部分,一个分片是一个 Lucene 的实例(它本身就是一个完整的搜索引擎)。我们的文档被存储和索引到分片内，但是应用程序是直接与索引而不是与分片进行交互(索引即是数据的交互出口)

数据存入分片中，分片分配到集群各处(索引:通过逻辑联系分片整合数据)
Elasticsearch 是利用分片将数据分发到集群内各处的。分片是数据的容器，文档保存在分片内，分片又被分配到集群内的各个节点里。当你的集群规模扩大或者缩小时， Elasticsearch 会自动的在各节点中迁移分片，使得数据仍然均匀分布在集群里
一个分片可以是主分片或者副本分片。索引内任意一个文档都归属于一个主分片，所以主分片的数目决定着索引能够保存的最大数据量

一个副本分片只是一个主分片的拷贝。副本分片作为硬件故障时保护数据不丢失的冗余备份，并为搜索和返回文档等读操作提供服务

在索引建立的时候就已经确定了主分片数，但是副本分片数可以随时修改，默认情况下会被分配5个主分片

多节点或者多机器的一些部署

多个节点可以放在同一台机器也可放不同台机器，分布式集群是相对的，同一台机器启动多个实例、节点，也是相互集群，相互分布式存储，不是说非要不一台机器

这里我们索引给了3个分片，1个副本（灰色的是副本）

创建实例后，没有建索引，是这样子的，节点中是空的

当我们创建一个节点时 ==>> 拥有一个索引的单节点集群

只有一个节点在运行时，意味着会有一个单点故障问题，挂了的话就真的挂了
我们再启动一个节点 ==>> 拥有两个节点的集群——所有主分片和副本分片都已被分配

当第二个节点加入到集群后，3个副本分片将会分配到这个节点上——每个主分片对应一个副本分片。这意味着当集群内任何一个节点出现问题时，我们的数据都完好无损
所有新近被索引的文档都将会保存在主分片上，然后被并行的复制到对应的副本分片上。这就保证了我们既可以从主分片又可以从副本分片上获得文档
再增加一个节点对现有的应用进行扩容(为了分散负载而对分片进行重新分配) ==>> 拥有三个节点的集群

节点1 和节点 2 上各有一个分片被迁移到了新的节点3，现在每个节点上都拥有2个分片
这表示每个节点的硬件资源（CPU, RAM, I/O）将被更少的分片所共享，每个分片的性能将会得到提升，如果想再扩容，可以再增加3个节点，我们这个拥有6个分片（3个主分片和3个副本分片）的索引可以最大扩容到6个节点，每个节点上存在一个分片，这样每个节点的全部性能100%为这一个分片服务
另一个维度的扩容，可以修改副本的分片数量，调整为2个，现在拥有9个分片：3个主分片和6个副本分片

意味着我们可以将集群最大扩容到9个节点
为了模拟故障，我们关闭了主节点

集群必须拥有一个主节点来保证正常工作，所以发生的第一件事情就是选举一个新的主节点： 节点 2
在我们关闭 节点1 的同时也失去了主分片 1 和 2 ，并且在缺失主分片的时候索引也不能正常工作。如果此时来检查集群的状况，我们看到的状态将会为 red ：不是所有主分片都在正常工作。
幸运的是，在其它节点上存在着这两个主分片的完整副本，所以新的主节点立即将这些分片在 节点2 和 节点3 上对应的副本分片提升为主分片，此时集群的状态将会为 yellow 。这个提升主分片的过程是瞬间发生的，如同按下一个开关一般。

为什么我们集群状态是 yellow 而不是 green 呢？虽然我们拥有所有的三个主分片，但是同时设置了每个主分片需要对应2份副本分片，而此时只存在一份副本分片。所以集群不能为 green 的状态，不过我们不必过于担心：如果我们同样关闭了 节点2 ，我们的程序依然可以保持在不丢任何数据的情况下运行，因为 节点3 为每一个分片都保留着一份副本。

如果我们重新启动 节点1 ，集群可以将缺失的副本分片再次进行分配，那么集群的状态也将如步骤 4 所示。如果 节点1 依然拥有着之前的分片，它将尝试去重用它们，同时仅从主分片复制发生了修改的数据文件