1. 创建索引，修改索引，删除索引
//创建索引
PUT /my_index
{
"settings": {
"number_of_shards": 1,
"number_of_replicas": 0
},
"mappings": {
"my_type": {
"properties": {
"my_field": {
"type": "text"
}
}
}
}
}
//修改索引
PUT /my_index/_settings
{
"number_of_replicas": 1
}
//删除索引
DELETE /my_index
DELETE /index_one,index_two
DELETE /index_*
DELETE /_all
2. 默认分词器standard
standard tokenizer：以单词边界进行切分
standard token filter：什么都不做
lowercase token filter：将所有字母转换为小写
stop token filer（默认被禁用）：移除停用词，比如a the it等等
修改分词器设置：
启用english停用词token filter
PUT /my_index
{
"settings": {
"analysis": {
"analyzer": {
"es_std": {
"type": "standard",
"stopwords": "_english_"
}
}
}
}
}
3.内核--type底层数据结构
type，是一个index中用来区分类似的数据的，类似的数据但可能有不同的fields；
field的value，在底层的lucene中建立索引的时候，全部是opaque bytes类型，不区分类型的，因为lucene是没有type的概念的，在document中，实际上将type作为一个document的field来存储，即_type，es通过_type来进行type的过滤和筛选；
一个index中的多个type，实际上是放在一起存储的，因此一个index下，不能有多个type重名，而类型或者其他设置不同的，因为那样是无法处理的；
最佳实践，将类似结构的type放在一个index下，这些type应该有多个field是相同的；
假如说，你将两个type的field完全不同，放在一个index下，那么就每条数据都至少有一半的field在底层的lucene中是空值，会有严重的性能问题；
//底层存储，一个index下所有的field都会存储，对于不同type下的字段若不存在，则置为空；
{
"_type": "elactronic_goods",
"name": "geli kongtiao",
"price": 1999.0,
"service_period": "one year",
"eat_period": ""
}
{
"_type": "fresh_goods",
"name": "aozhou dalongxia",
"price": 199.0,
"service_period": "",
"eat_period": "one week"
}
4. 定制dynamic策略和dynamic mapping策略
定制dynamic策略：
true：遇到陌生字段，就进行dynamic mapping；
false：遇到陌生字段，就忽略；
strict：遇到陌生字段，就报错；
dynamic mapping策略：
1）date_detection
默认会按照一定格式识别date，比如yyyy-MM-dd。但是如果某个field先过来一个2017-01-01的值，就会被自动dynamic mapping成date，后面如果再来一个"hello world"之类的值，就会报错。可以手动关闭某个type的date_detection，如果有需要，自己手动指定某个field为date类型。
PUT /my_index/_mapping/my_type
{
"date_detection": false
}
2）定制自己的dynamic mapping template（type level）
PUT /my_index
{
"mappings": {
"my_type": {
"dynamic_templates": [
{ "en": {
"match": "*_en",
"match_mapping_type": "string",
"mapping": {
"type": "string",
"analyzer": "english"
}
}}
]
}}}
PUT /my_index/my_type/1
{
"title": "this is my first article"
}
PUT /my_index/my_type/2
{
"title_en": "this is my first article"
}
title没有匹配到任何的dynamic模板，默认就是standard分词器，不会过滤停用词，is会进入倒排索引，用is来搜索是可以搜索到的
title_en匹配到了dynamic模板，就是english分词器，会过滤停用词，is这种停用词就会被过滤掉，用is来搜索就搜索不到了
3）定制自己的default mapping template（index level）
PUT /my_index
{
"mappings": {
"_default_": {
"_all": { "enabled": false }
},
"blog": {
"_all": { "enabled": true }
}
}
}
5. 重建索引
一个field的设置是不能被修改的，如果要修改一个Field，那么应该重新按照新的mapping，建立一个index，然后将数据批量查询出来，重新用bulk api写入index中；批量查询的时候，建议采用scroll api，并且采用多线程并发的方式来reindex数据，每次scoll就查询指定日期的一段数据，交给一个线程即可；
1）一开始，依靠dynamic mapping，插入数据，但是些数据是2017-01-01这种日期格式的，所以title这种field被自动映射为了date类型，实际上它应该是string类型的；
2）当后期向索引中加入string类型的title值的时候，就会报错；如果此时想修改title的类型，是不可能的；
3）唯一的办法是进行reindex，也就是说，重新建立一个索引，将旧索引的数据查询出来，再导入新索引；
4）如果说旧索引的名字，是old_index，新索引的名字是new_index，终端java应用，已经在使用old_index在操作了，难道还要去停止java应用，修改使用的index为new_index，才重新启动java应用吗？这个过程中，就会导致java应用停机，可用性降低；所以说，给java应用一个别名，这个别名是指向旧索引的，java应用先用着，java应用先用goods_index alias来操作，此时实际指向的是旧的my_index； PUT /my_index/_alias/goods_index
5）新建一个index，调整其title的类型为string；
6）使用scroll api将数据批量查询出来；采用bulk api将scoll查出来的一批数据，批量写入新索引；
POST /_bulk
{ "index": { "_index": "my_index_new", "_type": "my_type", "_id": "2" }}
{ "title": "2017-01-02" }
7）反复循环6，查询一批又一批的数据出来，采取bulk api将每一批数据批量写入新索引
8）将goods_index alias切换到my_index_new上去，java应用会直接通过index别名使用新的索引中的数据，java应用程序不需要停机，零提交，高可用；
POST /_aliases
{
"actions": [
{ "remove": { "index": "my_index", "alias": "goods_index" }},
{ "add": { "index": "my_index_new", "alias": "goods_index" }}
]
}
9）直接通过goods_index别名来查询，GET /goods_index/my_type/_search
5.2 基于alias对client透明切换index
PUT /my_index_v1/_alias/my_index
client对my_index进行操作
reindex操作，完成之后，切换v1到v2
POST /_aliases
{
"actions": [
{ "remove": { "index": "my_index_v1", "alias": "my_index" }},
{ "add": { "index": "my_index_v2", "alias": "my_index" }}
]
}
6. 倒排索引不可变的好处
（1）不需要锁，提升并发能力，避免锁的问题；
（2）数据不变，一直保存在os cache中，只要cache内存足够；
（3）filter cache一直驻留在内存，因为数据不变；
（4）可以压缩，节省cpu和io开销；
倒排索引不可变的坏处：每次都要重新构建整个索引；
7. document写入的内核级原理
（1）数据写入buffer缓冲和translog日志文件
（2）每隔一秒钟，buffer中的数据被写入新的segment file，并进入os cache，此时segment被打开并供search使用，不立即执行commit；--实现近实时；
数据写入os cache，并被打开供搜索的过程，叫做refresh，默认是每隔1秒refresh一次。也就是说，每隔一秒就会将buffer中的数据写入一个新的index segment file，先写入os cache中。所以，es是近实时的，数据写入到可以被搜索，默认是1秒。
（3）buffer被清空
（4）重复1~3，新的segment不断添加，buffer不断被清空，而translog中的数据不断累加
（5）当translog长度达到一定程度的时候，commit操作发生
（5-1）buffer中的所有数据写入一个新的segment，并写入os cache，打开供使用
（5-2）buffer被清空
（5-3）一个commit ponit被写入磁盘，标明了所有的index segment；会有一个.del文件，标记了哪些segment中的哪些document被标记为deleted了；
（5-4）filesystem cache中的所有index segment file缓存数据，被fsync强行刷到磁盘上
（5-5）现有的translog被清空，创建一个新的translog
//调整刷新的频率
PUT /my_index
{
"settings": {
"refresh_interval": "30s"
}
}
默认会在后台执行segment merge操作，在merge的时候，被标记为deleted的document也会被彻底物理删除；
每次merge操作的执行流程：
（1）选择一些有相似大小的segment，merge成一个大的segment；
（2）将新的segment flush到磁盘上去；
（3）写一个新的commit point，包括了新的segment，并且排除旧的那些segment；
（4）将新的segment打开供搜索；
（5）将旧的segment删除；
POST /my_index/_optimize?max_num_segments=1，尽量不要手动执行，让它自动默认执行；