ES--特殊概念

1、Index

• 复数形式：indices
• 索引库
  • 类似于数据库中的数据库的概念
  • MySQL：database
  • Hbase ：NameSpace
• 用于区分不同数据构建的不同的索引

2、Type

• 索引类型，类型表
  • 类似于数据库中表的概念
  • 但是不一样，数据库中的表是有物理存储而ES中的Type是逻辑，没有物理存储
• 用于存储document的索引分类
• 注意：
  • 在ES中，你在理解Type的时候可以将Type类比表的概念，用于区分存储类型的数据
  • 在 物理上：Type和Table的概念是不一样
• ES中的第一级存储是索引库Index，第二级存储索引库中有索引类型Type
  • 以前的ES版本中，一个索引库中可以有多个索引类型
    • 类似于一个数据库中有多张表
  • 从6.x开始：一个索引库中只能有一个索引类型，不允许一个index中有多个Type；7废弃，但还在用；8才真正的去掉了type
  • 更新的版本中：Type这个概念和结构已经没有了，从ES中直接取消了
  • 用多个索引库来代替多个索引类型
• 简单点说：将Type类比于表，但是不一样
• 以前的结构
  • 数据库
    • 表1
      • 行
    • 表2
      • 行
• 现在的结构
  • 数据库
    • 表：只能有一张表
      • 行
• 未来的结构
  • 数据库
    • 行

Type与Table不一样的地方

• Type是没有物理结构，Table在物理是有区分
• MySQL的一个数据库中有两张表
  • people：数据库
    • teacher：表1：文件1
      • teaid teaname age【int】
    • student：表2：文件2
      • stuid stuname age[double]
    • 两张表中可以有相同的列名，彼此独立，互不影响
    • 在物理上这两张 表的数据是没有交集 ，是独立的两份数据
• ES中：一个索引库中所有的Type列是共用的
  • Type没有物理结构，所有的数据都是直接存储在索引库中的
  • indexpeople：索引库
    • teacherType：类型表1
      • teaid teaname age【int】
    • studentType：类型表2
      • stuid stuname age[double]
• 所有的数据都是直接存储在索引库中 ，type只是逻辑的概念，物理上是不区分的
• 如果两个类型表中出现了相同的列名，在索引库的物理层次中这是同一列
• 但是这两列的类型不一样，你读取数据就会出问题了
• 现象：
  • 逻辑结构两层
    • Index
      • Type
  • 物理结构一层
    • Index
• 解决
  • ES逐渐淡化Type这个结构，取消这个结构，直接与物理结构保持一致
    • 6.x版本中：强制一个index只能有一个type
    • 7.x版本中：取消Type这个结构
  • ES物理结构只有一层
    • Index
      • document

为什么它的物理结构不做Type？

• MySQL：支持业务数据存储
  • 数据库：区分不同业务
    • 人事数据库
    • 财务数据库
  • 表：用于区分数据
    • 人事数据库中
      • 在职人员表
      • 离职人员表
      • 招聘人员表
      • ……
• ES：存储数据和 构建索引，不需要关心业务
  • Index：区分不同数据
    • 数据
  • 当初为什么设计Type？
    • 参考数据库来设计的
    • 用于支持SQL接口
    • 在逻辑上划分了两层，但是物理上只有一层
  • 将每个要构建索引的数据作为一个索引库

3、Document

• 一条数据，类似于Hbase中的一条rowkey的数据
• document = documentId + data[fields]
  • documentId：类似于主键或者 行键的概念
    • 唯一标识一行
    • 与分区规则有关系
  • data【Fields】：这条数据中的列
  • 类似于Hbase中的数据
    • 一条数据 = rowkey + data[Fields]
• 一个document是可以被索引的基础单元
  • 根据索引返回数据时，返回的是匹配这个关键词的每个document
• document在物理上存储在索引库中，但是在逻辑上必须属于某个Type
  • 在实现对ES中document的读写时，需要加上index和type
• documentId：类似于rowkey，所有的索引库中的每条数据都有这一列，这一列的值由你自定义
  • 如果自己不自定义，由ES自动分配一个 documentid，一般都需要自定义
  • 唯一性
• 每一条document都是以json格式来表示
  • 不同的json可以有不同的字段
  • 每一个document的字段也可以不一样

4、Field

• 字段，类似于表中的列
• 由于每个document都是通过json来定义的，所有每个document可以定义任意多个字段

5、Shards

• 分片，实际上就是分区
  • HDFS：分块block
  • MapReduce：分片Split
  • Hbase：分区Region
  • ES：分片Shard
  • Kafka：分区Partition
  • 将存储的所有数据进行分布式存储
    • 放到一个分布式的结构中
    • 分的过程
• 每个Index在创建默认有5个分区，就是5个shard
  • 分区规则：数据根据documentId来决定写入哪个分片shard中
    • 根据documentId的hash值取余分片的个数
    • 类似于MapReduce中的shuffle阶段的分区规则
  • HDFS：每128M分一个BLock
  • MapReduce：max(minsplit,min(maxsplit,blocksize))，一个block对应一个 分片
  • Hbase：按照rowkey范围来划分region

问题：分布式的分区存储必然存在，如果节点故障，怎么保证数据安全的问题？

• Zookeeper：每一台机器存储的数据都是一样的，任何一台机器故障都不影响
• HDFS：副本机制，每个block都有副本，默认总共存储3份
• Hbase
  • memstore：通过WAL来保证数据安全
  • hdfs：通过hdfs副本机制来保证
• ES：副本机制

6、Replicas

• ES会为每个分片默认构建1个副本
  • 默认情况下，一个索引库创建以后，总共产生了10个分片
  • 5个分片，每个分片有1个副本分片
  • 相同的分片和副本不能在同一台机器上，每个分片的总副本数是不允许超过机器的个数的
    • 3台机器，每个分片最多3个副本，每台机器一个
    • 4个行不行？不行，没有意义
• 分片与副本有主从关系
  • 所有副本也是分片
  • 有主从关系
  • 主分片：对外提供写
  • 副本分片：与主分片同步数据
    • 如果主分片故障，所有副本分片重新选举一个新的主分片

概念	HDFS	Hbase	ES	Kafka
数据库	–	namespace	index	–
表/文件	文件	表	Type	Topic
分区	Block	Region	Shard	partition
安全	副本	WAL+hdfs副本	副本	副本
行	–	Rowkey+data[Fields]	docId+data[Fields]	KeyValue
架构	主从架构【NN，DN】	主从架构【Master，RS】	主从架构【Master，Node】	主从架构【Control，Broker】
	Zookeeper	Zookeeper	zen-discovery	Zookeeper