哪種技術最適合存儲和查詢巨大的只讀圖？

我有一個巨大的有向圖：它由160萬個節點和3000萬條邊組成。我希望用戶能夠找到圖形兩個節點之間的所有最短連接（包括傳入和傳出邊緣）（通過Web界面）。目前我已經將圖存儲在PostgreSQL數據庫中。但是這個解決方案不是非常高效和優雅，我基本上需要存儲圖形的所有邊緣兩次（請參閱我的問題PostgreSQL: How to optimize my database for storing and querying a huge graph）。哪種技術最適合存儲和查詢巨大的只讀圖？

有人建議我使用GraphDB，如neo4j或AllegroGraph。然而，AllegroGraph的免費版本僅限於5000萬個節點，並且還具有非常高級的API（RDF），這對我的問題來說似乎過於強大和複雜。另一方面，Neo4j只有非常低級的API（並且python界面還不成熟）。它們都似乎更適合於問題，其中節點和邊緣經常被添加或移除到圖形中。對於圖表中的簡單搜索，這些GraphDB似乎太複雜了。

我有一個想法是「濫用」像Lucene這樣的搜索引擎，因爲我基本上只在圖表中搜索連接。

另一個想法是，有一個服務器進程，將整個圖形（500MB到1GB）存儲在內存中。然後客戶端可以查詢服務器進程，並且可以非常快速地橫切圖形，因爲圖形存儲在內存中。用一些現有的框架編寫這樣一個服務器（最好是用Python編寫的）有沒有簡單的可能性？

您將使用哪種技術來存儲和查詢如此龐大的只讀圖？

來源

2009-12-22 asmaier

「對於圖表上的簡單搜索，這些GraphDB看起來太複雜了。」不知道這是什麼意思。除了圖形以外的任何東西存儲圖形都會增加複雜性。 – sevenforce 2014-10-17 18:52:02

LinkedIn必須管理一個相當大的圖。在他們的體系結構上檢查出this info可能是有益的。特別要注意他們如何將整個圖形緩存在內存中。

來源

2009-12-22 11:40:46

我有一個有向圖，我（錯）使用Lucene。

每條邊都作爲文檔存儲，其中節點爲文檔的字段，然後我可以搜索。

它的表現已經足夠好了，並且查詢時間用於從節點獲取入站和出站鏈接對於將其用作基於Web的工具的用戶來說是可接受的。但是對於計算密集型的批量計算，我正在做很多100000次查詢，我不滿意查詢時間。我明白我絕對會濫用Lucene，因此我正在開發第二個基於Berkeley DB的實現，以便我可以對兩者進行並排比較。如果我有機會在這裏發佈結果，我會做。

但是，我的數據要求比您的要大得多，大於3GB，超過了我的可用內存。因此，我使用的Lucene索引位於磁盤上，但對於Lucene，您可以使用「RAMDirectory」索引，在這種情況下，整個內容將存儲在內存中，這可能很適合您的需求。

來源

2009-12-22 12:09:04 Joel

創造性的解決方案，但不會邊緣的關係數據庫一樣好？或者我錯過了使用lucene獲得的一些免費功能？ – drxzcl 2009-12-22 15:24:54

是的，它可能會。我之所以使用Lucene是因爲我當時已經在使用Lucene，並且我想要一個完全可以在我的應用程序（如bdb）中運行的獨立的，可移植的解決方案。 – Joel 2009-12-22 16:38:45

糾正我，如果我錯了，但由於每個節點都是鏈接節點的列表，在我看來，具有模式的數據庫比負載更重要。它還聽起來像谷歌應用程序引擎將是對你的衚衕：

它優化用於讀取 - 如果你希望它更快
它的分佈還有的memcached的 - 這樣的大小不會影響效率

當然，如果你以某種方式依賴於關係數據庫尋找路徑，它不會爲你工作...

我只是注意到，q是4個月大

來源

2010-04-24 21:58:55 Nick

也有OrientDB一個開放源碼的文件圖形DBMS與商業友好許可證（Apache 2）。簡單的API，SQL語言，ACID Transactions和Gremlin圖形語言的支持。

SQL具有樹和圖的擴展。例如：

select from Account where friends traverse (1,7) (address.city.country.name = 'New Zealand')

要返回至少有一個居住在新西蘭的朋友的所有帳戶。而對於朋友則意味着遞歸到深度的第七層。

來源

2010-09-23 09:54:18 Lvca

所以你有一個圖形作爲你的數據，並希望執行一個經典的圖形操作。我看不出其他什麼技術比圖形數據庫更適合。

來源

2014-10-17 18:57:23 sevenforce

哪種技術最適合存儲和查詢巨大的只讀圖？

回答

相關問題