elasticsearch常识：存储结构、优化

elasticsearch常识：

1、es存储结构

Relational DB -> Databases -> Tables -> Rows -> Columns //这个就是Mysql的结构,不多说,都懂
Elasticsearch -> Index-> Types -> Documents -> Fields //这个就是ES的结构
#ES的index代表Mysql中的数据库
#ES的types代表Mysql中的Tables
#ES的Document代表Mysql中的行
#ES的Fields代表Mysql中的列
#ES的mapping代表Mysql中的表结构，由于Elasticsearch底层使用了lucene的原因，不支持对mapping的修改，可使用索引重建的方式。而且不能更改类型，为什么不能修改一个字段的type？原因是一个字段的类型修改以后，那么该字段的所有数据都需要重新索引。Elasticsearch底层使用的是lucene库，字段类型修改以后索引和搜索要涉及分词方式等操作，不允许修改类型在我看来是符合lucene机制的。
Elasticsearch集群可以包含多个索引index数据库
每一个索引可以包含多个类型 types表，
每一个类型包含多个文档documents行
每个文档包含多个字段 Fields列

2、elasticsearch不支持跨索引查询

3、优化ES

不需要索引的字段，一定要明确定义出来，因为默认是自动建索引的
同样的道理，对于String类型的字段，不需要analysis的也需要明确定义出来，因为默认也是会analysis的
选择有规律的ID很重要，随机性太大的ID(比如java的UUID)不利于查询

可能有时候你会发现一个问题，用term或terms进行查询文本信息的时候竟然没有返回任何数据，例如：需要查询elasticsearch-dsl，Elasticseach，
elasticsearch client这类文本信息，结果都是查不到的，原因不在于term方法，而是因为es建立索引的方式，
es默认建立索引的时候会是analyzed，这个设置会对写入es的数据进行分词并全部转换成小写，这样做是为了方便进行全文搜索，
如elasticsearch-dsl存储的时候是elasticsearch和dsl分开的，但有时候我们需要进行精确查询，这个守候需要设置索引为not_analyzed，
此设置下不会进行分词处理，但显然不利于全文搜索，
查到有人的解决方法是，设置两个存储相同内容的field，一个设置analyzed，另一个设置not_analyzed，
一个用来精确查询，另一个用来全文搜索。但是也可以为每个字段设置两个index，一个是text类型，一个keyword类型。
另外如果对数据内容没有太大要求的时候，可以再写入es之前对数据进行处理，过滤掉“-“、空格等非单词字符，
如Elasticsearch-dsl client直接存储成Elasticsearchdslclient

在elasticsearch-dsl中没有找到设置not_analyzed的接口，原因是在elasticsearch-dsl只需要设置类型为keyword即可