是否準備好了ObjectDB？

Question

在這個基準ObjectDB是迄今爲止速度最快的DB： http://www.jpab.org/All/All/All.html

但我無法看到ObjectDB任何其他基準測試結果。 是否有人使用ObjectDB？生產準備好了嗎？有什麼經驗？

Answer 1

我已經將它用於許多項目和產品，無論是專業還是個人。我已經用了5年多了。這些是我的經驗：

聲明：我擁有服務器許可證和OEM許可證，並且多年來必須瞭解創建者。我與ObjectDB公司沒有其他的商業關係 - 換句話說，如果他們銷售更多的副本，我就從商業上獲益匪淺。我只是喜歡這個產品。

我的用法：

1. 個人：我用它作爲說出來我的博士的商業產品的一部分，堅持UML2/EMF模型。這些是很多類的複雜事物，而ObjectDB是我能夠發現的唯一能夠處理具有足夠性能的複雜鏈接的產品。在這樣的環境中，它一直是一位傑出的演員。

2. 工作相關：我在一家投資銀行工作，我們使用ObjectDB來堅持工作流狀態並處理大型網格（> 2000節點）環境中的持久性。它在這個環境中也運行得非常好。

我也是一個顧問Gentleware在一個點早在2007年左右，我們評估ObjectDB反對db4o中，休眠等它跑贏附近的任何競爭一個數量級。這是我第一次使用它的商業經驗。

所以，底線是我發現ObjectDB速度非常快，並且堅如磐石。我們在UML2模型上單獨測試了10GB，並且在那裏沒有問題。我從來沒有一個數據庫死在我身上，或者在我使用它的所有時間裏都損壞了。此外，它的佔地面積非常小。簡而言之，這是一個空間中的無名英雄。

我的經驗與jpab基準一致 - 他們爲其他產品的所有者製造不舒服的閱讀，但是......雖然我可能並不完全沒有偏見 - 但我與創作者有很多聯繫，多年來ObjectDB一直在推動它們發佈基準測試。特別是，我覺得他們應該讓圖形線性而不是對數 - 它表明在大多數情況下，ObjectDB的性能要好得多。另外，爲什麼在這個或任何其他JPA產品上找不到許多其他基準的原因是，沒有任何供應商能夠基本達成基準並傾向於指責其他偏見。我多次看到這個第一手牌。有些人更喜歡polepos，但這主要由db4o支配，而這些人不會公佈dn結果。有些數據庫供應商不允許結果等。這是一個雷區，ObjectDB的創建者在這裏沒有什麼不同。每個人都喜歡控制自己的基準;-)無論如何，長話短說，我的誠實經驗是，ObjectDB非常快，生產已經準備好了（多年來回到1.x），並得到很好的支持。這是一個非常好的產品。

Answer 2

我不相信沒有獨立驗證的基準。如果您檢查版權信息，該網站實際上由ObjectDB的所有者擁有和運營！

這就是說，我沒有數據來反駁他們的說法，我只是不把它們當作面值。

Answer 3

我也一直在用商業身份使用ObjectDB多年（我認爲7年）。我們公司有兩種使用數據庫的產品（兩種嵌入式版本）。我們的產品之一顯示有關在移動設備（即手機）和模擬網絡之間發送的信號的信息。儘管我們實際上爲我們運行的每個測試都創建了一個單獨的數據庫，但我們通常可以將高達1GB的等效XML數據保存到數據庫中。

保存數據的速度非常快（通常比讓Windows複製等效的XML文件更快）。檢索速度非常好，允許我們滾動瀏覽數千個（甚至數萬個）以圖形表示的項目，就像滾動瀏覽Windows資源管理器文件目錄一樣。

ObjectDB是一個很好的產品，我希望能繼續使用它。當我們開發我們的產品時，我們遇到了一個奇怪的問題（雖然我們不需要報告任何事情，只要我記得），但是我們解決所有問題的速度是最好的，曾經遇到過。

爲了回答你「這個生產準備好了」的問題，在我看來，它當然是。

Answer 4

我們已經在我們的啓動中使用Object DB超過5個月。在查看不同的技術（RDBMS，Graph db和object db）之後，我們在猶豫了很久才找到了objectDB。我們正在開發一個基於Web的業務應用程序，我們對持久層有一系列要求。我們認爲除其他： MySQL和PostgreSQL，德比的，db4o，ObjectivityDB，了Perst，臭氧，Neadatis ODB，Neo4j的，OrientDB

