彈性搜索，多個索引與一個索引和不同數據集的類型？

Question

我有一個使用MVC模式開發的應用程序，我想現在索引它的多個模型，這意味着每個模型都有不同的數據結構。

• 使用多重索引，每個模型一個或每個模型的同一索引中有一個類型更好嗎？這兩種方式還需要我認爲不同的搜索查詢。我剛開始這個。

• 如果數據集很小或很大，兩個概念之間在性能上會有差異嗎？

如果有人能爲我推薦一些好的樣本數據，我會自己測試第二個問題。

Answer 1

這兩種方法都有不同的含義。

假設您使用Elasticsearch的默認設置，每個模型有1個索引會顯着增加碎片的數量，因爲1個索引將使用5個碎片，5個數據模型將使用25個碎片;而1個索引中有5個對象類型仍然使用5個碎片。

啓示具有每個數據模式作爲索引：

• 高效和快速的索引內進行搜索，如因爲其被分配到不同的索引的數據量應該在每個碎片小。
• 從2個或更多索引中搜索數據模型的組合會產生開銷，因爲查詢必須發送到索引中更多的分片，編譯併發回給用戶。
• 如果數據集較小，則不推薦使用，因爲每創建一個額外的分片並且性能增益很小，您將產生更多存儲空間。
• 如果您的數據集很大並且您的查詢需要很長時間才能處理，建議您使用它，因爲專用分片存儲您的特定數據，並且Elasticsearch將更容易處理。

啓示具有的每個數據模型作爲索引內的對象類型：

• 更多的數據將被存儲的索引的5個碎片內，這意味着有較小的開銷問題，當您查詢跨不同的數據模型，但你的碎片大小將會更大。
• 由於有更多的文檔需要過濾，因此分片內的更多數據將花費更長的時間用於Elasticsearch搜索。
• 如果您知道您要經歷1 TB的數據，並且您未在Elasticsearch映射中的不同索引或多個分片中分發數據，則不推薦使用。
• 建議用於小數據集，因爲您不會浪費存儲空間以獲得極少的性能增益，因爲每個碎片佔用了硬件中的空間。

如果你問什麼是太多的數據與小數據？通常，這取決於處理器速度和硬件RAM，您在映射Elasticsearch中的每個變量中存儲的數據量以及查詢要求;在查詢中使用許多方面會顯着減慢響應時間。沒有直接的答案，你將不得不根據你的需求進行基準測試。

Answer 2

喬納森的回答很好。我只想添加其他幾點要考慮的：

• 可以爲您選擇的每個解決方案自定義分片數量。你可能有15塊主碎片一個索引，或將其分割至3個索引5個碎片 - 性能的角度不會改變（假設數據被相等地分佈）
• 考慮數據使用。 IE瀏覽器。如果你使用kibana可視化，它更容易包含/排除特定指數（ES），但種在儀表板中被過濾
• 數據保留：應用程序日誌/度量數據，使用不同的指標，如果你需要不同的保留期

Answer 3

兩個以上的答案是偉大的！

我在索引中添加了幾個類型的示例。 假設您正在開發一個應用程序來搜索庫中的書籍。 有問到庫所有者幾個問題，

問題：

1. 多少書，你打算存儲？

2. 你要什麼樣的書在圖書館保存？

3. 你將如何尋找書籍？

答案：

1. 我打算存儲50K的 - 到爲70K書（大約）

2. 我將有十五K -20 k科技公司相關的書籍（計算機科學，機械工程，化學工程等），歷史書籍15部，醫學書籍10部。以10K語言相關的書籍（英語，西班牙語等）

3. 通過作者搜索第一名稱，作者姓名，出版年份，出版商的名稱。 （此爲您提供有關你應該在索引存儲什麼信息的想法）

從上面的答案，我們可以說，在我們的索引架構應該看起來有點像這樣。

//這是不準確的映射，只是爲了例如

  "yearOfPublish":{ 
       "type": "integer" 
      }, 
      "author":{ 
       "type": "object", 
       "properties": { 
        "firstName":{ 
         "type": "string" 
        }, 
        "lastName":{ 
         "type": "string" 
        } 
       } 
      }, 
      "publisherName":{ 
       "type": "string" 
      } 
     } 

爲了實現上述我們可以創建一個索引叫做書，可以有多種類型。

指數：圖書

類型：科學，藝術

（或者你可以創建多種類型，如科技，醫藥科學，歷史，語言，如果你有很多書）

重要這裏要注意的是模式是相似的，但數據並不相同。另一個重要的是您正在存儲的全部數據。

希望以上內容有助於何時查找索引中的不同類型，如果您有不同的模式，則應考慮使用不同的索引。小數據索引小。 :-)

Answer 4

雖然喬納森的回答是當時正確的大指數大數據的世界已經改變，現在看來，背後ElasticSearch的人有一個長期計劃放棄對多種類型的支持：

Where we want to get to: We want to remove the concept of types from Elasticsearch, while still supporting parent/child.

因此，對於新項目，僅使用每個索引的單一類型將使ElasticSearch 6.x的最終升級變得更容易。