Elasticsearch 快速入门指南【总结记录】

本文将介绍一些基本概念，帮助您快速入门使用Elasticsearch。

一、概述

ES用来解决什么问题？Elasticsearch是解决海量数据（已经存在的数据）全文检索的不二只选。

Elasticsearch是一个基于Java语言开发，建立在开源搜索库Lucene之上的，天生支持分布式、可扩展、实时的搜索、聚合分析和存储引擎。它提供了强大的全文搜索功能和复杂的分析能力，适用于各种场景，包括应用日志分析、电子商务搜索、实时数据分析等。

二、认知

1、Lucene

Lucene封装好了各种建立倒排索、匹配索引进行搜索的各种算法。我们可以引入Lucene，基于它的API进行开发。

Elasticsearch就是在Lucene的基础上实现的，对Lucene进行了良好的封装，简化开发，并提供了很多高级功能。

2、ELK

ELK是Elasticsearch、Logstash和Kibana开源项目的首字母缩写。

ELK的应用场景：

网站搜索、垂直搜索、代码搜索；
日志管理与分析、安全指标监控、应用性能监控、web专区舆情分析；

3、Elastic Stack

Elastic Stack是ELK的更新换代产品，由于Logstash是重负载的任务，非常吃内存，消息处理在实战中面临很多问题（和web应用抢占资源等），因此后期引入了Beats，因为Beats是Go语言开发的，非常轻量，所以后期取代了Logstash的消息采集器（Beats只取代了Logstatsh中的一部分功能）。

Elasticsearch：Elasticsearch是一个搜索和分析引擎，是Elastic技术体系中最核心的成员；
Logstash：是一个服务端动态数据收集管道，能够同时从多个来源采集数据，转换数据，然后将数据发送到诸如ES等存储库中；
Kibana：提供了功能强大的图形化工具，可以让用户在Elasticsearch中使用图形和图表对比数据进行可视化；
Beats：轻量化数据采集器；
X-pack：商业化套件（收费），安全、告警、监控、图查询、机器学习。

Elasticsearch为快速检索和分析大数据而生，目前已形成丰富的生态。

三、入门

1、ES特点

基于Java开发，基于Lucene框架（ES每一个分片都是一个完整的Lucene实例）；
原生支持分布式（Lucene不支持分布式，Solr需要借助Zookeeper来进行分布式集群管理）；
仅支持JSON数据格式，支持PB级数据量；
开源、免费、跨语言、高性能、高可用、易扩展；
开箱即用，上手简单，潜力巨大，可开发性强；
不支持事务，写入实时性低，不能保证数据即时一致性。

2、ES目录

bin：可执行脚本文件，包括启动Elasticsearch服务、插件管理、函数命令等；
config：配置文件目录，如：Elasticsearch配置、角色配置、JVM配置等；
lib：Elasticsearch所依赖的Java库；
data：默认的数据存放目录，包含节点、分片、索引、文档的所有数据（生产环境要求必须修改到其它路径）；
logs：默认的日志文件存放目录（生产环境同样要求必须修改到其它路径）；
modules：包含所有的Elasticsearch模块，如Cluster、Discovery、Indices等；
plugins：已经安装插件的目录（新增插件可以直接存放到该目录，然后重启ES生效）；
jdk/jdk app：7.0版本以后才有，自带的Java环境。

3、ES基本概念

1）ES分布式相关概念：

Elasticsearch本质上是一个分布式的数据库，允许多台服务器协同工作，每台服务器可以运行多个Elastic实例（生产环境建议每个节点都分别部署到不同的服务器上，防止某一台服务器宕机导致多个ES节点不可用），单个Elastic实例是一个节点，一组节点构成一个集群。

节点（Node）：节点是Elasticsearch集群中的一个实例，它是数据存储和处理的基本单元。每个节点都有一个唯一的名称，并且具有自己的角色和职责。节点之间可以互相通信和协作，以实现数据的分布式存储和处理。
集群（Cluster）：集群是由多个节点组成的Elasticsearch环境。节点通过互相通信和协调工作，共同构成一个集群。集群具有一个唯一的名称，并且可以包含数十甚至数千个节点，以实现高可用性和横向扩展。

2）ES单节点中的概念：

