ElasticSearch功能简介和系统介绍

ElasticSearch简介

本文针对ElasticSearch进行简单的介绍，包括ES的功能，相关概念和基本结构。该部分内容参考自：ElasticSearch Introduction官方文档。

Elasticsearch是Elastic Stack的核心分布式搜索和分析引擎。 Elastic Stack技术栈中，Logstash和Beats用于收集、聚合和丰富数据，并将数据存储在Elasticsearch中。 Kibana可以帮助用户进行交互式地探索，可视化和共享对数据的见解，并管理和监视整个Stack的运行情况。而Elasticsearch便是为数据建立索引，提供搜索和进行数据分析的地方。

Elasticsearch可以为所有类型的数据提供实时的搜索和分析，包括结构化文本、非结构化文本、数字数据或地理空间数据。Elasticsearch都能够以快速搜索的方式有效地对其进行存储和建立索引（search其实就是对索引的快速查找）。 ElasticSearch不仅可以进行简单的数据检索，还可以聚合信息来发现数据中的趋势和模式。 随着数据和查询量的增长，Elasticsearch的分布式特性可以使部署的集群随之无缝地扩容。

虽然不是每个问题都是搜索问题，但Elasticsearch可以快速和灵活的处理各种使用场景中的数据：

• 为应用（APP）或网站添加内容搜索框
• 存储和分析日志，监测值（metrices）和安全事件数据（security event data）
• 使用机器学习（ML）自动实时为数据行为建模
• 使用Elasticsearch作为存储引擎自动化业务工作流程
• 使用Elasticsearch作为地理信息系统（GIS）管理，集成和分析空间信息
• 使用Elasticsearch作为生物信息学研究工具来存储和处理遗传数据

数据导入：建立文档和索引

Elasticsearch是一个分布式文件存储系统（distributed document store）。 它不会将信息使用结构化的行列表进行存储，而是存储已序列化为JSON文档的复杂数据结构。 当集群中有多个Elasticsearch节点时，存储的文档将分布式的存储在集群的多个节点中，并且可以从任何节点立即访问。

ES在存储文档时，将在1秒钟内，几乎实时地对文档进行建立索引和完成搜索。 Elasticsearch使用倒排索引（inverted index）的数据结构，该结构支持非常快速的全文本搜索。 倒排索引列出了出现在任何文档中的每个唯一单词，并标识了每个单词出现的所有文档。

ES中的索引可以看做是优化后的文档集合，其中每个文档都是多个字段（filed）组成的集合结构，这些字段是包含数据（data）的键值对（key:value）。默认情况下，Elasticsearch对每个字段中的所有数据建立索引，并且每个索引字段都具有专用的优化数据结构。例如，文本字段存储在倒排索引中，数字字段和地理字段存储在BKD树中。这种使用字段的数据结构，在组合并返回搜索结果时，使得Elasticsearch的搜索非常快速。

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

当然，如果不使用以上的默认方式，用户也可以自定义规则来控制动态映射，显式定义映射以指定字段的存储和索引方式。如果使用自定义的映射，则能够：

• 区分全文字符串字段和精确值字符串字段
• 执行特定于语言的文本分析
• 优化字段以进行部分匹配
• 使用自定义日期格式
• 使用无法自动检测到的数据类型，例如geo_point和geooshape

一般来说，根据不同的目的以不同的方式对同一字段（field）建立索引通常很有用。 例如，有时可能希望将一个字符串字段（string field）构建为全文搜索的文本字段（full-text search），或者是索引关键字（keyword field）以便对数据进行排序或汇总。 或者，有时可能会使用多个语言分析器来处理用户输入的同一字符串字段的内容。

ES在搜索数据时，会使用在索引期间建立的全文字段的分析链。 当查询全文字段时，对查询文本进行相同的分析，然后才能在索引中进行搜索。

信息导出：数据搜索和分析

虽然Elasticsearch常被用作文档存储，或检索文档及其元数据，但其真正的强大之处在于能够轻松访问基于Apache Lucene搜索引擎库构建的全套搜索功能。

Elasticsearch提供了一个简单、统一的REST API，用于管理ES集群、索引和搜索数据。 使用户可以轻松地直接从命令行或通过Kibana中的开发者控制台（Developer Console）提交请求。 在应用程序中，可以为Elasticsearch客户端选择需要使用的开发语言，例如：Java，JavaScript，Go，.NET，PHP，Perl，Python或Ruby，具体见：Elasticsearch client。

搜索数据

Elasticsearch REST API支持结构化查询（structured query）、全文查询（full text query）和结合了两者的复杂查询（complex query）：

• 结构化查询类似于在SQL中构造的查询类型。例如，在员工索引中搜索性别和年龄字段，然后按Hire_date字段对匹配项进行排序。
• 全文查询会找到所有与查询字符串匹配的文档，并按相关性（relevance）对它们进行返回——它们与搜索词的匹配程度（相关性分数）。

除了搜索单个术语（terms）外，还可以执行短语搜索、相似性搜索和前缀搜索。如果需要搜索地理空间或其他数字数据，Elasticsearch支持高性能的在地理和数字查询的优化数据结构中，索引非文本的数据。

