我對於Elasticsearch和多態數據似乎是一個基本問題感到困惑。我希望能夠通過一個Elasticsearch查詢找到多種類型的結果（例如用戶，視頻和播放列表）。它必須只是一個查詢，因爲Elasticsearch可以做所有的評分，我不需要做任何魔術來組合多個不同類型的查詢結果。使用Elasticsearch通過多態數據搜索
我知道Elasticsearch使用平面文檔結構，使我遇到以下問題。如果我對多態數據進行索引，那麼我將不得不爲每個獨特的屬性指定一個「缺失」值，這是我關心對多態數據的子類型進行評分的原因。
我找過其他處理這個問題的例子，找不到任何。在文檔中似乎也沒有任何內容。我忽略了一些顯而易見的東西，或者Elasticsearch只是沒有設計用來做這樣的事情？
親切的問候，
STEFFAN
那Elasticsearch本身沒有問題，它的問題（或限制）底層的Lucene索引的。所以，任何基於lucene的數據庫/引擎都會有相同的問題（如果不是更糟糕的話），ES爲你做了很多工作）。 ES可能會緩解進一步發佈中的痛苦，但不會顯着。而國際海事組織幾乎沒有任何hi-perf搜索引擎能夠承載真正的多態數據。
答案取決於你的數據結構，這是肯定的。基本上，你有兩種選擇：
把所有的數據放在單一的索引，並按類型拆分。而且你已經知道開銷 - 透明指數對於稀疏數據的效果不佳。你的數據越多，你的問題就越少。無論如何，ES會爲「缺失」值做所有潛在的工作，你只需要處理存儲稀疏數據的內存/磁盤開銷。
如果您的數據是用父子關係（即視頻 - >播放列表）組織的，那麼您肯定需要單一索引來處理此類數據。只有這種方法會導致你失敗。
將您的數據分成多個索引。這樣，當你從多個分片彙總數據時，你的lucene索引的磁盤開銷就會稍高一些，CPU使用率可能會更高（所以你應該分別調整你的分片）。
由於ES支持multi-index查詢，您仍然可以在單個請求中查詢ES的所有文檔。
因此，這看起來像純粹的數據結構問題。我建議簡單地啓動小羣集來測量預期數據的內存/磁盤/ CPU使用情況。更多關於「index vs shard」的詳細信息 - 偉大的article作者Adrien。如果ES似乎並不足以滿足您的需求，我建議您 仍然考慮在應用程序端合併數據。 ES可以很好地處理多個光照請求（而不是較少的重複請求），並且隨着ES的結果已經排序，您需要合併已排序輸入的已排序流。不是那麼神奇，tbh。
在應用程序方面結合結果的問題是評分在查詢之間沒有意義，因此儘管流被排序，但不同流之間相互關聯的方式仍然需要您定義，這是我的意思是魔法。 否則，非常感謝您的回答！我並不十分關心開銷，但我確實記得閱讀過有關Lucene和稀疏數據的問題。多態數據的性質使得任何搜索引擎都很難處理，儘管我期望在某處會有更多的例子。 – steffansluis
我想說，如果評分是現在唯一的問題 - 嘗試多類型單索引查詢。如果數據中的相同字段的類型/含義相同（希望如此，如果您需要得分那麼:)），請試試看。 如果它會很慢/不適用於你，你可以嘗試使用MongoDB（true polymorhic，hehe），但只使用wiredtiger存儲引擎（基本上是v3 +）。遺憾的是，之前版本3對於任何hi-perf聚合/分析都不是這種情況。 – Slam