Elasticsearch 關鍵字：索引，類型，字段，索引狀態，mapping，文檔

1. 索引（_index）
索引：說的就是數據庫的名字。
我這個說法是對應到咱經常使用的數據庫。

結合es的插件 head 來看。

可以看到，我這個地方，就有這么幾個索引，索引就是數據庫，后面是這個數據庫占用多大空間，以及里面有多少條docs，也就是里面有多少條數據。

（下面這些話算是我從其他地方復制官話吧。可以參考，但是，看完的效果不敢保證。）

索引（index）是Elasticsearch對邏輯數據的邏輯存儲，所以它可以分為更小的部分。你可以把索引看成關系型數據庫的表（濕胸我反對，你家的數據庫一張表里面可以存不同的數據嗎？存個學生，存個學校？存個dog？咱關系數據庫，難道不是分三個表，一個表叫學生，一個叫學校，一個叫狗。嗎？）。然而，索引的結構是為快速有效的全文索引准備的，特別是它不存儲原始值。Elasticsearch可以把索引存放在一台機器或者分散在多台服務器上，每個索引有一或多個分片（shard），每個分片可以有多個副本（replica）。

 

2. 類型（_type）
還是結合head插件，來說這個關鍵字。

從圖上，可以看到：我選擇了一個索引，head插件，也是這么對索引翻譯的，選擇了索引之后，我在下面的類型里面又選擇啦類型。

這個效果就是，右邊展示的數據，現在展示的是我選擇的那個索引里面的叫做calendars類型的數據，

相當於選擇了某個數據庫（ezsonar_config：可以算是數據庫名稱）里面的某個表（calendars：姑且可以叫表名稱）

所以，這個類型就可以理解為我們常用的數據庫的一張表

再多說一句，這個地方，可以看到很多的類型，這些類型是上面的所有的索引里面的所有字段的總和，不是說，你選了某個索引(數據庫)之后，下面的類型(表)就會對應展示成某個數據庫里面的表，他說全量展示的。所以，下面在展示字段的時候，也是展示的是所有的索引(數據庫)的所有的類型(表)的所有的屬性。

（下面這些話算是我從其他地方復制官話吧。可以參考，但是，看完的效果不敢保證。）

在Elasticsearch中，一個索引對象可以存儲很多不同用途的對象。例如，一個博客應用程序可以保存文章和評論。文檔類型讓我們輕易地區分單個索引中的不同對象。每個文檔可以有不同的結構，但在實際部署中，將文件按類型區分對數據操作有很大幫助。當然，需要記住一個限制，不同的文檔類型不能為相同的屬性設置不同的類型。例如，在同一索引中的所有文檔類型中，一個叫title的字段必須具有相同的類型。

上面變紅的這句話，我翻譯一下，就是說你在一個Student.class類里面有個屬性 age 是 int，表示年齡用，，，你在另外一個Country.class 里面有個屬性，也叫 age，string 類型，表示世紀。。。，那么，es就炸啦。我下面也將要說到，這個field，字段是一起展示的，也就是說es他是一起處理這些字段的，所以，你同一個字段，這里說的就是叫age的屬性，一個是int類型，一個是字符串類型，他就會炸。。。。

我在使用，spring-data-elasticsearch的時候，還真的有這個情況，就是某個bean model里面他已經取了個屬性名稱是某個類型啦，我不知道，又在我自己新建的bean model里面也取了一樣的名稱的屬性，但是類型不一樣，，，，所以，我在保存數據到es的時候，崩 的炸啦。。。換個名稱就沒事啦。。。

我覺得，這是es的設計bug。。。

我自己設計model bean的時候，我怎么知道我這個屬性的名稱是否在其他地方被使用啦呢。。。。。。。

 

3. 字段（field）

還是結合head插件

在索引完了之后，是類型，類型之后，是字段

這個字段，此處所展示的是包含了所有索引的所有類型的所有字段。

這個字段就是說，你保存的某個表里面的屬性的的名稱，比如，你存個學生類型，會有個Student類型，這個學生對象是不是可以有name，age，class等屬性。這些屬性在es里面就叫做。字段。

