SQL和elasticsearch之間的良好規範

想象一下，您有一個SQL數據庫，如mysql或postgresql。你有兩張桌子：用戶和汽車。一個用戶可以驅動N輛汽車，一輛汽車可以由N個用戶驅動，所以你有第三個帶兩個外鍵的「驅動器」表。SQL和elasticsearch之間的良好規範

現在，您希望您的表用戶繼續進行elasticsearch，因爲您希望按名稱，電子郵件等搜索用戶......也許您還需要在汽車桌面上進行一些搜索。

我看到三個方式來實現這一目標，我D'想知道什麼是最好的方法：

1）放棄的SQL數據庫。所有表格現在都在elasticsearch上。您可以根據需要進行搜索，但必須手動處理所有約束。

2）保持sql數據庫的結構，你保留你的三個表，主鍵和外鍵。但是您的表只包含elasticsearch中關聯行的elasticsearch ID。例如，對於表用戶，您保留user_id並添加一個user_elasticsearch_id指向您在其中找到名稱，電子郵件地址的彈性搜索行...等等...因此，您擁有sql約束，您可以執行搜索，但您必須維護兩張桌子。

3）重複。你不碰你的sql數據庫，你複製了elasticsearch數據庫中的所有行。你有自己的限制，你可以搜索，但是你必須保持兩張表格，你有兩倍的數據和兩倍的存儲空間。

現在，勇敢的stackoverflow夥伴，你會在這種情況下做什麼？

謝謝。

來源

2016-12-22 Oreste Viron

這個答案應該有幫助：http://stackoverflow.com/questions/36915428/how-to-setup-elasticsearch-index-structure-with-multiple-entity-bindings/36982705#36982705和這一個也是：http： //stackoverflow.com/questions/40410920/elasticsearch-usage-with-mysql/40415430#40415430 – Val

謝謝，我會讀這個:-) –

因爲你可能有很多業務規則混合到你使用它的數據庫和應用程序中，所以我會保守並保留數據庫。並使用ES來索引我想要搜索的用戶屬性。 ES會返回得分結果。當結果選擇我將切換到數據庫來檢索所有信息和關係。

所以我會選擇2b：保持數據庫和存儲在ES中的PK，而不是在數據庫中的ID）。

請記住，您可以強制ID EN ES。它可能是「user_PK」或類似的東西。

來源

2016-12-22 10:30:18 Setop

關鍵業務數據最常見的設置是例如一個SQL數據庫作爲您的主數據存儲區，Elasticsearch作爲附加搜索索引。（=你的解決方案3）。

對於像日誌等非關鍵業務數據的替代方案是單獨使用Elasticsearch。

解決方案2似乎有線，不是我的選擇。

來源

2016-12-28 12:56:31 Philip

SQL和elasticsearch之間的良好規範

回答

相關問題