本文主要围绕ES核心特性：分布式存储特性和分析检索能力，介绍了概念、原理与实践案例，希望让读者快速理解ES的核心特性与应用场景。
Elasticsearch可以实现秒级的搜索，cluster是一种分布式的部署，极易扩展(scale )这样很容易使它处理PB级的数据库容量。最重要的是Elasticsearch使它搜索的结果可以按照分数进行排序，它能提供我们最相关的搜索结果（relevance) 。
本文分享了在工作中关于 ElasticSearch 的一些使用建议。和其他更偏向手册化更注重结论的文章不同，本文将一定程度上阐述部分建议背后的原理及使用姿势参考，避免流于表面，只知其然而不知其所以然。如有不当的地方，欢迎指正！
本文介绍了一次排查Elasticsearch node_concurrent_recoveries 引发的性能问题的过程。
我们小组主要负责四轮场景下的司乘匹配工作，基于开源分布式搜索引擎ElasticSearch实现订单的召回。同时我们使用Flink实时消费kafka消息，将订单数据写入到对应的ES索引中。
canal 是阿里知名的开源项目，主要用途是基于 MySQL 数据库增量日志解析，提供增量数据订阅和消费。 这篇文章，我们手把手向同学们展示使用 canal 将 MySQL 增量数据同步到 ES 。
Qunar 的实时日志平台使用的是 ELK 架构，其中 Elasticsearch 集群（以下简称：ES 集群）和 kibana 平台在机房 A，Logstash 集群在机房B。 目前机房 A 在使用过程中存在以下一些问题隐患： 机房 A 目前为饱和状态，批量新增机器难以支持 机房 A 主要由 Hadoop、ES 集群组成，业务交互会产生大量跨机房流量，峰值会影响到业务 基于上述因素，与 Ops 同事沟通后，决定整体迁移 ES 集群到机房 B。这样不仅可以解决上述两个问题，和写入端的 Logstash 集群也同在一个机房，网络通信更有保障。 此文主要介绍 ES 集群节点迁移实战过程中的一些实践与探索演进经验，对于日常的平台开发与运维也能有所借鉴和参考。
