圖表與對比關係數據庫的性能

Question

我正在研究一個近乎實時地執行大量圖形操作的項目。我們目前正在使用Hibernate，MySQL和EhCache，但考慮將所有與圖形有關的持久性移動到圖形數據庫，如Neo4j或Titan。

圖形數據庫可以比Hibernate +關係更好嗎？我只是想確保我們不會用另一半取代其中的六個。

Answer 1

對象圖越深，對象/圖形數據庫的性能優勢就越大。

關係數據庫性能明顯下降，超過七個JOIN。

諸如CAD/CAM之類的幾何系統具有用於物料清單的深度目標圖表優於其關係對應表。

關係數據庫有一個巨大的優勢：關係代數和數據之間的明確分離以及訪問和操作數據的「方式」。但它們並不適合所有問題。

Answer 2

如果您使用的是Hibernate，那麼您堅持域對象的本質是對象圖。

數據庫是表格結構，並確定這種關係，但快速分解。另外，Hibernate有一個討厭的習慣，就是用連接拉入整個數據庫。

鑑於Neo4j設計時使用了對象關係作爲它的核心功能，並且您在進行域持久化，所以這種自然設計更合適。

此外，Neo4j使用Lucene（一個愚蠢的快速搜索索引）執行查詢，並可以直接跳轉到您的節點進行遍歷。底線：Neo4j設計的是令人興奮的規模和準確的圖形相關數據的想法。你不會因爲縮放而出錯，但是你會發現工具和庫對於一個經典的數據庫連接來說不夠成熟。

Answer 3

當你移動到neo4j（或某些圖形數據庫）時，查詢時間保持不變（差不多），因此可以預測，而不考慮數據量的增加。根據您的數據域進行概念證明總是更好，因爲通用答案通常不適用於nosql dbs。

取自here。

Answer 4

圖形和關係數據庫都依靠緩存來提高查詢性能。但是，圖形數據庫中的邊緣遍歷通常是一個常量時間操作，如果頂點被緩存，則通常會緩存邊緣。對於RDBMS，外鍵遍歷需要在O（log n）時間的目標表上進行B樹索引查找。當索引不適合緩存時，數據庫將不得不執行緩慢的磁盤查找操作。

結賬Bitsy。如果你的圖形適合內存，查詢和更新速度非常快。或者你可以使用另一個Blueprints實現，如Neo4J和Titan，它可以處理更大的數據集。