數據庫vs Solr vs圖形數據庫（Neo4j）

我在想我的問題可能的解決方案（工具）。有一大堆地點（超過600 000）元素的集合。位置具有不同的語言名稱，並以樹形結構表示：區域 - >國家 - >管理部門 - >城市 - >郵編。用戶可以添加自定義位置，但我計劃這些操作很少發生。應用程序應提供有效的能力，以按位置名稱，類型執行搜索，以構建分層名稱（如「倫敦 - >英格蘭 - >英國」），建立位置子樹（即歐洲所有國家和城市）。數據庫vs Solr vs圖形數據庫（Neo4j）

我已經考慮過三種解決方案。

平原數據庫：位置將持有一些表和主樓邏輯將用Java代碼來實現。在這種解決方案的情況下，我擔心性能，因爲搜索，構建樹和創建自定義位置可能會涉及到額外的表連接。
SOLR：乍一看這個任務正好適用於solr：數據集很少變化，我們需要按名稱搜索。但我擔心如果Solr支點功能將滿足樹木建設需求。此外，我不確定Solr搜索是否會比普通DB好得多，因爲搜索並不困難（只需使用短字符串名稱搜索）。
graph db Neo4j：它似乎對構建樹和子樹有用。但我不知道搜索性能（看來我應該使用的社區版，它不具備一些有用的性能功能，如高速緩存等）

來源

2014-05-08 Vladimir Zenkevich

這實在是一個基於意見的問題。您可以使用任意數量的數據庫類型解決您的問題。沒有單一的正確答案，還有許多其他因素需要考慮，例如HA，數據攝取率，數據讀取率等。 –

數據庫是一個很大的NO。因爲RDBMS並未針對基於關係的查詢進行優化。例如，讓我看看那些在我所在的同一家餐廳吃飯的人，這些人也屬於我所在的地區。或者使它更復雜，一個數據庫查詢可能是一個殺手級別的關係要計算。就像我可以成爲你的二級朋友，你的一個或多個朋友是我的朋友。

SOLR：Solr是一個不錯的選擇，但你必須看到它的性能影響。有這麼多的行索引它可以是一個記憶殺手。在實施SOLR之前先通過這些。 http://wiki.apache.org/solr/SolrPerformanceProblems

http://wiki.apache.org/solr/SolrPerformanceFactors

SOLR也沒有更多的邏輯搜索一個很好的解決方案與往常一樣去爲它來學習這一切。

Neo4J（或任何其他圖形DB）是完美的解決方案。我自己實現了所有這三種技術，並且憑藉我的經驗，我發現Neo4J最適合這種需求。

但是，您必須瞭解如何備份數據庫以及如何在發生崩潰時進行恢復。

一切順利。

來源

2014-05-08 12:31:06

OP應該真正指出這些相對類型的查詢執行的頻率。層次結構的遍歷肯定是neo4j的理想選擇，但是通過位置名稱進行搜索處於SOLR甚至RDBMS的最佳位置。另外，如果OP的層次結構只有3深（最大），那麼RDBMS在那裏可能並不那麼糟糕。如果OP的層次結構很龐大，那麼與neo4j的差異將佔主導地位。但目前尚不清楚neo4j在這裏是否最好;如果80％的工作負載是按名稱搜索的，並且層次結構永遠不會超過3深，那麼RDBMS或SOLR可能會更好*總體*。 – FrobberOfBits

而......這個答案就是爲什麼這個問題應該以*基於意見爲基礎來關閉。*這個答案純粹是基於意見的，但是被陳述爲事實/絕對。 –

數據庫vs Solr vs圖形數據庫（Neo4j）

回答

相關問題