技术栈 | 传送门 |
JAVA 基础 | 手撸架构,Java基础面试100问_vincent-CSDN博客 |
JAVA 集合 | 手撸架构,JAVA集合面试60问_vincent-CSDN博客 |
JVM 虚拟机 | 手撸架构,JVM面试30问_vincent-CSDN博客 |
并发编程 | 手撸架构,并发编程面试123问_vincent-CSDN博客 |
Spring | 手撸架构,Spring面试63问_vincent-CSDN博客 |
Spring cloud | 手撸架构,Spring cloud面试45问_vincent-CSDN博客 |
SpringBoot | 手撸面试,Spring Boot面试41问_vincent-CSDN博客 |
Netty 与 RPC | 手撸架构,Netty 与 RPC面试48问_vincent-CSDN博客 |
Doubo | 手撸架构,Dubbo面试49问_vincent-CSDN博客 |
Redis | 手撸架构,Redis面试41问_vincent-CSDN博客 |
Zookeeper | 手撸架构,Zookeeper面试27问_vincent-CSDN博客 |
Mysql | 手撸架构,Mysql 面试126问_vincent-CSDN博客 |
MyBatis | 手撸架构,MyBatis面试42问_vincent-CSDN博客 |
MongoDB | 手撸架构,MongDB 面试50问_vincent-CSDN博客 |
Elasticsearch | 手撸架构,Elasticsearch 面试25问_vincent-CSDN博客 |
RabbitMQ | 手撸架构,RabbitMQ 面试49问_vincent-CSDN博客 |
Kafka | 手撸架构,Kafka 面试42问_vincent-CSDN博客 |
Docker | 手撸架构,Docker 面试25问_vincent-CSDN博客 |
Nginx | 手撸架构,Nginx 面试40问_vincent-CSDN博客 |
算法 | 常用排序算法总结(1)-- 比较排序_vincent-CSDN博客_比较排序 常用排序算法总结(2)-- 非比较排序算法_vincent-CSDN博客_非比较排序的算法有 |
分布式事务 | 分布式事务解决方案(总览)_vincent-CSDN博客 |
HTTP | 太厉害了,终于有人能把TCP/IP 协议讲的明明白白了_vincent-CSDN博客_tcp和ip |
Elasticsearch 深入浅出,ELKStack及Solr企业级搜索引擎实战。
Elasticsearch 之(2)Elasticsearch核心概念_vincent-CSDN博客_elasticsearch核心概念
Elasticsearch是一个基于Lucene的搜索引擎。它提供了具有HTTP Web界面和无架构JSON文档的分布式,多租户能力的全文搜索引擎。Elasticsearch是用Java开发的,根据Apache许可条款作为开源发布。
Lucene工作原理
(1)可以作为一个大型分布式集群(数百台服务器)技术,处理PB级数据,服务大公司;也可以运行在单机上,服务小公司
(2)Elasticsearch不是什么新技术,主要是将全文检索、数据分析以及分布式技术,合并在了一起,才形成了独一无二的ES;lucene(全文检索),商用的数据分析软件(也是有的),分布式数据库(mycat)
(3)对用户而言,是开箱即用的,非常简单,作为中小型的应用,直接3分钟部署一下ES,就可以作为生产环境的系统来使用了,数据量不大,操作不是太复杂
(4)数据库的功能面对很多领域是不够用的(事务,还有各种联机事务型的操作);特殊的功能,比如全文检索,同义词处理,相关度排名,复杂数据分析,海量数据的近实时处理;Elasticsearch作为传统数据库的一个补充,提供了数据库所不不能提供的很多功能
属性 | 关系型数据库 | ElasticSearch |
库 | DB | Index |
表 | Table | Index Type |
约束 | Constraint | ID |
群集是一个或多个节点(服务器)的集合,它们共同保存您的整个数据,并提供跨所有节点的联合索引和搜索功能。群集由唯一名称标识,默认情况下为“elasticsearch”。此名称很重要,因为如果节点设置为按名称加入群集,则该节点只能是群集的一部分。
节点是属于集群一部分的单个服务器。它存储数据并参与群集索引和搜索功能。
索引就像关系数据库中的“数据库”。它有一个定义多种类型的映射。索引是逻辑名称空间,映射到一个或多个主分片,并且可以有零个或多个副本分片。 MySQL =>数据库 ElasticSearch =>索引
文档类似于关系数据库中的一行。不同之处在于索引中的每个文档可以具有不同的结构(字段),但是对于通用字段应该具有相同的数据类型。 MySQL => Databases => Tables => Columns / Rows ElasticSearch => Indices => Types =>具有属性的文档
类型是索引的逻辑类别/分区,其语义完全取决于用户。
(1)Near Realtime(NRT):近实时,两个意思,从写入数据到数据可以被搜索到有一个小延迟(大概1秒);基于es执行搜索和分析可以达到秒级
(2)Cluster:集群,包含多个节点,每个节点属于哪个集群是通过一个配置(集群名称,默认是elasticsearch)来决定的,对于中小型应用来说,刚开始一个集群就一个节点很正常
(3)Node:节点,集群中的一个节点,节点也有一个名称(默认是随机分配的),节点名称很重要(在执行运维管理操作的时候),默认节点会去加入一个名称为“elasticsearch”的集群,如果直接启动一堆节点,那么它们会自动组成一个elasticsearch集群,当然一个节点也可以组成一个elasticsearch集群
(4)Document&field:文档,es中的最小数据单元,一个document可以是一条客户数据,一条商品分类数据,一条订单数据,通常用JSON数据结构表示,每个index下的type中,都可以去存储多个document。一个document里面有多个field,每个field就是一个数据字段。
product document
{
"product_id": "1",
"product_name": "高露洁牙膏",
"product_desc": "高效美白",
"category_id": "2",
"category_name": "日化用品"
}
(5)Index:索引,包含一堆有相似结构的文档数据,比如可以有一个客户索引,商品分类索引,订单索引,索引有一个名称。一个index包含很多document,一个index就代表了一类类似的或者相同的document。比如说建立一个product index,商品索引,里面可能就存放了所有的商品数据,所有的商品document。
(6)Type:类型,每个索引里都可以有一个或多个type,type是index中的一个逻辑数据分类,一个type下的document,都有相同的field,比如博客系统,有一个索引,可以定义用户数据type,博客数据type,评论数据type。
(7)shard:单台机器无法存储大量数据,es可以将一个索引中的数据切分为多个shard,分布在多台服务器上存储。有了shard就可以横向扩展,存储更多数据,让搜索和分析等操作分布到多台服务器上去执行,提升吞吐量和性能。每个shard都是一个lucene index。
(8)replica:任何一个服务器随时可能故障或宕机,此时shard可能就会丢失,因此可以为每个shard创建多个replica副本。replica可以在shard故障时提供备用服务,保证数据不丢失,多个replica还可以提升搜索操作的吞吐量和性能。primary shard(建立索引时一次设置,不能修改,默认5个),replica shard(随时修改数量,默认1个),默认每个索引10个shard,5个primary shard,5个replica shard,最小的高可用配置,是2台服务器。
节点是 Elasticsearch 的实例。实际业务中,我们会说:ES 集群包含 3 个点、7 个节点。这里节点实际就是:一个独立的 Elasticsearch 进程,一般将一个节点部署到 一台独立的服务器或者虚拟机、容器中。
不同节点根据角色不同,可以划分为:
主节点
帮助配置和管理在整个集群中添加和删除节点。
数据节点
存储数据并执行诸如 CRUD(创建/读取/更新/删除)操作,对数据进行搜索和聚合的操作。
1、 客户端节点(或者说:协调节点)
将集群请求转发到主节点,将与数据相关的请求转发到数据节点。
2、 摄取节点
用于在索引之前对文档进行预处理。
1.一个index中包含多个shard
2.每个shard都是一个最小工作单元,承载部分数据;每个shard都是一个Lucene实例,有完整的建立索引和处理请求的能力
3.增减节点时,shard会自动在nodes中负载均衡
4.primary shard 和 relica shard,每个document只会存在于某一个primary shard以及其对应的replica shard中,不可能存在于多个primary shard中
5.replica shard 是primary shard 的副本,负责容错,以及承担读请求的负载均衡
6.primary shard在创建索引的时候就固定了,relica shard的数量可以随时更改
7.primary shard 和 它对应的replica shard 不能放在同一台机器上,不然起不了容错的作用
一个 CRUD 操作只对单个文档进行处理,文档的唯一性由 _index, _type, 和 routing values (通常默认是该文档的 _id )的组合来确定。 这表示我们确切的知道集群中哪个分片含有此文档。
搜索需要一种更加复杂的执行模型因为我们不知道查询会命中哪些文档: 这些文档有可能在集群的任何分片上。 一个搜索请求必须询问我们关注的索引(index or indices)的所有分片的某个副本来确定它们是否含有任何匹配的文档。
但是找到所有的匹配文档仅仅完成事情的一半。 在 search 接口返回一个 page 结果之前,多分片中的结果必须组合成单个排序列表。 为此,搜索被执行成一个两阶段过程,我们称之为 query then fetch
分布式模式
模式 | 代表组件 | 优点 | 缺点 |
---|---|---|---|
主从模式 | ES/HDFS/HBase | 简化系统设计,Master作为权威节点,负责维护集群原信息。 | Master节点存在单点故障,需要解决在被问题,并且集群规模会受限于Master节点的管理能力。 |
无主模式 | Cassandra | 分布式哈希表(DHT),支持每小时数千个节点的离开和加入。集群没有master的概念,所有节点都是同样的角色,彻底避免了整个系统的单点问题导致的不稳定性。 | 多个节点可能操作同一条数据,数据一致性上可能比较难以保证。 |
Elasticsearch的典型场景中的另一个简化是集群中没有那么多节点。 通常,节点的数量远远小于单个节点能够维护的连接数,并且网格环境不必经常处理节点加入和离开。 这就是为什么领导者的做法更适合Elasticsearch。
master节点的职责主要包括集群、节点和索引的管理,不负责文档级别的管理;data节点可以关闭http功能。
当集群中master候选的个数不小于3个(node.master:true)。可以通过discovery.zen.minimum_master_nodes这个参数的设置来避免脑裂,设置为(N/2)+1。
这里node.master : true 是说明你是有资格成为master,并不是指你就是master。是皇子,不是皇帝。假如有10个皇子,这里应该设置为(10/2)+1=6,这6个皇子合谋做决策,选出新的皇帝。另外的4个皇子,即使他们全聚一起也才四个人,不足合谋的最低人数限制,他们不能选出新皇帝。
假如discovery.zen.minimum_master_nodes 设置的个数为5,有恰好有10个master备选节点,会出现什么情况呢?5个皇子组成一波,选一个皇帝出来,另外5个皇子也够了人数限制,他们也能选出一个皇帝来。此时一个天下两个皇帝,在es中就是脑裂。
假如集群master候选节点为2的时候,这种情况是不合理的,最好把另外一个node.master改成false。如果我们不改节点设置,还是套上面的(N/2)+1公式,此时discovery.zen.minimum_master_nodes应该设置为2。这就出现一个问题,两个master备选节点,只要有一个挂,就选不出master了。
我还是用皇子的例子来说明。假如先皇在位的时候规定,必须他的两个皇子都在的时候,才能从中2选1 继承皇位。万一有个皇子出意外挂掉了,就剩下一个皇子,天下不就没有新皇帝了么。
TransportClient利用transport模块远程连接一个elasticsearch集群。它并不加入到集群中,只是简单的获得一个或者多个初始化的transport地址,并以 轮询 的方式与这些地址进行通信。
想了解该处,可以参考各个编程语言提供的es 库
协调节点默认使用文档ID参与计算(也支持通过routing),以便为路由提供合适的分片。
shard = hash(document_id) % (num_of_primary_shards)
补充:Query Then Fetch的搜索类型在文档相关性打分的时候参考的是本分片的数据,这样在文档数量较少的时候可能不够准确,DFS Query Then Fetch增加了一个预查询的处理,询问Term和Document frequency,这个评分更准确,但是性能会变差。
Elasticsearch 提供的首个近似聚合是cardinality 度量。它提供一个字段的基数,即该字段的distinct或者unique值的数目。它是基于HLL算法的。HLL 会先对我们的输入作哈希运算,然后根据哈希运算的结果中的 bits 做概率估算从而得到基数。其特点是:可配置的精度,用来控制内存的使用(更精确 = 更多内存);小的数据集精度是非常高的;我们可以通过配置参数,来设置去重需要的固定内存使用量。无论数千还是数十亿的唯一值,内存使用量只与你配置的精确度相关 .
Standard Analyzer:标准分析器是默认分词器,如果未指定,则使用该分词器。它基于 Unicode 文本分割算法,适用于大多数语言。
Whitespace Analyzer:基于空格字符切词。
Stop Analyzer:在 simple Analyzer 的基础上,移除停用词。
Keyword Analyzer:不切词,将输入的整个串一起返回
补充:索引阶段性能提升方法
1.在设计的时候可以基于模板+时间滚动方式创建索引,每天递增数据,避免单个索引很大的情况出现。
2.在存储的时候,冷热数据分开存储,比如最近3天的数据作为热数据,其他的作为冷数据,冷数据的话,由于不会再写入新数据了,可以考虑定期force_merge(强制合并)和shrink(压缩)的方式进行处理,节约空间和检索效率
3.由于es支持动态扩展,所有可以多加几台机器来缓解集群压力。
1、关闭缓存 swap;
2、堆内存设置为:Min(节.点内存/2, 32GB);
3、设置最大文件句柄数;
在ElasticSearch中实现分页查询的方式有两种,分别为深度分页(from-size)和快照分页(scroll)
Elasticsearch 之(5)kibana多种搜索方式_vincent-CSDN博客_kibana search
X-Pack 是与 Elasticsearch 一起安装的扩展程序。
X-Pack 的各种功能包括安全性(基于角色的访问,特权/权限,角色和用户安全性),监视,报告,警报等。