索引（Index）：索引是Elasticsearch中存储和组织数据的基本单元，每个Index的名字必须是小写。用于存储和管理一组相关的文档。每个索引都有一个唯一的名称，并且可以包含多个类型（在Elasticsearch 7.x版本开始，一个索引只能包含一个类型）。
类型（Type）：类型是在旧版本的Elasticsearch中引入的概念，用于将索引内的文档进行逻辑上的分组。每个类型都有一个名称，用于描述一组具有相似结构的文档。从Elasticsearch 7.x版本开始，一个索引只有一个固定的类型（即_doc）。

例如：weather这个Index里面，可以按城市分组（北京和上海），也可以按气候分组（晴天和雨天）。这种分组就叫做Type，它是虚拟的逻辑分组，用来过滤Document。

性质完全不同的数据（比如products和logs）应该存成两个 Index，而不是一个 Index 里面的两个 Type（虽然可以做到）。

文档（Document）：文档是ES中的基本数据单元。用于表示一个具体的实体或对象，文档以JSON格式表示，可以包含各种字段和对应的值。每个文档都有一个唯一的ID，用于在索引中进行唯一标识，同一个Index里面的Doc不要求有相同的结构（schema），但是最好保持相同，这样有利于提高搜索效率。
字段（Field）：是用于表示和存储文档中特定数据的单元。每个文档都可以包含一个或多个字段，字段可以是不同的数据类型，如文本、数值、日期等。
分片和副本（Shard & Replica）：为了实现数据的分布式存储和高可用性，ES将每个索引划分为多个分片（Shard）。每个分片都是一个独立的索引，包含部分数据。每个分片可以有多个副本（Replica），用于提供冗余和故障恢复。

类比数据库相关概念：

Elasticsearch名称	概念	数据库
Index	索引	库
Type	类型	表
Document	文档	行
field	字段	列

思考：ES中_type类比数据库中表的概念是否恰当？

最初，官方谈到索引类似于SQL数据库中的数据库的概念，类型相当于表。这是一个糟糕的类比，导致了错误的假设。在SQL数据库中，表是相互独立的。一个表中的列与另一个表中的同名列无关。对于_type中的字段，情况并非如此。

在 Elasticsearch 索引中，不同_type中具有相同名称的字段在内部由相同的Lucene字段支持。相同的索引中，不同的Type应该有相似的结构（schema），举例来说，id字段不能在这个Type是字符串类型，在另一个Type是数值类型（这是与关系型数据库的表的一个区别）。

思考：ES 7.x官方为什么要删除_type这个概念？

因为Elasticsearch设计初期，是直接查考了关系型数据库的设计模式，存在了 type（数据表）的概念。

但是，其搜索引擎是基于Lucene的，这种基因决定了type是多余的。 Lucene的全文检索功能之所以快，是因为倒序索引的存在。

而这种倒序索引的生成是基于index的，而并非type。多个type反而会减慢搜索的速度。

为了保持Elasticsearch "一切为了搜索" 的宗旨，适当的做些改变（去除 type）也是无可厚非的，也是值得的。

3）Query与Analysis：

查询（Query）：查询是使用Elasticsearch进行搜索和过滤的一种方式。Elasticsearch提供了丰富的查询语言和API，可以进行全文搜索、精确匹配、范围过滤、聚合等操作。查询可以根据各种条件和参数来指定，并且可以根据相关性进行排序和评分。
分析（Analysis）：分析是在将文本数据存储到Elasticsearch之前对其进行处理的过程。它包括分词、词干化、停用词过滤等步骤，以便更好地支持全文搜索和相关性排序。Elasticsearch提供了强大的分析器和标记器，可以根据不同的语言和需求进行配置。

四、应用

下面是常用数据库的对比图。

1、ES和MySQL的优劣势

1）Elasticsearch的优势：

高性能：Elasticsearch是一个面向搜索和分析的分布式数据库，专注于快速的全文搜索和实时数据分析。它在处理大规模数据和高并发查询时表现出色，具有较高的性能。
水平扩展性：Elasticsearch具有良好的可扩展性，可以轻松地进行水平扩展和集群部署。它可以处理大规模的数据集和高并发操作。
弹性和容错性：Elasticsearch具有自动数据复制和故障恢复的机制，保证了数据的容错性和高可用性。

