【elasticsearch】4、基本概念

文档

  • elasticsearch是面向文档的,文档是所有可搜索数据的最小单位
    • 日志文件中的日志项
    • 一本电影的具体信息/一张唱片的详细信息
    • mp3播放器里面的一首歌/一篇pdf文档中的具体内容
  • 文档会被序列化成json格式,保存在elasticsearch中
    • json对象由字段组成
    • 每个字段都有对应的字段类型(字符串,数值,布尔,日期,二进制,范围类型)
  • 每个文档都有一个unique id
    • 你可以自己制定id
    • 或者通过elasticsearch自动生成

json文档

json文档
  • 一篇文档包含了一系列的字段,类似数据库中的一条记录
  • json文档,格式灵活,不需要预先定义格式
    • 字段的类型可以指定或者通过elasticsearch自动推算
    • 支持数组,支持嵌套

上篇通过csv文件装换的数据

{
    "@version" => "1",
          "id" => "177939",
       "genre" => [
        [0] "Animation",
        [1] "Romance"
    ],
        "year" => 2017,
       "title" => "The Night Is Short, Walk on Girl"
}

文档的元数据

文档的元数据
  • 元数据,用于标注文档的相关信息
    • _index 文档所属的索引名
    • _type 文档所属的类型名
    • _id 文档唯一id
    • _source 文档的原始json数据
    • _all 整合所有字段内容到该字段,已被废除
    • _version 文档的版本信息
    • _score 相关性打分

索引

索引
  • index 索引是文档的容器,是一类文档的结合
    • index提现了逻辑空间的概念:每个索引都有自己的mapping定义,用户定义包含的文档的字段名和字段类型
    • shard体现了物理空间的概念:索引中的数据分散在shard上
  • 索引的mapping和settings
    • mapping定义文档字段的类型
    • setting定义不同的数据分布

索引的不同语义

elasticsearch集群中
  • 名词 一个elasticsearch集群中,可以创建很多个不同的索引
  • 动词 保存一个文档到elasticsearch中的过程也叫索引
  • 名词 一个b树索引,一个倒排索引

type

  • 7.0之前,一个index可以设置多个types
  • 6.0开始,type已经被抛弃,7.0开始,一个索引只能创建一个type,_doc
  • 传统关系型数据库和elasticsearch的区别
    • elasticsearch - schemaless/相关性/高性能全文搜索
    • rdms - 事务性/join

抽象和类比

rdbms(关系型数据库) elasticsearch
table index(type)
row document
column filed
schema mapping
sql dsl

提供了rest-api 容易被各种语言调用

rest-api

一些基本的api

  • indeces
    • 创建index
      • put movies
    • 查看所有的index
      • _cat/indices

kibana应用

kibana应用-索引管理

index相关api

#查看索引相关信息
GET kibana_sample_data_ecommerce

#查看索引的文档总数
GET kibana_sample_data_ecommerce/_count

#查看前10条文档,了解文档格式
POST kibana_sample_data_ecommerce/_search
{
}

#_cat indices API
#查看indices
GET /_cat/indices/kibana*?v&s=index

#查看状态为绿的索引
GET /_cat/indices?v&health=green

#按照文档个数排序
GET /_cat/indices?v&s=docs.count:desc

#查看具体的字段
GET /_cat/indices/kibana*?pri&v&h=health,index,pri,rep,docs.count,mt

#How much memory is used per index?
GET /_cat/indices?v&h=i,tm&s=tm:desc

节点,集群,分片以及副本

分布式系统的可用性和拓展性

  • 高可用性
    • 服务可用性 - 允许有节点停止服务
    • 数据可用性 - 部分节点丢失,不会丢失数据
  • 可拓展性
    • 请求量提升,数据的不断增长(将数据分布到所有节点上)

分布式特性

  • elasticsearch的分布式架构的好处
    • 存储的水平扩容
    • 提高系统的可用性,部分节点停止服务,整个集群的服务不受影响
  • elasticsearch的分布式架构
    • 不同集群通过不同的名字区分,默认名字“elasticsearch”
    • 通过配置文件修改,或者在命令行中 -E cluster.name=cutie进行设定
    • 一个集群可以有一个或者多个节点

