虽然你可以使用Elasticsearch来存储文档和检索文档和它们的元数据，Elasticsearch真正的强大之处在于，它能够轻松访问构建在Apache Lucene搜索引擎库上的完整搜索功能套件。

Elasticsearch提供了简单、明确的REST API来管理集群和索引文档和检索数据。用于测试的目的，你可以直接通过命令行的方式或者在Kibana的开发者控制台（Developer Console）中发送命令。Elasticsearch也提供了Java, JavaScript, Go, .NET, PHP, Perl, Python or Ruby客户端供你使用。

检索数据

Elasticsearch REST APIs支持结构化查询，全文检索和两个联合起来的复杂查询。结构化查询类似于构建sql查询那样。例如，你可以搜索gender和age字段在employee索引中并且通过hire_date进行排序。全文搜索会查找所有跟查询的字符串相匹配的文档，并且根据相关性（跟搜索的字符串的匹配程度）排序。

除了搜索单个关键字，你还可以短语搜索、 相似度搜索、前缀搜索，和获得自动化建议。

想搜索地理或者数值型数据？Elasticsearch使用优化的数据结构来索引这些非文本数据，使得Elasticsearch搜索效率变得高效。

所有Elasticsearch支持的查询方式，你都可以使用Elasticsearch的Json风格的查询语言来进行查询。你也可以在Elasticsearch中使用Sql风格的查询方式来搜索和聚合数据，JDBC和ODBC驱动允许应用程序通过sql与Elasticsearch交互。

分析数据

Elasticsearch的聚合功能使得你能构建复杂的统计，并深入了解关键指标、形态和趋势。而不仅仅只是找到海量数据里面的一条。聚合能解决类似下面的问题：

  • 有多少条数据？
  • 数据的平均大小是多少？
  • 数据中位数是多少，按制造商进行分类？
  • 最近六个月新增了多少条数据？

聚合也可以解决更加细微的问题，比如：

  • 最热门的数据是哪些？
  • 有不正常或者不规则的数据块？

Elasticsearch的聚合使用的是相同的数据结构来搜索，所以也是非常高效的。你可以实时的分析和可视化你的数据。当你的数据发生变化时，你的报表和仪表盘可以基于最新的数据做出响应。

此外，聚合操作可以和搜索一起使用。你可以在单个请求里面针对同一个数据并且同时进行搜索文档，过滤结果，和执行分析。而且由于聚合是在特定搜索的上下文中计算的，因此您不仅要显示所有尺寸为70的针的数量，还要显示符合用户搜索条件的70号针的数量——例如，所有尺寸为70号的不粘绣花针。

等等，还有彩蛋

想要自动分析你的时间序列化数据？你可以使用机器学习特性来创建你的数据正常行为的基准钱来识别出异常模式。通过机器学习，你可以：

  • 与数值、计数或频率的时间偏差有关的异常
  • 统计稀有度
  • 数据中某一条异常的数据

最棒的是，实现这些完全不需要指定的算法、模型或者其它数据科学相关的配置。

伸缩性和弹性：集群、节点、分片

Elasticsearch被设计为高可用，并且可以根据你的需求进行扩展。通过自然分布来实现这一点。你可以增加节点Elasticsearch会自动把你的数据和查询请求负载到所有可用的节点上。不需要修改你的应用程序，Elasticsearch知道如何平衡多节点集群来提供伸缩性和高可用。

这是怎么实现的？在底层，一个Elasticsearch索引是一个或多个物理分片的逻辑分组，每个分片是一个自我包含的索引。将文档分布在多个分片的相同索引上，又把分片分布在多个节点上，Elasticsearch可以冗余数据，这样可以避免硬件故障，当节点的加入集群时，查询能力也能随着增加。随着集群的增长或者减少，Elasticsearch可以自动迁移分片使集群重新平衡。

Elastcisearch有两种类型的分片：主分片和复制分片。索引中的每一个文档都属于一个分片。复制分片是主分片的备份。复制分片冗余数据来避免硬件故障同时也增加了服务的查询能力，比如搜索或者检索一个文档。

索引的主分片数量只能索引创建时指定。但是复制分片的数量可以在任何时候修改，并且不会影响索引和查询操作。

这取决于…

对一个索引设置分片数量和分片容量大小，有很多性能和权衡的需要考虑。分片数越多，维护这些索引的开销也就越大。分片的容量越大，当Elasticsearch平衡集群移动分片时所花费的时间也越多。

对大量的小容量分片进行查询，每个分片的查询速度是很快的，但是查询请求越多，开销也就越大。这就意味着对小数量、大容量的分片进行查询，速度可能会快一点。简而言之…视情况而定。

一开始的注意点：
平均每个分片的容量保持在几GB到几十GB之间。对于时间序列化的数据，一般建议在20GB到40GB之间。
避免大量分分片问题，一个节点所能支持的分片数量是跟可用对空间成正比的。一般而言，每GB可用堆空间的分片数量应小于20.

为你的应用场景选择最佳的配置的最好方式是测试你的数据和查询请求。

容灾

出于性能的考虑，集群中的节点需要处于同一网络。在一个横跨不同数据中心的集群中平衡分片花费时间太长了。但是高可用的设计架构强烈要求避免“把鸡蛋都放在一个篮子里”。如果一个区域停电，那么其它区域的服务需要无缝的接管。解决方案？跨集群复制-Cross-cluster replication (CCR).

CCR提供了一种方法，可以自动把你的主集群中索引同步到远程副本集群。如果主集群挂了，备用集群可以接管。你也可以使用CCR来创建副本集群以服务那些在地理位置接近的用户请求。

跨集群复制-Cross-cluster replication是主动的也是被动的。主集群上的索引是leader（领导）索引，处理所有写请求。副本上的索引是只读的followers（追随者）。

监控和管理

与其它企业系统一样，你都需要工具来保护、管理和监控你的Elasticsearch集群。安全、可监控、管理的特性也集成到了Elasticsearch，你可以使用Kibana作为管理集群的控制中心。像数据归档和索引生命周期这些特性能帮你随时智能化的管理你的数据。