建立並行搜索引擎和數據庫API的良好設計模式是什麼？

我正在與關係數據庫並行使用搜索引擎。感興趣的主要目標是「列表」。它在組合風格結構中有大約5個其他實體。一個是位置，另一個是複雜的時間和日期定義。

根據我的經驗和研究，Solr，Lucene，Elastic SEarch的搜索速度比任何添加了全文和地理索引的數據庫都快。所以，這就是爲什麼我希望對數據庫中的數據使用搜索引擎。此外，搜索引擎將包含比數據庫更細的時間條目，更具體與形式。

所以，參照設計模式：目標是讓CRUD從API發生到實體上的數據庫內容以及在搜索引擎索引中實例化的所有時間和地理排列。

我與一位合夥人進行過討論，我認爲他說得對，當他說爲了保持低耦合性，'Listing'類（再次，數據中數據層次的頂部）不應該知道關於搜索引擎，並且沒有添加靜態功能來在搜索引擎上進行搜索。他表示，「責任鏈」設計模式可能是允許API的CRUD對數據庫和搜索引擎內容採取行動的適當方式。我的閱讀是不正確的。

我一直在尋找http://sourcemaking.com/design_patterns，我認爲門面模式，http://sourcemaking.com/design_patterns/facade，可能是最好的。但我想聽聽其他意見。

預先感謝您。

PS。我正在開發一個能夠注入Spring IOC的osem層（http://en.wikipedia.org/wiki/Compass_Project）。此圖層是爲ElasticSearch定製的。到目前爲止，它不支持事務或外鍵（並且可能永遠不會這樣做）。但是它會在後面開發這些註釋。你可能想看看它。它在https://github.com/kwince/osemManager。目前有兩個分支正在進行中。我將在下週決定合併哪一個。

來源

2012-01-22 Dennis

要麼我走開，要麼讓她感到困惑。我想你需要打破這個問題，有很多事情可以在這裏的不同層次進行並行化。 – Ali

編程不是我爲了生活而做的。所以，我已經盡我所能地解釋了它。 – Dennis

外觀模式更適合隱藏一個相對簡單的界面背後的一些複雜的子系統。

從我可以理解你有2個不同的系統，你想發送相同的請求到兩個。你需要知道什麼是這兩個系統之間的關係：

如果沒有某種形式優於另一種系統的首選項，你會使用責任鏈：你發送一個請求，如果第一個系統可以處理它，你會得到結果，如果沒有，請求會進入鏈中的下一個系統，依此類推。
如果某種形式的某個系統的結果來自另一個系統的結果的增強或增強，那麼您將使用裝飾器，因此請求首先進入「外部」系統，它會調用「內部」系統，獲得一些結果然後用它自己的數據裝飾它們並返回裝飾結果;
如果你只有2個你想要並行查詢的獨立系統，那就用「just do it」pattern =）從框架中使用一些parralel原語，發送2個請求，等待兩個結果，將它們提交給合併函數。

希望這會有所幫助。

來源

2012-02-20 18:06:30

建立並行搜索引擎和數據庫API的良好設計模式是什麼？

回答

相關問題