我們的要求是：

• 成熟的產品穩定性
  ObjectDB更超過6 歲 - 在2.2.9版，因爲我們說話
• 支持與社區
  我們希望確保有 有人幫助，如果我們有一個概率lem，到目前爲止，我們非常高興 以我們的問題得到答案的速度。社區可能更大但非常活躍。
• 發展速度
  敏捷和快速的功能 週轉對象數據庫是非常簡單和直接 前進。我們認爲RDBMS + Hybernate但這是緩慢和 有點令人費解
• 有能力承受此重負載
  沒有什麼科學的，但我們 要感覺舒適，該系統能夠處理大量 數量的併發請求。我們測試了多達1000個併發 請求，這些請求包含索引查詢，對象更新，創建和 刪除和收集更新，以嘗試和模擬我們的應用程序的負載。 ObjectDB的前2
• 快速
  同樣在這裏我們使用相同類型的查詢和定時他們， 我們還增加了負荷，我們認爲將是我們後期的 合理的猜測去走了出來再次活荷載和ObjectDB是 不斷地在頂部2
• 能夠處理大量數據
  與1，我們逐漸增加 客戶的數量在我們的數據庫，以500萬級的客戶（這是一個 樂觀一點）來每個5個訂單並檢查 表現。有沒有顯著的性能下降（與地方 正確的索引！）
• 開源/廉價
  小問題與爲我們使用GWT和它有時會出現問題的原因 系列化沒有訪問 源管理的集合和日期（儘管一個解決辦法 存在）
• JPA支持
  如果可能的話，我們希望JPA或JDO支持輕鬆 結合現有框架（春季）集成，可以放心， 出現最壞的情況，我們仍然可以去回到一個古老的RDMS系統 - 雖然我不得不說，對象持久性是如此簡單，並且透明，因此有時很難堅持JPA 的要求。

總的來說，ObjectDB一直在我們的前2名選手中，有時是第一名，有時是第二名，因此我們選擇了。錯誤修復和新功能發佈的頻率令人印象深刻。

我希望這會有所幫助，如果我在我們去世之前（明年年初）有一段時間把我們的結果呈現爲一個可以表達的格式，我會嘗試在這裏發佈它們。

Answer 5

的行業標準基準是，

http://www.spec.org/jEnterprise2010/

一個大量使用JPA

注意，它測試整個Java EE服務器，不只是JPA，但JPA是最顯著的部分基準。主要的JPA產品已通過其各自的應用程序服務器提交結果。由於大多數結果都在不同的硬件上，因此SpecJ並不像JPAB結果那樣容易比較產品，但結果都是同行評審的，所以可以更加信任。它也是一個模擬的真實應用程序，具有多個用戶，一個大型數據庫，併發和隔離要求，大多數結果都在一個集羣上。

沒有ObjectDB結果可用，但理論上，因爲ObjectDB支持JPA，所以應該可以在其上運行SpecJ，並將其與其他產品進行比較。

Answer 6

我在一個小項目上測試ObjectDB。以下是我的評論：

• 在使用JDO時沒有太多的文檔/教程。 JPA擁有更多的文檔。
• 教程太簡單，遠離現實。
• 我遇到了DatabaseExplorer中的2個bug。但它在新版本中迅速修復。
• 論壇支持非常好，我很快收到答覆。

與Versant DB相同的項目和ObjectDB相比，入門更直接。

Answer 7

我不相信沒有獨立驗證的基準。如果您查詢版權信息，這個網站實際上是擁有的，並且 由ObjectDB的所有者操作！

更重要的是，數據是一回事，解釋是另一回事。而且真的有一個解釋爲什麼它應該更快一個量級。這一點以及他們網站上顯示的基準非常低，因此只顯示整個圖片的很小部分的事實對我來說似乎很奇怪。我的經驗（一般來說，與ObjectDB不同）是，例如，hibernate取決於工作負載類型，如果您需要遷移數據庫，則需要明確調整hibernate行爲以獲得不錯的性能。 ObjectDB是否支持緩存？它是否僅適用於垃圾緩存的大吞吐量場景？

更新

我剛纔讀http://www.objectdb.com/database/forum/259。對速度的典型剋星是，猜測是什麼，一致性。看來ObjectDB根本不支持任何合理的併發模型。那麼，它基本上只是一個NoSQL存儲？