前言
伴随着业务的迭代，我们能预见到的第一个问题往往是来自数据库。
在Elasticsearch没出现之前，如果MySQL数据库的某张表的数据量涨到1亿，复杂的查询条件下总是返回TimeOut，你只能尝试分库，分表，分区，添加索引，迁移数据到 PostgreSQL或MariaDB，添加缓存……忙忙碌碌10多天发现效果并不理想，最终只能寻求业务上的妥协。
所有开发人员都在寻找一种轻松应对海量数据管理的工具，Elasticsearch为此而生。
一. 问题
监控平台上显示有接口标红（耗时26秒），进一步排查发现主要耗时在SQL执行层。具体信息如下：
该表有4亿数据，占用90G磁盘（InnoDB引擎）。
SQL语句中用到了avg,sum等计算，基于MySQL优化的空间非常小。
项目中使用了大量的ORM和原生SQL，修改项目代码的风险较大。
最初我希望找到一种方案实现“透明”优化（不改代码逻辑），在尝试多种方案后放弃。最后选择 Elasticsearch 实属无奈，大量ORM和原生SQL需要重写。引入新技术是为了解决主要问题，新技术肯定会带来新的问题，如何抉择？每次我都会想到马车和汽车，汽车比马车速度快，能解决人们出行的主要问题，即使汽车带来了污染，维修，事故，拥堵等，最终汽车敲开了新世界的大门。
Tips: 官方提供了 elasticsearch-sql 工具，可将SQL转换成elasticsearch的查询DSL，节约开发时间。
二. Elasticsearch使用效果
使用Elasticsearch后，对于单Type（Elasticsearch中Type等同于表）4亿数据，各种复杂的搜索条件都能1秒内返回。具体架构如下
如果服务器9200端口无法访问，可以通过Nginx做一次转发。对于客户端来说所有操作都能通过http接口实现。对于Elasticsearch集群来说，只需要添加机器、摘除机器。所有数据同步、负载均衡等操作都由Elasticsearch的内部机制实现。
三. Elasticsearch内部结构
第一次接触Elasticsearch，很多名词不好理解，可与MySQL类比加深印象：
| Elasticsearch | MySQL |
|---|---|
| Cluster（集群） | 数据库集合 |
| Node（节点） | 服务器 |
| Index（索引） | Database（数据库） |
| Type（分类） | Table（数据库表） |
| Document（文档） | Data（数据） |
图片说明：
Node（节点）表示Elasticsearch服务进程，一台物理机上可以启动一个或者多个Node（Elasticsearch服务进程）。Node中存放着一个或者多个分片，每个分片都是一个独立的Lucene 搜索引擎（下面会谈到）。
Index（索引）等同于MySQL的Database，每个Index下都有一个或者多个分片（系统默认分配5个），下图是索引与节点的关系图
Type（分类），等同于MySQL的Table，很容易理解。处理数据时需要指定Index和Type，与MySQL执行需要指定数据库和表名一样。
Document（文档）等同于MySQL的一行数据，同样需要设置属性名和数据类型。不过Document中的属性用Field表示，使用Json格式，每个Document都可能会有不同的Field集合这与MySQl的属性概念差别非常大。
Shard（分片）在上文Node和Index中都提到了分片信息，他是Elasticsearch特有的结构。通过分片能实现水平扩容，分布式部署达到提高性能/吞吐量。
四. Luncene介绍
Elasticsearch能搭建高性能可扩展的集群，离不开Lucene搜索引擎，在学习Elasticsearch时一定要对Lucene有所了解。
Lucene是一个成熟的、高性能的、可扩展的、轻量级的，功能强大的搜索引擎。类似于Sphinx、Xapian。
如图所示：
Lucene 能够为文本类型的数据建立索引，只要源数据的格式能转化为文本格式，Lucene 就能进行索引和搜索。比如你要对一些 HTML 文档，PDF 文档进行索引，只需要把 HTML 文档和 PDF 文档转化成文本格式，然后将转化后的内容交给 Lucene 进行索引， Lucene会把创建好的索引文件保存到磁盘或者内存中，最后根据用户输入的查询条件在索引文件上进行查询。
索引是现代搜索引擎的核心，建立索引的过程就是把源数据处理成非常方便查询的索引文件的过程。为什么索引这么重要呢，试想你现在要在大量的文档中搜索含有某个关键词的文档，那么如果不建立索引的话你就需要把这些文档顺序的读入内存，然后检查这个文章中是不是含有要查找的关键词，这样的话就会耗费非常多的时间，想想搜索引擎可是在毫秒级的时间内查找出要搜索的结果的。这就是由于建立了索引的原因，你可以把索引想象成这样一种数据结构，他能够使你快速的随机访问存储在索引中的关键词，进而找到该关键词所关联的文档。Lucene 采用的是一种称为反向索引（inverted index）的机制。反向索引就是说我们维护了一个词 / 短语表，对于这个表中的每个词 / 短语，都有一个链表描述了有哪些文档包含了这个词 / 短语。这样在用户输入查询条件的时候，就能非常快的得到搜索结果。
Elasticsearch的搜索速度能如此快，得益于 Lucene 的反向索引机制，也叫倒排索引(inverted index)。
与Lucene一样，Elasticsearch 同样会将索引文件保存到内存中，由于JVM heap分配不能超过32GB的内存（超过32GB以后，JVM的对象指针压缩失效，实际可能内存反而更小），所以一个Elasticsearch节点最大只能将32G的数据放入内存。如果机器是128G的，最好启用3个Elasticsearch节点；
五. Elasticsearch平台搭建
Linux和Windows上都能搭建Elasticsearch，搭建成本非常低。这里举例通过CentOS的yum安装java1.8
1 | $ yum install java-1.8.0-openjdk.x86_64 |
使用 2.3.4 版本是因为从MySQL实时同步数据到 Elasticsearch 需要使用JDBC importer，JDBC importer 最高只支持elasticsearch-2.3.4。如果你的系统不需要使用JDBC importer可安装更高版本的Elasticsearch 。
假如你需要从MySQL同步数据到elasticsearch使用JDBC importer将非常方便。
Elasticsearch可以开箱即用，当然也可以针对自己的服务器环境做一些初始化设置。修改Elasticsearch的配置文件 config/elasticsearch.yml，设置集群名称，存储路径。添加新服务器，只需要重复如上步骤，拷贝配置文件 config/elasticsearch.yml到新服务器再做如下简单修改
1 | # 修改0.0.0.2服务器上的配置文件 |
为了方便管理 Elasticsearch 集群，建议在本地安装一个Chrome扩展 ElasticSearch Head 。
六. 使用技巧
Document（文档）的json结构需要尽量统一，能提高搜索速度；
分片一定要有1个或者多个复制分片；
为什么需要多个复制分片？不是会有大量冗余吗？
Elasticsearch的性能提升与水平扩容主要是通过复制分片实现。创建索引时就已经确定了分片的数量（默认是5），这个参数后期无法再修改。前面提到过一个分片就是一个Lucene搜索引擎，当数据量达到PB级别，5个搜索引擎肯定承受不了。在无法添加分片的情况下，我们可以动态添加复制分片，比如为每个分片设置6个复杂分片，再添加6台机器，这样数据就备份了6份，每一份单独运行在一台机器上，理论上搜索性能可提升6倍；6个复制分片就是6份全量备份，冗余很严重，空间换时间不要太在意冗余。
主分片与复制分片不能在一个节点上，否则毫无意义。一是机器硬件出问题，数据会全部丢失。二是分片和复制分片共用内存和磁盘，机器慢所有分片都会慢。
索引下的分片也不能太多，数据同步非常耗性能，默认的5个分片是官方经过测试后给的最优方案；
冷数据存储需要做特殊处理，减少机器的负担；
关于节点和分片数的配置遵循如下公式： 节点数 = （复制分片+1）* 分片