一、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有效壓縮文檔的能力。