elasticsearch底层引擎替换之索引创建+文档添加

最近在改elasticsearch的源码，真的蛋疼，现在先记录一下遇到的问题

首先，我们在做的是替换掉elasticsearch的底层引擎，也就是把lucene替换成我们自己的引擎。这个工作起步不久，所有的一切都是自己一步步来的，除了底层架构，上层的调用也有好多不懂的地方，现在，就我替换的索引建立这一块做个简单的记录。

工作中使用的elasticsearch版本是5.4.2，网上资料比较少。

elasticsearch调用lucene建立索引的入口在elasticsearch/index/engine/internalEngine里，这个internalEngine是分别为每个index的每个分片建立的，如果分片存在的话es初始化的时候，索引recovery的时候就会创建internalengine，否则是在获取到es建立index的命令时创建。关于这个东西不多说，看源码的话这个internalengine里功能有啥还是比较明了的。

今天搞了一天，主要是在对索引添加document的动作选择上，这个是由version这个东西决定的，version，uid，source等几个都是elasticsearch官方文档上讲的元数据，在elasticsearch选择对文档的操作是有很重要的作用。在internalengine里，有个versionmap，会对各个文档的version做个缓存，不过这个map好像很小。在每次添加文档时，internalengine会去查找要添加的文档（uid来指定一个文档）的version，如果version不存在，则代表这个文档还没添加，故调用lucene的adddocument，否则调用updatedocument。注意，它检测version是否存在的时候，首先会检查versionmap，如果versionmap中不存在则会去lucene中检索uid的version（获得version的函数在internalengine的resolveDocVersion里，去lucene检索的函数名叫loadCurrentVersionFromIndex即elasticsearch的这些元数据会随着文档一起存在lucene中，持久化到硬盘上），如果可以在lucene中检测到version一样会认为文档已经存在。我们自己的引擎还暂时没有多个field的功能，所以我做测试的时候一直没法正确的选择对文档的操作。经过一天的检查，终于找到原因。明天我会把除了自定义的json中的field额外还会存进lucene的元数据给贴上来，同时为了自己的引擎测试，先暂用lucene来存储元数据，用户数据交给我们自己的引擎来存储。

元数据有如下内容: _source,_uid,_type,_type,_version,_all(记录的是json自定义的field的内容),_field_names(有多个，会把前面的所有域，包括元数据的域的名字全部记录一遍)，目前把元数据存在lucene中没有发现什么bug，