elasticsearch2

三种元数据

1、_index元数据

（1）代表一个document存放在哪个index中
（2）类似的数据放在一个索引，非类似的数据放不同索引：product index（包含了所有的商品），sales index（包含了所有的商品销售数据），inventory index（包含了所有库存相关的数据）。如果你把比如product，sales，human resource（employee），全都放在一个大的index里面，比如说company index，不合适的。
（3）index中包含了很多类似的document：类似是什么意思，其实指的就是说，这些document的fields很大一部分是相同的，你说你放了3个document，每个document的fields都完全不一样，这就不是类似了，就不太适合放到一个index里面去了。
（4）索引名称必须是小写的，不能用下划线开头，不能包含逗号：product，website，blog

2、_type元数据

（1）代表document属于index中的哪个类别（type）
（2）一个索引通常会划分为多个type，逻辑上对index中有些许不同的几类数据进行分类：因为一批相同的数据，可能有很多相同的fields，但是还是可能会有一些轻微的不同，可能会有少数fields是不一样的，举个例子，就比如说，商品，可能划分为电子商品，生鲜商品，日化商品，等等。
（3）type名称可以是大写或者小写，但是同时不能用下划线开头，不能包含逗号

3、_id元数据

（1）代表document的唯一标识，与index和type一起，可以唯一标识和定位一个document
（2）我们可以手动指定document的id（put /index/type/id），也可以不指定，由es自动为我们创建一个id。

• 在自动生成document_id的时候使用GUID算法保证在不同的节点同时进行document的创建的时候可以保证生成不同的document_id
• _source的元数据在get的时候会将创建的字符串原封不动的返回回来。
• document的全量替换是将原有的数据标记为delete类型，然后在当前节点空间不够的时候将标记为document的节点进行物理的删除来节省空间。es采用的是懒删除的模式进行删除。
• elasticsearch中的并发冲突问题：两种情况：乐观锁与悲观锁  （1）悲观锁：在读取数据的时候就进行加锁，然后其他线程在进行锁的读取的时候是获取不到的。锁有行级锁和表级锁 读锁和写锁（2）乐观锁：通过版本号来判断线程是否数据是否进行改变。多个线程可以并发操作。
• es内部是怎样通过乐观锁来进行版本的控制的：es的内部不同的修改之间是乱序的，后修改的可能先到；因此在修改的过程中是通过版本号来进行并发控制的。根本版本好版本好大的就会覆盖先前小的版本好来保证新的数据覆盖旧的数据。
• es内部在修改doc的数据的时候就是基于乐观锁版本号来进行并发的控制的。通过版本好来进行判断是否数据进行过更改。
• version_type=external是表明你自定义的版本好比es中该doc中提供的版本号大的时候才能进行更改，否则不能进行更改。
• partial_update:举例如下：POST /text_index/text_type/5/_update
  {
    "doc": {"age":"12"}
  }   该原理和全量替换的原理几乎是一样的。先全量查询，然后将请求中doc的数据插入到json中，将原有的doc标为doc。与全量查询相比的优点 1.所有的查询修改和写回操作都会发生在es查询的一个shard中避免的所有网络数据传输的开销，大大提升了性能。2.减少修改过程中的时间间隔，减少并发控制所带来的问题。
• es内部基于groovy的内置脚本操作 
• partial update是利用乐观锁完成数据的更改的。
• 运用mget可以一次请求多个请求，这样可以一次性取多个数据。
• bulk是批量执行的    语法要求：每个json串不能换行，只能放一行，同时两个json串之间必须换行。如下所示
• POST /_bulk
  {"delete":{ "_index":"test_index", "_type":"text_type", "_id":11}}，其中任意一个操作失败是不会影响结果的。
• bulk会被加载到内存中，这样会引起性能的下降，最好在5M和15M之间。