（我這好像沒有復制官方的話。）

4. 文檔（document）
文檔：也就是指es里面的單條數據。看圖。

看到圖里面，選擇了一個索引(數據庫)，后面顯示31個文檔，就是簡單的說明這個數據庫里面一共有31條數據。是不是一個類型(表)里面的，就不得而知。

（下面這些話算是我從其他地方復制官話吧。可以參考，但是，看完的效果不敢保證。）

存儲在Elasticsearch中的主要實體叫文檔（document）。用關系型數據庫來類比的話，一個文檔相當於數據庫表中的一行記錄。
文檔由多個字段組成，每個字段可能多次出現在一個文檔里，這樣的字段叫多值字段（multivalued）。每個字段有類型，如文本、數值、日期等。字段類型也可以是復雜類型，一個字段包含其他子文檔或者數組。字段類型在Elasticsearch中很重要，因為它給出了各種操作（如分析或排序）如何被執行的信息。幸好，這可以自動確定，然而，我們仍然建議使用映射。與關系型數據庫不同，文檔不需要有固定的結構，每個文檔可以有不同的字段，此外，在程序開發期間，不必確定有哪些字段。當然，可以用模式強行規定文檔結構。從客戶端的角度看，文檔是一個JSON對象。每個文檔存儲在一個索引中並有一個Elasticsearch自動生成的唯一標識符和文檔類型。文檔需要有對應文檔類型的唯一標識符，這意味着在一個索引中，兩個不同類型的文檔可以有相同的唯一標識符。
5. 映射(mapping) 
這個是重點，就像你在使用數據庫的時候，一樣樣滴。

還是看head插件的截圖。

在head插件，可以如上圖，查看當前索引(數據庫)的狀態和信息。

索引狀態和索引信息，這2個詞，是head插件翻譯的。咱就這么用吧。

索引狀態：就是簡單的描述了下這個索引(數據庫)的信息。可以大概看看，如下圖。

索引信息：這個是關鍵，這個說的是這個索引(數據庫)里面的類型(表)的結構的設計。就像你在設計表結構一樣，某個類型(表)的哪個字段(屬性)是String，還是int還是boolean啥的，都在這地放看的。

為了，實際對比，我這放一個Java里面的model bean 以及生成的mapping。因為字段也就是屬性太多，我就刪除了部分。

 

1.  
   @Document(indexName = "ezsonar_config", type = "calendars", shards = 3, replicas = 0)
2.  
   public class Calendar extends Type {
3.  
   @Id
4.  
   private String id;
5.  
   /**
6.  
   * 名稱
7.  
   * 添加 @Field(type = FieldType.keyword)
8.  
   * 注解作用：不分詞，查ES的時候，就是精確查找。
9.  
   */
10.  
    @Field(type = FieldType.keyword)
11.  
    private String name;
12.  
    private String content;
13.  
    private int streamType;
14.  
    private String jsonContent;
15.  
    }

上面是bean，下面是在索引信息里面的對應數據

 

 

1.  
   {
2.  
   "calendars": {
3.  
   "properties": {
4.  
   "hid": {
5.  
   "type": "text",
6.  
   "fields": {
7.  
   "keyword": {
8.  
   "ignore_above": 256,
9.  
   "type": "keyword"
10.  
    }
11.  
    }
12.  
    },
13.  
    "content": {
14.  
    "type": "text",
15.  
    "fields": {
16.  
    "keyword": {
17.  
    "ignore_above": 256,
18.  
    "type": "keyword"
19.  
    }
20.  
    }
21.  
    },
22.  
    "streamType": {
23.  
    "type": "text",
24.  
    "fields": {
25.  
    "keyword": {
26.  
    "ignore_above": 256,
27.  
    "type": "keyword"
28.  
    }
29.  
    }
30.  
    },
31.  
    "name": {
32.  
    "type": "keyword"
33.  
    },
34.  
    "id": {
35.  
    "type": "text",
36.  
    "fields": {
37.  
    "keyword": {
38.  
    "ignore_above": 256,
39.  
    "type": "keyword"
40.  
    }
41.  
    }
42.  
    },
43.  
    "jsonContent": {
44.  
    "type": "text",
45.  
    "fields": {
46.  
    "keyword": {
47.  
    "ignore_above": 256,
48.  
    "type": "keyword"
49.  
    }
50.  
    }
51.  
    }
52.  
    }
53.  
    }
54.  
    }