节点

  • 节点是一个elasticsearch的实例
    • 本质上是一个java进程
    • 一台机器上可以运行多个elasticsearch进程,但是生产环境一般建议一台机器上只运行一个elasticsearch实例
    • 每一个节点都有名字,通过配置文件配置,或者启动的时候 -E node.name=node1指定
    • 每一个节点在启动之后会分配一个uid,保存在data目录下

master-eligible nodes 和 master node

  • 每个节点启动后,默认就是一个master eligible节点
    • 可以设置node.master:false禁止
  • master-eligible节点可以参加选主流程,成为master节点
  • 当地一个节点启动的时候,它会将自己选举成master节点
  • 每个节点上都保存了集群的状态,只有master节点才能修改集群的状态信息
    • 集群状态(cluster state),维护了一个集群中必要的信息
      • 所有的节点信息
      • 所有的索引和与其相关的mapping和setting信息
      • 分片的路由信息
    • 任意加点都能修改信息会导致数据的不一致性

data node (数据)和 coordinating node (协调)

  • data node
    • 可以保存数据的节点,叫做data node,负责保存分片数据。在数据拓展起到了至关重要的作用
  • coordinating node
    • 负责接受client的请求,将请求分发到合适的节点,最终把结果汇集到一起
    • 每个节点默认都起到了coordinating node的职责

其他的节点类型

  • hot & warm node (冷热节点)
    • 不同硬件配置的data node,用来实现hot & warm 架构,降低集群成本
  • machine learning node
    • 负责跑机器学习的job,用来做异常检测
  • tribe node
    • 5.3开始使用corss cluster search,tribe node 链接到不同的elasticsearch集群,并且支持将这些集群当成一个单独的集群处理

配置节点类型

在elasticsearch.yml中配置

  • 开发环境中一个节点可以承担多种角色
  • 生产环境中应该设置单一的角色的节点(dedicated node)
节点类型 配置参数 默认值
master eligible node.master true
data node.data true
ingest node.ingest true
coordinating onlu 每个节点默认都是coordinating节点,设置其他类型全部为false
machine learning node.ml true(需要enable x-pack)

分片(primary shard & replica shard)

  • 主分片,用户解决数据水平拓展的问题。通过主分片,可以将数据分布到集群内的所有节点之上
    • 一个分片是一个运行的lucene实例
    • 主分片数在索引创建时指定,后续不允许修改,除非reindex
  • 副本,用以解决数据高可用的问题。分片是主分片的拷贝
    • 副本分片数可以动态调整
    • 增加副本数,还可以在一定程度上提高服务的可用性(读取的吞吐)
  • 一个三节点的集群中,blogs索引的分片分部情况
    • 思考:增加一个节点活改大主分片数对系统的影响?
分片示例

分片的设定

  • 对于生产环境中分片的设定,需要提前做好容量规划
  • 分片数设置过小
    • 导致后续无法增加节点实现水平拓展
    • 单个分片的数据量太大,导致数据重新分配耗时
  • 分票数设置过大,7.0开始,默认主分片设置为1,解决了over-sharding的问题
    • 影响搜索结果的相关性打分,影响统计结果的准确性
    • 单个节点上过多的分片,会导致资源的浪费,同时也会影响性能

查看集群的健康状况

健康状态
  • green - 主分片和副本都正常分配
  • yellow - 主分片全部正常分配,有副本分片未能正常分配
  • red - 有主分片未能分配
    • 如:服务器的磁盘容量超过85%时,去创建了一个新的索引

demo

get _cluster/health
get _cat/nodes
get _cat/shards

get _cat/nodes?v
GET /_nodes/es7_01,es7_02
GET /_cat/nodes?v
GET /_cat/nodes?v&h=id,ip,port,v,m


GET _cluster/health
GET _cluster/health?level=shards
GET /_cluster/health/kibana_sample_data_ecommerce,kibana_sample_data_flights
GET /_cluster/health/kibana_sample_data_flights?level=shards

#### cluster state
The cluster state API allows access to metadata representing the state of the whole cluster. This includes information such as
GET /_cluster/state

#cluster get settings
GET /_cluster/settings
GET /_cluster/settings?include_defaults=true

GET _cat/shards
GET _cat/shards?h=index,shard,prirep,state,unassigned.reason

你可能感兴趣的:(【elasticsearch】4、基本概念)