ES简介

Elasticsearch 是一个非常强大的搜索引擎。它目前被广泛地使用于各个IT公司。Elasticsearch 是由 Elastic 公司创建并开源维护的。代码库

同时，Elastic 公司也拥有 Logstash 及 Kibana 开源项目。这个三个开源项目组合在一起，就形成了 ELK 软件栈。

他们三个共同形成了一个强大的生态圈。简单地说，Logstash 负责数据的采集，处理（丰富数据，数据转型等），Kibana 负责数据展，分析及管理。

Elasticsearch 处于最核心的位置，它可以帮我们对数据进行快速地搜索及分析。

ES中的基本概念

文档（Document）

Elasticsearch是面向文档的，文档是所有可搜索数据的最小单位。

日志文件中的日志项
一本电影的具体信息/—张唱片的详细信息
MP3播放器里的一首歌/ 一篇PDF文档中的具体内容
文档会被序列化成JSON格式，保存在Elasticsearch中，JSON对象由字段组成。每个字段都有对应的字段类型（字符串/数值/布尔/日期/二进制/范围类型）。
结构灵活。你的文档不依赖于预定义的架构。例如，并非所有事件都需要描述值，因此可以完全省略该字段。但它可能需要新的字段，例如位置的纬度和经度。
它可以是分层的。可以将其视为文档中的文档。字段的值可以很简单，就像位置字段的值可以是字符串一样。它还可以包含其他字段和值。例如，位置字段可能包含城市和街道地址。
每个文档都有一个Unique ID，你可以自己指定ID，或者通过Elasticsearch自动生成。

{
    "name": "Elasticsearch Denver",
    "organizer": "Lee",
    "location": "Denver, Colorado, USA"
}

文档的元数据

元数据，用于标注文档的相关信息

_index -文档所属的索引名
type -文档所属的类型名
_id -文档唯一Id
_source：文档的原始Json数据
_all:整合所有字段内容到该字段，已被废除
_version :文档的版本信息
_score :相关性打分

类型(Type)

类型是文档的逻辑容器，类似于表是行的容器。你将具有不同结构（模式）的文档放在不同类型中。例如，你可以使用一种类型来定义聚合组，并在人们聚集时为事件定义另一种类型。

每种类型的字段定义称为映射。例如，name 将映射为字符串，但 location 下的 geolocation 字段将映射为特殊的 geo_point 类型。每种字段的处理方式都不同。例如，你在名称字段中搜索单词，然后按位置搜索组以查找位于你居住地附近的组。

很多人认为 Elasticsearch 是 schema-less 的。大家都甚至认为 Elasticsearch 中的数据库是不需要 mapping 的。其实这是一个错误的概念。schema-less 在 Elasticsearch 中正确的理解是，我们不需要事先定义一个类型关系数据库中的 table 才使用数据库。在 Elasticsearch 中，我们可以不开始定义一个 mapping，而直接写入到我们指定的 index 中。这个 index 的 mapping 是动态生成的（当然我们也可以禁止这种行为）。其中的数据项的每一个数据类型是动态识别的。比如时间，字符串等，虽然有些的数据类型还是需要我们手动调整，比如 geo_point 等地理位置数据。另外，它还有一个含义，同一个 type，我们在以后的数据输入中，可能增加新的数据项，从而生产新的 mapping。这个也是动态调整的。

Elasticsearch 具有 schema-less 的能力，这意味着无需显式指定如何处理文档中可能出现的每个不同字段即可对文档建立索引。启用动态映射后，Elasticsearch 自动检测并向索引添加新字段。这种默认行为使索引和浏览数据变得容易-只需开始建立索引文档，Elasticsearch 就会检测布尔值，浮点数和整数值，日期和字符串并将其映射到适当的 Elasticsearch 数据类型。