2）Elasticsearch的劣势：

事务处理支持有限：Elasticsearch是一个面向搜索和分析的数据库，对于复杂的事务处理支持有限。它不支持跨多个文档的事务操作，因此在需要强一致性和事务性操作的场景下不是最佳选择。
数据一致性延迟：由于Elasticsearch的分布式特性，数据的一致性可能需要一定的时间来保证。在进行数据复制和同步时，可能会出现短暂的数据一致性延迟。

3）MySQL的优势：

事务处理支持：MySQL是一个成熟的关系型数据库，具有强大的事务处理支持。它支持ACID属性（原子性、一致性、隔离性和持久性），可以确保数据的一致性和完整性。
数据一致性：MySQL在数据一致性方面相对可靠，可以提供较低的数据一致性延迟。
关联查询支持：MySQL支持关系型数据模型和复杂的关联查询操作，适用于需要多表关联查询和复杂数据模型的应用。

4）MySQL的劣势：

性能瓶颈：在处理大规模数据和高并发操作时，MySQL可能会遇到性能瓶颈，需要进行优化和调整。
扩展性限制：相比于Elasticsearch，MySQL的扩展性相对较差。在需要处理大规模数据和高并发操作的场景下，可能需要进行复杂的分库分表操作。

综上所述，Elasticsearch适用于快速的全文搜索和实时数据分析，但在事务处理和数据一致性方面支持有限。MySQL则适用于事务处理和复杂的关联查询，但在处理大规模数据和高并发操作时可能会遇到性能瓶颈。根据具体的业务需求和数据特点，选择合适的数据库系统是很重要的。有时候，使用Elasticsearch和MySQL的组合可以更好地满足不同类型的需求。

2、ES使用场景

1）单独使用elasticsearch作为存储，一般适用于以下场景：

全文搜索：Elasticsearch是一个强大的全文搜索引擎，适用于对大量文本数据进行快速和高效的搜索。如果应用程序主要关注全文搜索功能，并且需要快速地检索和分析文本数据，那么单独使用Elasticsearch作为存储是一个不错的选择。
实时数据分析：Elasticsearch具备实时性能和高度可扩展性，适用于实时数据分析和可视化。它可以处理大规模的日志数据、事件数据等，支持聚合、分组和多维度分析等操作。如果应用程序需要实时地分析和可视化大量的数据，并且对性能和扩展性要求较高，那么单独使用Elasticsearch作为存储是一个合适的选择。
日志管理：Elasticsearch被广泛应用于日志管理和分析领域。它可以接收和索引大量的日志数据，并提供强大的搜索和过滤功能，以便快速定位、检索和分析日志事件。如果应用程序需要对大量日志数据进行搜索、过滤和分析，并且需要快速定位和诊断问题，那么单独使用Elasticsearch作为存储是一个理想的选择。
地理空间数据：Elasticsearch对地理空间数据的支持非常强大，可以进行地理位置的索引和搜索。它提供了丰富的地理位置查询功能，如距离计算、地理范围查询等。如果应用程序需要处理地理空间数据，并进行复杂的地理位置搜索和分析，那么单独使用Elasticsearch作为存储是一个合适的选择。

总而言之，单独使用Elasticsearch作为存储适用于那些需要强大的全文搜索、实时数据分析、日志管理和地理空间数据处理的应用场景。根据具体的需求和数据特点，选择合适的存储方案是很重要的。

2）与数据库集成（先写入数据库，再同步Elasticsearch），以下场景可以考虑与数据库进行集成：

与现有系统的集成
需要考虑事务性（ES天生不支持事务）
数据库更新频繁（数据库不能保证数据实时一致性）

3、指标分析/日志分析流程图

总结：本文介绍了Elasticsearch的生态、常用数据库的对比以及如何与Mysql的整合，还介绍了一些Elasticsearch的基本概念，包括索引、文档、类型、节点、集群、分片和副本、查询以及分析。了解这些基本概念将有助于您更好地理解和使用Elasticsearch，从而构建高效的搜索和分析系统。对于更深入的学习和实践，建议参考官方文档和相关资源。