elasticsearch 6变更记录

elasticsearch 6变更内容记录

原来没怎么接触过es，找了个教程，本来是按着教程上敲的练练手的，然后就我靠了，又回到当初碰Django时候的懵逼状态，新版本改好多。。

No handler for type [string] declared on field

本来练手练得好好的：

PUT http://192.168.0.91:9200/index_test

{
	"settings": {
		"number_of_shards": 3,
		"number_of_replicas": 2
	},
	"mappings": {
		"Testlog": {
			"properties": {
				"logType": {
					"type": "string",
					"index": "not_analyzed"
				}
			}
		}
	}
}

然后就是悲剧：

"error": {
       "root_cause": [
           {
               "type": "mapper_parsing_exception",
               "reason": "No handler for type [string] declared on field [logType]"
           }
       ],

研究半天，JSON没啥错啊，教程里就是这么干的啊，回忆起Django的版本悲剧，搜了下版本变更，唉~`ElasticSearch 5.x开始就取消了string类型，取代的事text和keyward，text用于全文搜索的, 而keyword用于关键词搜索`

找了段网上的解释：
这个变动的根本原因是string类型会给我们带来很多困惑: 因为ElasticSearch对字符串拥有两种完全不同的搜索方式. 你可以按照整个文本进行匹配, 即关键词搜索(keyword search), 也可以按单个字符匹配, 即全文搜索(full-text search). 对ElasticSearch稍有了解的人都知道, 前者的字符串被称为not-analyzed字符, 而后者被称作analyzed字符串.

事实上, 同一种类型用于应对两种不同的使用场景是会让人崩溃的, 因为有些选项只对其一的场景设置有效.例如position_increment_gap对not-analyzed字符就不会起作用, 而像ignore_above对于analyzed字符串就很难区分它到底是对整个字符串的值有效还是对单独的每个分词有效(在这种场景, ignore_above确实只对整个字符串值有效, 而对单个分词的限制可以使用limit设置)，同样，index现在也只需要boolean的两种状态，所以可以修改为：

{
	"settings": {
		"number_of_shards": 3,
		"number_of_replicas": 2
	},
	"mappings": {
		"gaialog": {
			"properties": {
				"logType": {
					"type": "text",
					"index": "false"
				}
			}
		}
	}
}

as the final mapping would have more than 1 type

原因是6.x开始，取消了mapping type…
具体原因可以看官方的解释：removal of mapping type
需要的一些解释是：
首先，很多人会把es和关系型数据库进行类比；

index ——> 数据库（database）
type ——> 表（table）
document ——> 数据记录（data）
filed ——> 列（column）

其实这样理解是有问题的，在关系型数据库中，每个表的列都是相互独立的，即使是同样列名的列，也毫无关系；但是在像es这样的映射型数据库中，即使是在不同的type下的field，只要field名字一样，它们所指向的Lucene字段都是同一个，所以是有影响的。在ES中，之前有type的情况下，在不同的type下可以建同样名字的field，比如test，type1下的field是string类型，type2下的field是boolean类型，由于同一个名字的field对应的Lucene字段一样，所以在进行field删除时，系统就会出错，不知道具体应该删的是哪个field。
官方为了避免这样的情况，就直接开始了不要type~~~