分片和副本相关基础：
number_of_shards :类似我们分库分表， 一经定义，不可更改。影响写入操作。
比如有四条数据
id：1234.
2个shards
id%len = ？
1和3存在shard1
2和4存在shard2
如果突然修改了分片数，就只能重建索引了。
numer_of_replicas:副本数 ，用来备份分片的和分片里的数据保持一直，只要用相应读操作，副本越多读取速度越快。（可以随便调整）
分布式索引的分片数量一定不难更改，8核cpu 16g的机器一个分片不超过500g，索引会根据分片的配置来均匀的相应用户请求。
如果装了head ，
写请求：不管咋样都会到master节点上要到master节点上hash取模来判断存到哪个shard上去。
读请求：不一定要到master，因为每个node上都存了节点信息。读也是确定hash，然后到哪个分片上读。
put：全量修改数据。
post：部分修改数据。（在kinbana里记得加_update)
es基础类型：
type：文本类型（可以被分析）。
keyword：不可以被分析。要求全字匹配的文本。
date：日期类型， 通常配合format使用，{“type”：‘date“，”format“：yyyy-MM-dd”}，
long， short， intger，
array ：数组类型，但是因为性能， 几乎没什么用的。
object： 一般是json。
ip： ip地址
goe （地理位置，geohash应该是）： lat，let
es查询：
1.主键查询。
2.查询all。
3.分页查询。
es分页不能分的太多， 因为都在内存里进行，所以es不支持全部导出，分页千万别超出一万。
4.待条件查询。
5.排序查询（sort）。
6.聚合查询，（支持很多，avg，min，max， sum等）
分词相关：
es默认分词器stander，把每个字都分开。
做了一个标准化， 英文默认优化，会提取词干，例如apples ， 直接提取成apple。
ik分词器：
sname的话，用的贪心算法， 尽量分词长的。
是不是就意味着stander分词没用了？其实并不是这样的哦
托底，搜江大桥没有，在建了ik的字段，在建一个一样的stander的字段。如果ik搜不到 就可以搜这一个stander分词的，这样保证会又结果。但是慎用，因为占空间，有些特殊的系统可以使用。
其实ik也还有一个解决的办法叫砍词：江大桥 我可以砍掉一个词，我砍掉江 就出来了。砍词的策略可以自定义
江大桥：电商中。我们系统假设有大桥这个品牌。 我会一个个的是去试一下，比如可以用字符串匹配找出大桥。也有很多系统很粗暴，直接从第一个字开始砍，一直砍到有为止。
既有英文又有中文的 直接选ik
如果不用砍词那就要去词库加词，比如加入江大桥就可以了。
