Elasticsearch在Centos 7上的安装常见的问题node
使用场景:好比分库的状况下,你想统计全部数据的报表,就把全部数据都放在ElasticSearch上算法
关系型数据库 | ElasticSearch |
数据库Database | 索引index,支持全文检索 |
表Table | 类型Type |
数据行Row | 文档Document |
数据列Column | 字段Field |
模式Schema | 映射Mapping |
用关系型数据库就会想到创建一张User表,再建字段等,数据库
而在Elasticsearch的文件存储,Elasticsearch是面向文档型数据库,一条数据在这里就是一个文档,用JSON做为文档序列化的格式segmentfault
在ES6.0以后,已经不容许在一个index下建不一样的Type了,一个index下只有一个Type(之后版本中Type概念会去掉,能够直接把index类比成Table)网络
节点Node:app
一个ElasticSearch运行的实列,集群构成的单元分布式
集群Cluster:测试
由一个或多个节点组成,对外提供服务 优化
ElasticSearch是基于倒排索引实现的
倒排索引(Inverted Index)也叫反向索引,有反向索引必有正向索引。
通俗地来说,正向索引是经过key找value,反向索引则是经过value找key。
倒排索引—单词词典
单词词典(Term Dictionary)是倒排索引的重要组成部分。
——记录全部文档的单词,通常都比较大
——记录单词到倒排列表的关联信息(这个单词关联了哪些文档)
倒排索引—排序列表
倒排列表(Posting List)记录了单词对应文档的集合,由倒排索引项(Posting)组成
倒排索引项(Posting)主要包含以下信息
—文档Id,用于获取原始信息
—单词频率(TF,Term Frequency),记录该单词在文档中出现的次数,用于后序相关算分
—位置(Position),记录单词在文档中的分词位置,用于作词语搜索(Phrase Query)
—偏移(Offset),记录单词在文档的开始和结束位置,用于高亮显示
搜索引擎的核心是倒排索引,而倒排索引的基础就是分词。所谓分词能够简单理解为将一个完整的句子切割为一个个单词的过程。也能够叫文本分析,在es称为Analysis。
如文本:elasticSearch是最流行的搜索引擎
分词结果:elasticSearch 流行 搜索引擎
分词器是es中专门处理分词的组件,英文为Analyzer,它的组成以下
Character Filters:针对原始文本特殊处理,好比除html特殊符
Tokenizer:将原始文本按照必定规则切分为单词
TokenFilters:针对tokenizer处理的单词就行在加工,好比转小写,删除或新增处理(好比中文中的 这 呢 无实意的词)
Analyze API
es提供了一个测试分词的API接口,方便验证分词效果,endpoint是_analyze
—能够直接指定analyze测试
—能够直接指定索引中的字段进行测试
—能够自定义分词器进行测试
Mapping相似数据库中的表结构定义,主要做用以下:
—定义Index下的字段名(Field Name)
—定义字段的类型,好比数值型、字符串型、布尔型等
—定义倒排索引相关的配置,好比是否索引、记录position等
Dynamic Mapping
es能够自动识别文档字段类型,从而下降用户使用成本
es中存储的数据进行查询分析,endpoint为_search
查询主要有两种形式
1)URI Search
操做简单,方便经过命令进行测试
但 仅包含部分查询语法
GET /indexname/_search?q=user:xx
2)Request Body Search
es提供的完备查询语法Query DSL(Domain Specific Language)
GET /indexname/_search
{
"query": {
"term": {
"user": "xx"
}
}
}
相关算分
相关算分是指文档与查询语句直接的相关度,英文为relevance
经过倒排索引能够获取与查询语句相匹配的文档列表,那么如何将最符合用户查询的文档放到前列呢
本质是一个排序问题,排序的依据是相关算分
ES目前主要有两个相关性算分模型
TF/IDF模型
BM25模型 5.x以后的默认模型
BM25相比TF/IDF的一大优化是下降了TF(Term Frequency单词频率)在过大时的权重
相关算分是shard与shard间是相互独立的,也就意味着一个Term的IDF等值在不一样shard上是不一样的。文档的相关算分和它所处的shard有关
在文档数量很少时 会致使相关算分严重不许的状况发生
解决办法
—设置分片数是一个,从根本排除问题,在文档数据量很少时能够考虑该方法,(百万到千万)
—二是使用DFS Query Then Ftech查询方式
es支持集群模式,是一个分布式系统,好处是
—1)增长系统容量:内存、磁盘,使es集群能够支持PB级的数据
如何将数据分布在全部节点上
—引入分片 Shard解决问题
分片是ES支持PB级数据的基石
—分片存储了部分数据,能够分部在任意节点上
—分片数在索引建立时指定且后序不容许再更改(即便你后面新增了也用不到),默认5个
—分片有主分片和副本分片之分,以实现数据的高可用
es集群由多个es实列组成
—不一样集群经过集群名字来区分,可经过cluster.name修改,默认为elasticSearch
—每一个ES实列本质是一个JVM进程,且有本身的名字,经过node.name修改
Master Node:Master节点经过集群中全部的节点选举产生,能够被选举的节点称为master-eligible节点,
相关配置以下:node.master:true
Coordinating Node:处理请求的节点为Coordinating节点,该节点为全部节点默认角色,不能取消
做用是把请求路由到正确的节点处理,好比建立索引请求到master节点
Data Node:存储数据的节点即为data节点,默认节点都是data类型,相关配置以下:node.data.true
—2)提供系统可用性:即部分节点中止服务,整个集群依然能够正常服务
提升系统可用性
服务可用性
—两个节点状况下,容许其中一个节点中止服务
数据可用性
—引入副本(Replication)解决
—每一个节点上都有完备的数据
复制分片的意义在于容错性,当一个节点挂了,另外一个节点上的分片能够代替挂掉节点上的分片
一:
二:
三:
文档到分片的映射算法
es经过以下公式计算文档到对应的分片 -shard=hash(routing)%number_of_primary_shards
hash算法保证能够将数据均匀的分散在分片中
routing是一个关键参数,默认是文档id,也能够自行指定
number_of_primary_shards是主片分数(该算法与主片分数相关,这也是分片数量一旦肯定就不能修改的缘由)
在上述第一步的时候 node2和node3选举node2为master节点了时候,此时会更新cluster state
此时node1节点网络恢复了,node1本身组成集群后,也会更新cluster state
此时:同一个集群有两个master,并且维护不一样的cluster state,网络恢复后 没法选择正确的master
解决方案:仅在可选举master-eligible节点数大于等于quorum时才能够进行master选举
即便node1节点恢复了 ,可选节点数未达到quorum,不选举