关于Type，类型概念，在6.x版本中，一个索引(Index)可以拥有多个Type。在7.x版本(目前最新版本)，一个索引只能拥有一个Type，默认的type就是_doc，在7.x版本中，已经建议删除了。在未来的8.x版本会彻底删除。但是在7.x版本中，一个文档还是必须归属于一个类型。

传统的RDBMS，在插入数据之前需要定义表结构，各个字段的类型及长度等。当我们在ES中建立一个索引的第一个文档时，如果你没有创建它的 schema，那么 Elasticsearch 会根据所输入字段的数据进行猜测它的数据类型，比如上面的 user 被被认为是 text 类型，而 uid 将被猜测为整数类型。这种方式我们称之为 schema on write，也即当我们写入第一个文档时，Elasticsearch 会自动帮我们创建相应的 schema。在 Elasticsearch 的术语中，mapping 被称作为 Elasticsearch 的数据 schema。一旦一个索引的某个字段的类型被确定下来之后，那么后续导入的文档的这个字段的类型必须是和之前的是一致，否则写入将导致错误。schema on write 可能在某些时候不是我们想要的，那么在这种情况下，我们可以事先创建一个索引的 schema。你将在后面的文章中看到。在最新的 Elasticsearch 设计中，也出现了一种叫做 schema on read 的设计。

ES集群

Elasticsearch 的节点的分类如下：

主节点（Master Node）：也叫作主节点，主节点负责创建索引、删除索引、分配分片、追踪集群中的节点状态等工作。Elasticsearch 中的主节点的工作量相对较轻。

用户的请求可以发往任何一个节点，并由该节点负责分发请求、收集结果等操作，而并不需要经过主节点转发。

通过在配置文件中设置 node.master=true 来设置该节点成为候选主节点（但该节点不一定是主节点，主节点是集群在候选节点中选举出来的），在 Elasticsearch 集群中只有候选节点才有选举权和被选举权。其他节点是不参与选举工作的。

数据节点（Data Node）：数据节点，负责数据的存储和相关具体操作，比如索引数据的创建、修改、删除、搜索、聚合。

所以，数据节点对机器配置要求比较高，首先需要有足够的磁盘空间来存储数据，其次数据操作对系统 CPU、Memory 和 I/O 的性能消耗都很大。

通常随着集群的扩大，需要增加更多的数据节点来提高可用性。通过在配置文件中设置 node.data=true 来设置该节点成为数据节点。

客户端节点（Client Node）：就是既不做候选主节点也不做数据节点的节点，只负责请求的分发、汇总等，也就是下面要说到的协调节点的角色。

其实任何一个节点都可以完成这样的工作，单独增加这样的节点更多地是为了提高并发性。

node.master=falsenode.data=false

协调节点（Coordinating Node）：协调节点，是一种角色，而不是真实的 Elasticsearch 的节点，我们没有办法通过配置项来配置哪个节点为协调节点。集群中的任何节点都可以充当协调节点的角色。

当一个节点 A 收到用户的查询请求后，会把查询语句分发到其他的节点，然后合并各个节点返回的查询结果，最好返回一个完整的数据集给用户。

在这个过程中，节点 A 扮演的就是协调节点的角色。由此可见，协调节点会对 CPU、Memory 和 I/O 要求比较高。

集群健康

集群的状态有 Green、Yellow 和 Red 三种，如下所述：

Green：绿色，健康。所有的主分片和副本分片都可正常工作，集群 100% 健康。

Yellow：黄色，预警。所有的主分片都可以正常工作，但至少有一个副本分片是不能正常工作的。此时集群可以正常工作，但是集群的高可用性在某种程度上被弱化。

Red：红色，集群不可正常使用。集群中至少有一个分片的主分片及它的全部副本分片都不可正常工作。

这时虽然集群的查询操作还可以进行，但是也只能返回部分数据（其他正常分片的数据可以返回），而分配到这个分片上的写入请求将会报错，最终会导致数据的丢失。

8.3 KiB Raw Blame History Unescape Escape