[翻译]ElasticSearch官方文档

前段时间在做ElasticSearch数据分析相关的工作，一直想翻译ES的官方文档，相当于ES的入门文档吧。

Elasticsearch是一个高度可扩展的开源全文搜索和分析引擎。它允许用户快速，实时地存储，搜索和分析大量数据。ES通常用作为具有复杂的搜索功能和要求的应用程序提供的底层引擎/技术。

官方提供了几个示例用例：

官方文档的其余部分将引导用户完成ES的运行过程，并在其中进行查看，并执行索引，搜索和修改数据等基本 *** 作。而最后，用户将了解它的工作原理以及和对此的启发，以了解如何使用它来构建复杂的搜索应用程序或从数据中挖掘智能。

有几个概念是Elasticsearch的核心。从一开始就理解这些概念将大大有助于缓解学习过程。

Elasticsearch是一个接近实时的搜索平台。这意味着从你索引一个文档到该文档可搜索的时间稍微延迟（通常为1秒）。

集群是一个或多个节点（服务器）的集合，它们共同保存整个数据，并在所有节点之间提供联合的索引和搜索功能。集群由唯一的名称标识，默认情况下是“elasticsearch”。此名称很重要，因为如果节点设置为通过其名称加入集群，则节点只能作为集群的一部分。确保不要在不同环境中重复使用相同的集群名称，否则可能会导致节点加入错误的集群。例如，你可以对开发，分段和生产集群使用logging-dev，logging-stage和logging-prod。请注意，拥有只有一个节点的集群是有效和完美的。此外，你还可以拥有多个独立的群集，每个群集都有自己独特的群集名称。

节点是作为集群一部分的单个服务器，存储数据，并参与集群的索引和搜索功能。就像一个集群一样，一个节点被一个名称标识，默认情况下是一个随机的通用唯一标识符（UUID），它在启动时分配给节点。如果你不想要默认值，你可以定义所需的任何节点名称。此名称对于管理目的很重要，你希望确定网络中的哪些服务器对应于Elasticsearch集群中的哪些节点。可以将节点配置为按集群名称加入特定集群。

默认情况下，每个节点都设置为加入名为elasticsearch的群集，这意味着如果你在网络上启动了多个节点，并且假设它们可以相互发现，则它们将自动形成并加入名为elasticsearch的单个群集。

在单个集群中，你可以拥有很多你所需所需的节点数。此外，如果没有其他d性搜索节点运行在你的网络上，启动单个节点将默认形成名为elasticsearch的新的单节点群集。

索引是具有某种相似特征的文档的集合。例如，你可以拥有客户数据的索引，产品目录的一个索引，以及订单数据的另一个索引。索引由名称（必须全部为小写）标识，该名称用于在针对其中的文档执行索引，搜索，更新和删除 *** 作时引用索引。

在单个集群中，你可以根据需要定义任意多的索引。

在索引中，你可以定义一个或多个类型。类型是索引的逻辑类别/分区，其语义完全取决于你。通常，为具有一组公共字段的文档定义了一种类型。例如，假设你运行一个博客平台，并将所有数据存储在单个索引中。在此索引中，你可以定义用户数据的类型，博客数据的另一种类型以及注释数据的另一种类型。

文档是可以索引的基本信息单元。例如，你可以拥有单个客户的文档，单个产品的另一个文档，以及单个订单的另一个文档。文档以JSON表示，这是一种无处不在的互联网数据交换格式。在索引/类型中，你可以存储尽可能多的文档。请注意，虽然文档物理上位于索引中，但实际上文档实际上必须被索引/分配给索引中的类型。

索引可能潜在地存储可能超过单个节点的硬件限制的大量数据。例如，占用1TB磁盘空间的10亿个文档的单个索引可能不适合单个节点的磁盘，或者可能太慢，无法单独从单个节点提供搜索请求。
为了解决这个问题，Elasticsearch提供了将索引细分为多个称为碎片的片段的功能。创建索引时，你可以简单地定义所需的分片数。每个分片本身就是一个全功能且独立的“索引”，可以在集群中的任何节点上托管。
分片是重要的两个主要原因：

如何将其文档聚合回搜索请求完全由Elasticsearch管理，对用户来说对你是透明的。

在可以随时预期故障的网络/云环境中，非常有用，并强烈建议使用故障切换机制，以防止分片/节点因为某种原因脱机或消失。 为此，Elasticsearch允许你将索引的碎片的一个或多个副本复制到所谓的复制分片，或简写为复本。

副本是重要的两个主要原因：

总而言之，每个索引可以分成多个分片。 索引也可以被复制为零（意味着没有副本）或更多次。 一旦复制，每个索引将有 主碎片（复制的原始碎片）和副碎片（主碎片的副本）。 可以在创建索引时为每个索引定义碎片和副本的数量。 创建索引后，你可以随时动态更改副本数，但不能更改事后的分片数。

默认情况下，Elasticsearch中的每个索引都分配了5个主分片和1个副本，这意味着如果你的集群中至少有两个节点，则索引将具有5个主分片和5个复本分片（1个完整副本），总共 每个指数10个碎片

注意：每个d性搜索碎片都是Lucene索引。 在一个Lucene索引中可以有最多的文档数量。 从LUCENE-5843起，限制为2,147,483,519（= IntegerMAX_VALUE - 128）文档。 你可以使用_cat / shards API监视分片大小。

域名解析耗时就是将域名解析获得对应IP地址，并返回给客户端这个过程所消耗的时间。

当我们对某个域名发起访问，并不是直接就能对响应站点发起访问的，需要借助DNS获取域名与IP地址对应关系，在取得解析记录之后，才能发起访问。

解析过程的具体流程大致如下：

（1）客户端对某个域名发起访问。

（2）浏览器会首先对浏览器、系统缓存以及本机HOSTS文件等本地信息进行查询，如果有结果直接告知客户端，解析过程结束。

（3）如果本地没有结果，浏览器就会请求递归服务器，递归服务器有结果就会告知客户端，解析过程借宿。

（4）如果递归服务器没有结果，就会委托递归服务器进行全球递归查询，首先请求根域名。

（5）根域名告知递归服务器域名所在的顶级域名服务器，递归服务器对顶级服务器发起请求。

（6）顶级服务器告知递归服务器域名所在的权威域名服务器，权威域名服务器将解析记录告知递归服务器。

（7）递归服务器将结果再告知客户端，解析过程结束。

流程图如下所示：

由此可见，影响域名解析耗时的因素有以下几点：

（1）本地缓存

如果本地缓存中有域名和IP地址的对应关系，就会直接在本机获取结果，无需进行全球递归查询，这样解析用时就大大缩短，但缓存对于解析安全有较大影响；

（2）递归服务器

一般而言，我们无法决定用户使用何种DNS Server，大部分初级用户使用的是本地ISP自动获取的DNS Server，部分用户则使用第三方DNS Server比如Open DNS或者Google DNS。

不过你可以建议你的用户使用Google DNS (8888 和8844)，该DNS Server会比电信或网通自动获取的DNS Server快许多。

（3）权威域名服务器

权威域名服务器时影响域名解析耗时的关键，一般的解析服务器都是单节点单线路，如果域名距离较远，可能就会因为跨域跨网造成较大的延迟，如果域名的访问量大，还会造成线路的拥堵。所以为了减少解析时间，建议选择性能较好，多节点，多线路的权威域名服务器。

---