一、概念扫盲（index（数据库） -> type（表） -> mapping（映射） -> document（一行数据） -> field（字段））
elasticsearch设计的理念就是分布式搜索引擎，底层其实还是基于lucene的。
核心思想就是在多台机器上启动多个es进程实例，组成了一个es集群。
es中存储数据的基本单位是索引，比如说你现在要在es中存储一些订单数据，你就应该在es中创建一个索引，order_idx，所有的订单数据就都写到这个索引里面去，一个索引差不多就是相当于是mysql里的一张表。index -> type -> mapping -> document -> field。
index：mysql里的一个数据库。
type（新版本已经废弃）：没法跟mysql里去对比，一个index里可以有多个type，每个type的字段都是差不多的，但是有一些略微的差别。
实际上你往index里的一个type里面写的一条数据，叫做一条document，一条document就代表了mysql中某个表里的一行数据，每个document有多个field，每个field就代表了这个document中的一个字段的值。
二、es为什么天生就是分布式
一个索引，这个索引可以拆分成多个shard，每个shard存储部分数据。ES 默认为一个索引创建 5 个主分片, 并分别为其创建一个副本分片，也就是说每个索引都由有5 个主分片, 而每个主分片都相应的有一个 copy。
接着就是这个shard的数据实际是有多个备份，就是说每个shard都有一个primary shard，负责写入数据，但是还有几个replica shard。primary shard写入数据之后，会将数据同步到其他几个replica shard上去。通过这个replica的方案，每个shard的数据都有多个备份，如果某个机器宕机了，还有别的数据副本在别的机器上呢。
es集群多个节点，会自动选举一个节点为master节点，这个master节点其实就是干一些管理的工作的，比如维护索引元数据拉，负责切换primary shard和replica shard身份拉，之类的。要是master节点宕机了，那么会重新选举一个节点为master节点。
如果是非master节点宕机了，那么会由master节点，让那个宕机节点上的primary shard的身份转移到其他机器上的replica shard。急着你要是修复了那个宕机机器，重启了之后，master节点会控制将缺失的replica shard分配过去，同步后续修改的数据之类的，让集群恢复正常。
其实上述就是elasticsearch作为一个分布式搜索引擎最基本的一个架构设计。
三、实际部署
（1）es生产集群我们部署了3台机器，每台机器是4核32G的，集群总内存是120G
（2）我们es集群的日增量数据大概是100万条，每天日增量数据大概是50MB，每月增量数据大概是3000万，1.5G。目前系统已经运行了几个月，现在es集群里数据总量大概是10G左右。
（3）目前线上有1个索引（这个结合你们自己业务来，看看自己有哪些数据可以放es的，所以这个数据量之内，我们每个索引分配的是默认的5个shard