一個json對象吧

 

（下面這些話算是我從其他地方復制官話吧。可以參考，但是，看完的效果不敢保證。）

在有關全文搜索基礎知識部分，我們提到了分析的過程：為建索引和搜索准備輸入文本。文檔中的每個字段都必須根據不同類型做相應的分析。舉例來說，對數值字段和從網頁抓取的文本字段有不同的分析，比如前者的數字不應該按字母順序排序，后者的第一步是忽略HTML標簽，因為它們是無用的信息噪音。Elasticsearch在映射中存儲有關字段的信息。每一個文檔類型都有自己的映射，即使我們沒有明確定義。

Elasticsearch 主要概念
現在，我們已經知道Elasticsearch把數據存儲在一個或多個索引上，每個索引包含各種類型的文檔。我們也知道了每個文檔有很多字段，映射定義了Elasticsearch如何對待這些字段。但還有更多，從一開始，Elasticsearch就被設計為能處理數以億計的文檔和每秒數以百計的搜索請求的分布式解決方案。這歸功於幾個重要的概念，我們現在將更詳細地描述。
1. 節點和集群
Elasticsearch可以作為一個獨立的單個搜索服務器。不過，為了能夠處理大型數據集，實現容錯和高可用性，Elasticsearch可以運行在許多互相合作的服務器上。這些服務器稱為集群（cluster），形成集群的每個服務器稱為節點（node）。
2. 分片
當有大量的文檔時，由於內存的限制、硬盤能力、處理能力不足、無法足夠快地響應客戶端請求等，一個節點可能不夠。在這種情況下，數據可以分為較小的稱為分片（shard）的部分（其中每個分片都是一個獨立的Apache Lucene索引）。每個分片可以放在不同的服務器上，因此，數據可以在集群的節點中傳播。當你查詢的索引分布在多個分片上時，Elasticsearch會把查詢發送給每個相關的分片，並將結果合並在一起，而應用程序並不知道分片的存在。此外，多個分片可以加快索引。
3. 副本
為了提高查詢吞吐量或實現高可用性，可以使用分片副本。副本（replica）只是一個分片的精確復制，每個分片可以有零個或多個副本。換句話說，Elasticsearch可以有許多相同的分片，其中之一被自動選擇去更改索引操作。這種特殊的分片稱為主分片（primary shard），其余稱為副本分片（replica shard）。在主分片丟失時，例如該分片數據所在服務器不可用，集群將副本提升為新的主分片。
4. 時光之門
Elasticsearch處理許多節點。集群的狀態由時光之門控制。默認情況下，每個節點都在本地存儲這些信息，並且在節點中同步。

面向文檔
應用中的對象很少只是簡單的鍵值列表，更多時候它擁有復雜的數據結構，比如包含日期、地理位置、另一個對象或者數組。
總有一天你會想到把這些對象存儲到數據庫中。將這些數據保存到由行和列組成的關系數據庫中，就好像是把一個豐富，信息表現力強的對象拆散了放入一個非常大的表格中：你不得不拆散對象以適應表模式（通常一列表示一個字段），然后又不得不在查詢的時候重建它們。
Elasticsearch是面向文檔(document oriented)的，這意味着它可以存儲整個對象或文檔(document)。然而它不僅僅是存儲，還會索引(index)每個文檔的內容使之可以被搜索。在Elasticsearch中，你可以對文檔（而非成行成列的數據）進行索引、搜索、排序、過濾。這種理解數據的方式與以往完全不同，這也是Elasticsearch能夠執行復雜的全文搜索的原因之一。