本文将介绍一些基本概念,帮助您快速入门使用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,从而构建高效的搜索和分析系统。对于更深入的学习和实践,建议参考官方文档和相关资源。