用户可以使用Elasticsearch详细的JSON样式的查询语言（Query DSL）访问上述所有搜索功能。还可以构造SQL样式的查询（SQL-style queries）以在Elasticsearch内部本地搜索和聚合数据，并且可以使用JDBC和ODBC驱动程序，通过第三方应用程序使用SQL与Elasticsearch进行交互。

分析数据

Elasticsearch聚合（aggregation）提供了构建数据的复杂汇总，并深入了解关键指标（key metrics），模式（patterns）和趋势（trends）的功能。 通过聚合操作，不仅可以找到谚语“大海捞针”这种文本的检索数据，还可以回答以下问题：

• 大海捞针有多少根？
• 针的平均长度是多少？
• 针头的中位长度是多少，由制造商细分？
• 在过去六个月的每个月中，有多少根针被添加到大海里？

还可以使用聚合来回答更细微的问题，例如：

• 最受欢迎的针的制造商是哪些？
• 是否存在异常或者异常的针有哪些？

由于聚合功能使用了于搜索相同的优化数据结构，因此聚合的过程也非常快。 因此ES可以近乎实时的分析和可视化数据，及时的更新报告和系统监控仪表板上的数据，使得用户可以根据最新信息采取措施。

而且，聚合操作和搜索请求可以一起运行。 可以在单个请求中同时对数据进行搜索、过滤结果并执行分析。 而且由于聚合是在特定搜索结果的基础之上完成计算的，因此搜索结果不仅可以显示所有长度70大小的针数，而且还可以返回符合用户搜索条件（搜索子句criteria）的针——例如， 所有尺寸为70的不粘绣针（non-stick embroidery needles）。

机器学习数据分析

ElasticSearch提供了Machine Learning进行数据分析的功能，具体见：machine learning。

ES的可伸缩性和弹性：集群，节点和分片（shards）

Elasticsearch旨在提供高可用，和可扩展的系统功能，并通过自身具有的分布式存储结构来实现系统的弹性和可扩展性。用户可以将服务器（物理主机节点）添加到集群以增加计算和存储容量，此时Elasticsearch会自动在所有可用节点之间分配数据和均衡查询负载。很大程度的减少了用户对应用程序的修改，Elasticsearch知道如何平衡多节点集群以提供扩展性和高可用性。节点越多，系统的可用性和负载均衡的能力越好。

那么上面的可扩展性和弹性是如何运作的呢？在ES底层，Elasticsearch索引（index）实际上是一个或多个物理分片（shards）的逻辑分组，其中每个分片都是一个独立的索引。通过将文档分布在多个分片组成的一个逻辑索引，然后将这些分片分布在多个节点中，Elasticsearch实现了数据的冗余存储。这既可以防止硬件故障，又可以在将节点添加到集群中时提高查询能力。随着集群的增长（或收缩），Elasticsearch会自动迁移碎片以重新平衡集群。

上述的分片有两种类型：主分片和副本。索引中的每个文档都只属于一个主分片。副本分片是主分片的副本。副本可提供数据的冗余副本，以防止硬件故障并提高处理读取请求（例如搜索或检索文档）的能力。

创建索引时，索引中主分片的数量是固定的，但是副本碎片的数量可以随时更改，而不会中断索引或查询操作。

分片的数量配置

对于上述分片的大小和为索引配置的主分片数量方面，存在许多性能方面的考虑和权衡取舍。 碎片越多，维护这些索引的开销就越大。 分片大小越大，当Elasticsearch需要重新平衡集群时，移动分片所需的时间就越长。

查询很多小的分片会使每个分片的处理速度更快，但是更多的分片也查询意味着更多的开销，因此查询较小数量的大分片可能会更快。 简而言之，分片数量的设置需要视情况而定。

一般情况下：

• 将平均分片大小保持在几GB到几十GB之间。 对于基于时间的数据存储，通常会看到20GB到40GB范围内的碎片。
• 避免庞大的碎片问题。 节点可以容纳的分片数量与可用堆（heap）空间成比例。 通常，每GB堆空间中的分片数量应少于20。

此外，确定使用中最佳配置的最好方法是通过使用自己的数据和查询进行测试，来确定分片的大小和数量，具体参见：testing with your own data and queries。

集群容灾问题

出于性能的原因，ES集群内的节点必须位于同一网络上。 跨不同数据中心中的节点的群集中的碎片平衡将花费更长的时间开销。 但是高可用性架构的要求，避免将所有鸡蛋都放在一个篮子里。 如果一个位置发生重大故障，则另一个位置的服务器需要能够接管。 这就需要：跨集群复制（Cross-cluster replication，CCR）。

CCR提供了一种方法：可以自动将索引从主集群同步到可以用作热备份的辅助远程集群。 如果主集群出现故障，则辅助集群可以接管。 同时，还可以使用CCR创建辅助集群，以接近地理位置的方式向用户响应读取请求。

跨集群复制是主动——被动的。 主集群上的索引是活动的leader索引，并处理所有写请求。 复制到辅助集群的索引是只读的follower。

集群监控和管理

与任何企业系统一样，需要工具来保护、管理和监视Elasticsearch集群。 Kibana作为控制中心来管理ES集群，它为Elasticsearch提供了安全性、监视和管理等功能。 数据汇总（data rollups ）和索引生命周期管理（index lifecycle management）等功能则可帮助用户随着时间的推移智能地管理数据。