一、ES的存储结构
1、索引
es 中存储数据的基本单位，比如说你现在要在 es 中存储一些订单数据，你就应该在 es 中创建一个索引 order_idx，所有的订单数据就都写到这个索引里面去。看了一些文章有的说索引可以理解为关系型数据库中的数据库，有的说相当于数据库中的表。我的理解是它相对于关系型数据库更为灵活，因为在7.0之后的版本，type被废除，它直接可以自定义，感觉就就是直接添加到属性中，而不是原来的在索引之后添加type，所以在添加数据时就可以更加灵活，所以我认为一个索引可以理解为一个数据库。
2、type
7.0之前的写法：
PUT twitter
{
"mappings": {
"user": {
"properties": {
"name": { "type": "text" },
"user_name": { "type": "keyword" },
"email": { "type": "keyword" }
}
},
"tweet": {
"properties": {
"content": { "type": "text" },
"user_name": { "type": "keyword" },
"tweeted_at": { "type": "date" }
}
}
}
}
PUT twitter/user/kimchy
{
"name": "Shay Banon",
"user_name": "kimchy",
"email": "shay@kimchy.com"
}
PUT twitter/tweet/1
{
"user_name": "kimchy",
"tweeted_at": "2017-10-24T09:00:00Z",
"content": "Types are going away"
}
GET twitter/tweet/_search
{
"query": {
"match": {
"user_name": "kimchy"
}
}
}
在程序中可以很清楚的看到构架，tweet和user都是type，可以理解为索引的下个级别，可以理解为一张表，put 索引/type/id 添加一条数据（document），数据中的字段就是filed。
7.0之后：
PUT twitter
{
"mappings": {
"_doc": {
"properties": {
"type": { "type": "keyword" }, (1)
"name": { "type": "text" },
"user_name": { "type": "keyword" },
"email": { "type": "keyword" },
"content": { "type": "text" },
"tweeted_at": { "type": "date" }
}
}
}
}
PUT twitter/_doc/user-kimchy
{
"type": "user", (1)
"name": "Shay Banon",
"user_name": "kimchy",
"email": "shay@kimchy.com"
}
PUT twitter/_doc/tweet-1
{
"type": "tweet", (1)
"user_name": "kimchy",
"tweeted_at": "2017-10-24T09:00:00Z",
"content": "Types are going away"
}
GET twitter/_search
{
"query": {
"bool": {
"must": {
"match": {
"user_name": "kimchy"
}
},
"filter": {
"match": {
"type": "tweet" (1)
}
}
}
}
}
从官方解释中能够看出，之前type没有了，取而代之的是_doc，我是这么理解的，之前可以建立很多type，相当于可以减很多表，数据可以添加。现在只有一张_doc表格，表格多了type属性，可以添加type属性的内容加以区分。
图片理解：
3、document
相当于一条数据。
4、filed
相当于一条数据中的一个字段的内容。
5、mapping
Mapping 来定义每个字段的类型。比如诗题、作者、朝代都是 Keyword 类型，诗内容是 Text 类型，而字数是 Integer 类型，最后就是把数据组织成 Json 格式存放进去了。keyword和text都是字符成类型，它们有什么区别呢？
这涉及到分词的问题，Keyword 类型是不会分词的，直接根据字符串内容建立反向索引，Text 类型在存入 Elasticsearch 的时候，会先分词，然后根据分词后的内容建立反向索引。
6、id
再添加数据时需要添加id。
a、可以自己添加id
b、不添加，系统会自动配置id
二、为什么要取消type呢？
最初，我们讨论了索引“类似于数据库”和type“相当于表”。严格来说，这是一个错误的类比，导致了错误的假设。在SQL数据库中，表是相互独立的。
一个表中的列与另一个表中具有相同名称的列没有关系。这与映射类型中的字段不同。在Elasticsearch索引中，不同映射类型中具有相同名称的字段在内部由相同的Lucene字段支持。换句话说，使用上面的示例，user类型中的user_name字段存储在与tweet类型中的user_name字段完全相同的字段中，而且两个user_name字段在这两种类型中必须具有相同的映射(定义)。例如，当您想要删除一个类型中的日期字段和同一个索引中的另一个类型中的布尔字段时，这可能会导致失败。
最重要的是，存储在同一索引中具有很少或没有共同字段的不同实体会导致数据稀疏，并影响Lucene有效压缩文档的能力。