簡單圖形激活的低延遲

Question

我使用db4o作爲看起來像語義wiki的項目的後端。 我的主要擔憂是爲什麼表演如此之低？

這裏是上下文：

的應用程序中使用openJdk6 &的db4o-V8.1。該模型是在四個層次的傳承約20個類，有激活的藏品，參考，UUID，指數等

使用，我發現SYS-時間日誌的時間是在部分花...對象的操縱。對於30次激活或更新，應用程序平均需要1.1秒（在提交時數據少於1Kb）。我已經檢查了內存（轉儲），從透明激活中可以看出，圖中的一小部分是負載（我的數據庫大約是20K對象和20Mb）。我幾乎從不使用querys，總是關係激活。

我在同一主機上使用客戶端服務器。 db-server就是我們可以在db4o網站上找到的例子。客戶端 - 服務器殺死了一些性能，但對於併發性來說是必需的。主機依靠一個可以啓用300個左右的fc存儲。

• 可以做些什麼來提高性能，減少延遲？
• 我錯過了什麼嗎？
• 有什麼竅門我應該知道？

Answer 1

如果你按照手冊，那麼問題來自你的數據模型 或使用它的使用。 如果您已經對使用情況進行了所有可能的優化，最後的方法 是數據模型的更重要的因素;如果你沒有...現在就做。

所以簡短的回答：不使用繼承，保持關係鏈儘可能短。

較長的答案：

• 活力花費很多。類繼承爲激活時的方法解析和對象解析添加動態。

在hibernate/sql like db;繼承可以看作表連接，加載一個對象意味着將多行加載到一個表格中作爲繼承級別。所以速度受限於聯接requiere（和聯接條件）。

在db4o中，當您導航拋出一個對象時，決定使用對象的所有字段在用戶級別部分完成;所以所有的對象指針都是加載的情況下激活一個字段。因此，對象模型的所有部分都必須從數據庫加載（對於激活的對象）。這與hibernate/sql db中發生的事情非常相似。

• 爲了避免掃描到模型的玉米粥份，並加載到玉米粥激活指針，我們可以重寫模型一點。 只需刪除每個繼承關係，並將其替換爲指向相應對象的字段即可。

如果A擴展B，然後在B中添加一個指向A的字段並刪除擴展關係。然後根據需要使用透明激活從A導航到B.這個技巧在很多領域，數據庫中都是有效的。這是因爲在複雜的圖形關係中，我們很少在一次計算中使用對象的所有字段。

• ，以提高性能的另一種解決方案是使用更短的啓動路徑，來實現這一點，你需要在你的模型和計算的巨大變化;一種方法是使用快速原生查詢，而不僅僅是透明激活。

對於在對象數據庫中查看性能的良好夜晚，您還可以查看objectDB。有和db4o相同的問題。