假設我有以下“費用” MySQL 表：
| ID | 數量 | 小販 | 標簽 |
|---|---|---|---|
| 1 | 100 | 谷歌 | 富 |
| 2 | 450 | GitHub | 酒吧 |
| 3 | 22 | GitLab | 嘶嘶聲 |
| 4 | 75 | AWS | 嗡嗡聲 |
我正在構建一個 API，它應該根據部分“供應商”或“標簽”過濾器回傳費用，因此 vendor="Git" 應該回傳記錄 2&3，而 tag="zz" 應該回傳記錄 3&4。我正在考慮使用彈性搜索功能，但我不確定正確的方法..
我閱讀的大多數文章都建議將表記錄（使用 logstash 管道或其他方法）復制到彈性索引。
所以我的 API 甚至不查詢資料庫并直接從 ES 回傳一個檔案陣列？
這被認為是好的做法嗎？將整個表復制到彈性？表關系怎么樣...如果我想按嵌套表關系過濾怎么辦？...
uj5u.com熱心網友回復：
所以我的 API 甚至不查詢資料庫并直接從 ES 回傳一個檔案陣列？
是的，當您對 Elasticsearch 進行查詢時，您只能從 Elasticsearch 獲得結果。另一種方法是，只需從 Elasticsearch 獲取 id 并使用 id 從 MySQL 檢索檔案，但這可能會影響回應時間。
這被認為是好的做法嗎？將整個表復制到彈性？表關系怎么樣...如果我想按嵌套表關系過濾怎么辦？...
這不是關于好的實踐或壞的實踐，而是關于你想要實作什么型別的功能和用例，以及基于該技術堆疊可以使用和資料可以被復制。有很多公司使用 Elasticsearch 作為secondary資料源，他們復制資料只是因為用例最適合 Elasticsearh 或其他 NoSQL 資料庫。
Elasticsearch 是 NoSQL DB，它不維護資料之間的任何關系。因此，您需要在索引到 Elasticsearch 之前對資料進行非規范化處理。您可以閱讀這篇文章，了解更多關于非規范化以及為什么需要它的資訊。
ElasticSearch為父子關系提供Nested和Join資料型別，但兩者都有一些限制和性能影響。
以下是他們提到的join欄位型別：
連接欄位不應該像關系資料庫中的連接一樣使用。在 Elasticsearch 中，獲得良好性能的關鍵是將資料反規范化為檔案。每個連接欄位
has_child或has_parent查詢都會對您的查詢性能產生重大影響。它還可以觸發要構建的全域序數。
以下是他們提到的nested欄位型別：
當攝取具有大量任意鍵的鍵值對時，您可能會考慮將每個鍵值對建模為具有
key和value欄位的自己的嵌套檔案。相反，請考慮使用flattened資料型別，它將整個物件映射為單個欄位并允許對其內容進行簡單搜索。嵌套檔案和查詢通常很昂貴，因此在flattened此用例中使用資料型別是更好的選擇。
我閱讀的大多數文章都建議將表記錄（使用 logstash 管道或其他方法）復制到彈性索引。
是的，您可以使用logstash或任何語言客戶端（如java等python）將資料從 DB 同步到 Elasticsearch。您可以查看此SO 答案以獲取更多資訊。
您的搜索要求
如果您繼續使用 Elasticsearch，那么您可以使用N-Gram Tokenizer或Regex Query來滿足您的搜索要求。
轉載請註明出處，本文鏈接：https://www.uj5u.com/qianduan/478690.html
上一篇：如何根據屬性的總和組織物件陣列？