关于Elasticsearch的一些点

基本介绍

Elasticsearch是一个高伸缩、高可用开源的分布式实时搜索与分析引擎，支持云服务。它是基于Apache Lucene搜索引擎的类库创建的，提供了全文搜索能力、多语言支持、专门的查询语言、支持地理位置服务、基于上下文的搜索建议、自动完成以及搜索片段（snippet）的能力。通过它你可以很方便地对数据进行深入挖掘，可以随时放大与缩小搜索与分析的区间，并且这一切都是实时的。

Elasticsearch支持RESTful的API，可以使用JSON通过HTTP调用它的各种功能，包括搜索、分析与监控。此外，它还为Java、PHP、Perl、Python以及Ruby等各种语言提供了原生的客户端类库。

Elasticsearch既可以搜索、也可以保存数据。它提供了一种半结构化、不依赖schema并且基于JSON的模型，你可以直接传入原始的JSON文档，Elasticsearch会自动地检测出你的数据类型，并对文档进行索引。你也可以对schema映射进行定制，以实现你的目的，例如对单独的字段或文档进行boost映射，或者是定制全文搜索的分析方式等等。

Elasticsearch与传统的数据搜索的不同

Elasticsearch是用于实时全文搜索的，实时的全文搜索，按照通俗的说法，传统的搜索其实就是全文搜索的一个子集。大多数数据存储系统都是基于元数据，或是原始数据的某些部分实现搜索功能的。出于效率方面的原因，那些我们认为相关的数据子集（例如对象的id、name等等）会被索引，而其余部分则被忽略。与原始数据大小相比，所生成的索引数据量比较小，但它没有完全覆盖到所有的数据集。全文搜索解决这个问题的方式是对整个数据资料进行索引和搜索，代价就是对存储空间的需求增加（空间换时间）。

传统的搜索通常是与结构化数据相关的，因为对用户来说结构化数据更容易理解哪些数据是相关的，而哪些是不相关的。但当前的业务中，大多数数据都是非结构化的。你会将所有数据一次性保存起来，在需要的时候再去获取它的各种不同格式与结构的值，在这种情况下就必需用到全文搜索的方式，因为你已经无法忽略任何数据了。

Elasticsearch同时支持结构化数据搜索与全文搜索，它提供了大量的查询选项，包括关键字、布尔查询、过滤器以及模糊查询等方式，所有这些都选项都可以通过一个丰富的查询语言来完成。

请注意，Elasticsearch与简单的全文搜索相比，还提供了以下一些额外的特性：

1. 地理位置查询：根据数据的地理位置查找结果。
2. 聚合/分面：在查询的时候进行数据聚合，例如查找在某一天之内，访问过你的网站中某篇特定文章，或者是某些标签的用户来自哪些国家。由于聚合是实时计算的，因此当查询变化时，聚合也会相应的变化。换句话说，就是你总能获取数据集的即时反馈。

Elasticsearch引擎所支持的设计与架构模式

一个索引包括了多个分片，每个分片本身就是一个迷你的搜索引擎。一个索引本质上就是对应着一系列分片的虚拟命名空间。多分片的方式能够简化横向扩展任务，只需添加新的节点即可。而创建分发分片对每个主分片的数据进行复制能够实现高可用性，并增加读取时的吞吐能力。

查询某个索引是一种分布式操作，这意味着Elasticsearch不得不对索引中的每个分片的数据复制进行查询，并将结果整理到一个单一的结果集中。而对多个索引进行查询只是将相同的步骤进一步扩大了而已。在设计你的数据存储架构时，这种方式能够带来极大的灵活性。

而如果用户了解他的应用程序特定的一些领域知识，那就可以对查询进行优化，使查询只触及相关的分片。在同样的硬件条件下，这种方式可以支持更大的负载。

Elasticsearch是怎样支持数据的可伸缩性

为了支持高可用性与高伸缩性，Elasticsearch本身就是分布式设计的。从顶层的角度来说，Elasticsearch在索引（或者集合）中保存文档（或者数据记录），每个集合又分解为多个小块，称为分片。索引越大，所需要分配的分片越多（不必担心会创建过多的分片，它的开销很小）。取决于Elasticsearch的设置和规模，分片会在集群中均匀地平均分布，有两个原因：

1. 出于冗余方面的原因：默认情况下，Elasticsearch为每个分片都准备了一份拷贝，一旦某个节点停机了，备份的分片就能接替它的位置。
   2. 出于性能方面的原因：每个查询都发生在某个索引上，并且会在多个分片中并行运行，这种工作流方式是改善性能的关系所在。如果感觉运行速度缓慢，只需简单地在集群中加入新的机器，Elasticsearch就会自动地将分片与查询进行分布到新添加的机器上。
           

这种方式让使用Elasticsearch的组织可以自由选择进行纵向扩展（如果节点运行缓慢就升级硬件）或者横向扩展（如果集群整体速度慢就加入更多的节点）。

联合使用Elasticsearch与Hadoop技术具有的优势

Hadoop在设计上就是一个分布式的，面向批处理的平台，用以处理大数据集。虽然它是一个非常强大的工具，但它的批处理的本质意味着在处理结果时需要花费一定时间。此外，用户必需重新为各种操作编写代码。Hive或者Pig这样的类库能起到一定作用，但不能完全解决问题，想象一下在Map/Reduce中重新实现地理位置查询的难度吧。而使用Elasticsearch，你就可以将搜索工作交给搜索引擎去完成，而专注于其它方面的工作，例如数据转换。

Elasticsearch-Hadoop项目为Hadoop提供了直接的整合功能，因此用户使用起来没有任何障碍，我们为vanilla Map/Reduce提供了专门的InputFormat与OutputFormat，为Cascading的数据读写提供了Taps，并为Pig和Hive提供了Storages。这样你就可以以HDFS一样方式的访问Elasticsearch的数据了。

通常来说，与Hadoop进行整合的数据存储系统都可能会成为系统的瓶颈，这是由于每个job在集群中的各种任务会造成大量的请求。而Map/Reduce模型的分布式特性用于Elasticsearch上会配合得非常良好，因为我们能够将某个特定查询所生产的Map/Reduce任务数量与Elasticsearch的分片数量相关联。这样每次有查询运行时，系统就会动态地按照Hadoop的划分生成一个数值，该数值与Elasticsearch的可用分片数量成正比，这样各个job就能够并行地运行了。你可以按照Elasticsearch的数量对Hadoop集群进行扩展，或者是反过来也可以。

此外，这种整合将分片的信息暴露给Hadoop，以此可以实现协同定位。Job的任务会在每个Elasticsearch分片所在的同一台机器上运行，通过实现数据本地化消除了网络的开销，并改善了性能。出于这个原因，我们建议你在相同的机器上运行Elasticsearch和Hadoop集群，尤其是他们能够互相平衡资源的使用情况（I/O与CPU）。

最后但也是很重要的一点是，Elasticsearch能够提供近乎实时的响应速度（毫秒等级），这极大的改善了Hadoop job的执行速度以及执行的各种开销，在类似于Amazon EMR这种“租用的资源”上运行时的改善尤其明显。