ElasticSearch 是一个高可用开源全文检索和分析组件。提供存储服务,搜索服务,大数据准实时分析等。一般用于提供一些提供复杂搜索的应用。
ElasticSearch 提供了一套基于restful风格的全文检索服务组件。前身是compass,直到2010被一家公司接管进行维护,开始商业化,并提供了ElasticSearch 一些相关的产品,包括大家比较熟悉的 kibana、logstash 以及ElasticSearch 的一些组件,比如 安全组件shield 。当前最新的ElasticSearch 版本为 5.1.1 ,比较应用广泛的为2.X,直到 2016-12 推出了5.x 版本 ,将版本号调为 5.X 。这是为了和 kibana 和 logstash 等产品版本号进行统一ElasticSearch 。我们将从以下几个问题快速了解一些ElasticSearch索引服务器。
一、ES是如何产生背景
1、大规模数据如何检索?
当系统数据量上了10亿、100亿条的时候,我们在做系统架构的时候通常会从以下角度去考虑问题:
1)用什么数据库好?(mysql、sybase、oracle、达梦、神通、mongodb、hbase…)
2)如何解决单点故障;(lvs、F5、A10、Zookeep、MQ)
3)如何保证数据安全性;(热备、冷备、异地多活)
4)如何解决检索难题;(数据库代理中间件:mysql-proxy、Cobar、MaxScale等;)
5)如何解决统计分析问题;(离线、近实时)
2、传统数据库的应对解决方案
对于关系型数据,我们通常采用以下或类似架构去解决查询瓶颈和写入瓶颈:
1)通过主从备份解决数据安全性问题;
2)通过数据库代理中间件心跳监测,解决单点故障问题;
3)通过代理中间件将查询语句分发到各个slave节点进行查询,并汇总结果
3、非关系型数据库的解决方案
对于Nosql数据库,基本原理类似:
1)通过副本备份保证数据安全性;
2)通过节点竞选机制解决单点问题;
3) 先从配置库检索分片信息,然后将请求分发到各个节点,最后由路由节点合并汇总结果
4、另辟蹊径 完全把数据放入内存怎么样?
我们知道,完全把数据放在内存中是不可靠的,实际上也不太现实,当我们的数据达到PB级别时,按照每个节点96G内存计算,在内存完全装满的数据情况下,我们需要的机器是:1PB=1024T=1048576G 节点数=1048576/96=10922个 实际上,考虑到数据备份,节点数往往在2.5万台左右。成本巨大决定了其不现实!
从前面讨论我们了解到,把数据放在内存也好,不放在内存也好,都不能完完全全解决问题。 全部放在内存速度问题是解决了,但成本问题上来了。 为解决以上问题,从源头着手分析,通常会从以下方式来寻找方法:
1、存储数据时按有序存储;
2、将数据和索引分离;
3、压缩数据; 这就引出了Elasticsearch
二、ES基础知识
1、ES主要解决问题
1)检索相关数据; 2)返回统计结果; 3)速度要快;
2、Lucene与ES关系
1) Lucene只是一个库。想要使用它,你必须使用Java来作为开发语言并将其直接集成到你的应用中,更糟糕的 是,Lucene非常复杂,你需要深入了解检索的相关知识来理解它是如何工作的。
2) Elasticsearch也使用Java开发并使用Lucene作为其核心来实现所有索引和搜索的功能,但是它的目的是通过简 单的RESTful API来隐藏Lucene的复杂性,从而让全文搜索变得简单。
3、ES工作原理
当ElasticSearch的节点启动后,它会利用多播(multicast)(或者单播,如果用户更改了配置)寻找集群中的其它节 点,并与之建立连接。这个过程如下图所示:
4、ES的基本概念
1) 近实时查询(Near RealTime)
Elasticsearch 是一个能提供近实时查询的搜索服务引擎,这意味着从索引文档到真正可搜索之间会有一个轻微的延迟(大概在一秒内)。
2) 节点和集群
节点(node)是一个运行着的 Elasticsearch 实例,你可以认为是单个服务器。集群(cluster)是一个或多个节点的集合,他们协同工作,共享数据并提供故障转移和扩展功能。集群由唯一名称标识,如 .NET Core 中的环境名称,推荐在不同的环境中使用诸如 Development,Production 之类的名称部署开发。其实节点和集群就是 web 开发中的常见概念而已,大家注意区分即可。
3) 文档
文档是可索引信息的基本单元,以JSON表示。你可以用其来定义单个产品信息或是员工信息。我们可以把文档理 解为数据库文档中的行列数据。在索引/类型中,您可以存储任意数量的文档。文档有几个共同不可缺的属性,分 别为 _index, _type, _id, 针对特定一个或一类文档进行操作时,必须指定这些属性。 最后要提醒大家的是,虽然文档物理上是驻留在索引中,但实际上文档必须索引/分配给索引中的类型。
4) 索引
索引是具有某些相似特征的文档的集合,它和数据库中的索引概念并不十分相同。我们可以把索引理解为数据库文 档中的数据库。事实上,我们的数据被存储和索引在分片(shards)中,索引只是一个把一个或多个分片分组在一起 的逻辑空间。然而,这只是一些内部细节——我们的程序完全不用关心分片。
5) 类型
在索引中,我们可以定义一个或多个类型。类型是索引的逻辑类别/分区,其语义完全由开发者决定。通常,为具 有一组公共字段的文档定义类型。例如,假设开发者运行博客平台并将所有数据存储在一个索引中。在此索引中, 我们可以为用户数据定义类型,为博客数据定义另一种类型,并为注释数据定义另一种类型。我们可以把索引理解 成数据库文档中的表。
6) 分片和复制
理论上,索引可以存储尽可能多的数据,但是这种情况下性能往往不太乐观,或者常见的磁盘容量限制也不能允 许。所以 Elasticsearch 提供了类似于 MongoDB 中的分片功能,该功能能将索引细分为多个分片。每个分片本身是一个功能完全和独立的"索引",可以托管在集群中的任何节点上。
同样的,有分片技术来处理数据量增长快速的问题,就意味着需要复制技术来应对这种过程中(其实不只是该过 程,任何情况下都应该有安全意识)数据安全的问题。Elasticsearch 允许您将索引分片的一个或多个副本转换为所谓的副本分片。复制技术为我们提供了数据的高可用性和搜索吞吐的扩展性。不过需要注意的是,副本分片从不分 配在与从其复制的原始/主分片相同的节点上。
总而言之,每个索引可以拆分为多个分片。索引也可以复制为零(意味着没有副本)或更多次。一旦复制,每个索 引将具有主分片(从索引复制的原始分片)和副本分片(主分片的副本)。开发者可以在创建索引时就为每个索引 定义分片和副本的数量。创建索引后,可以随时动态更改副本数,但不能在此过程后随即更改分片数。
三、ES的安装与服务启动
1、下载ES的压缩包
Window 系统下载 zip 版本,linux 系统下载 tar 版本
将下载的zip解压到指定的磁盘上
2、ES服务的目录结构
bin 存放 elasticSearch 运行命令 config 存放配置文件 lib 存放 elasticSearch 运行依赖 jar 包 modules 存放elasticSearch 模块 plugins 存放插件
3、ES服务的启动
指定ES安装目录下的bin下的elasticsearch.bat
启动日志信息如下:
4、访问ES服务
四、通过java去访问ES服务
1、搭建环境
创建Maven工厂,添加ES的客户端坐标
2、创建索引