ElasticSearch類型和索引性能

Question

我想了解將多種類型的文檔索引到單個索引的性能影響，其中每種類型的項目數量不平衡（一種類型有數百萬個，其中另一種類型只有數千個文件）。我在我的一些索引中發現了一些問題，並排除了類型是否在單個索引內分別索引（或不是）會對我有所幫助。我能否假設類型是按照關係數據庫的各行分別索引的，而每個表格是有效分離的？

如果上面的答案是否定的，而且這些類型實際上都集中在一起，那麼我將闡述我正在做的其他嘗試以獲得更詳細的輸入。

本示例的用例是爲Twitter用戶捕獲推文（爲了清楚起見，將其稱爲所有者）。我有多租戶環境，每個嘰嘰喳喳擁有者一個索引。這就是說，着眼於一個單一的所有者：

• 我捕捉來自各個時間表鳴叫（提到，直接的信息，我的微博，並全面「家」的時間表）成一個單一的指標，與具有各自的時間表類型ElasticSearch中的不同映射
• 每條推文都是指父類型，即使用父映射創作推文（可能是也可能不是所有者）的用戶。對於所有時間線類型，只有一個「用戶」類型
• 我在單個查詢中只搜索一個所有者，因此我不必關心自己搜索多個索引
• 家庭時間表可能會捕捉數以百萬計的推文，其中所有者自己的推文可能會導致數百或數千個用戶文檔定期更新，其Twitter信息時間線之外的信息會定期更新，因此我希望避免（如果可能的話）保持多個索引同一用戶對象的多個副本同步

我注意到很多s即使排除了包含數百萬文檔索引的「家庭時間線」類型，只留下幾千條條目的類型，對數百萬個文檔的索引查詢響應也較低。由於推文和用戶之間的父子關係，我不想將這些類型拆分爲單獨的索引（除非必須）。

有沒有一種方法可以理解，如果問題是與特定索引中的文檔總數，與'has_child'過濾查詢的操作有關，還有其他一些糟糕的查詢或設計方面的問題或某事其他？

任何輸入，將不勝感激。

編輯

澄清鳴叫存儲每時間表的聲明。這意味着爲home_timeline，my_tweets_timeline，mentions_timeline，direct_messages_timeline等定義了ElasticSearch類型，這與您在標準twitter.com UI中看到的內容相對應。所以在推文集之間有一個自然分裂，儘管也有一些重疊。

我已經回去檢查has_child查詢，這是一個明確的紅鯡魚在這一點上。即使查詢僅有幾千行的類型（my_tweets_timeline），對較大索引的基本查詢也會非常慢。

Answer 1

我可以假設類型是沿着關係數據庫的行分別編制索引，其中每個表是有效地分開的？

不，根據您的猜測，類型都集中在一個索引中。

有沒有一種方法可以理解問題是否與特定索引中的文檔總數有關，如何處理'has_child'過濾查詢的操作，某些其他不良設計的查詢或方面，或者是其他東西？

索引中的文檔總數顯然是一個因素。例如，has_child查詢是否特別慢是另一個問題 - 嘗試將has_child查詢的性能與例如term查詢的性能進行比較。該has_child documentation下提供「內存使用事項」一個線索：

當前實現，所有_id值，以支持快速查找，所以一定要確保有足夠的內存爲它加載到內存（堆）。

這意味着任何has_child查詢需要大量的內存，其中有數百萬個潛在子項。確保有足夠的內存可用於此類操作，或考慮重新設計以消除對has_child的需求。