主內存數據庫vs對象數據庫

Question

我正在嘗試選擇數據庫供應商。

我只是從其他數據庫開發人員那裏尋求個人意見。

我的問題是特別有針對性的對人誰：

1）主內存數據庫（MMDB），支持複製到磁盤（混合）之前（即ExtremeDB）

或

2已經使用）已經使用Versant Object Database和/或Objectivity Database和/或Progress ObjectStore

問題是：如果你可以推薦一個數據庫供應商，根據你的經驗這將適合我的應用程序。

我的應用程序是一個商業實時（讀取：高性能）面向對象的C++ GIS類應用程序，我們需要做很多緯度/經度搜索（即給定一個區域，找到所有匹配的目標在該區域內... R-Tree索引）。

我想存儲到數據庫中的數據類型都是建模爲對象，並且它們使用std :: list和std :: vector，所以很自然地，對象數據庫似乎是有意義的。我已經經歷了足夠的文章讀來說服自己，傳統的RDBMS可能心不是我真正在

1. 性能方面尋找（連接或多個 表動態長度的數據，如 列表/矢量）
2. 易於編程 （阻抗不匹配）

然而，在性能方面的，

1. 輸入數據以約40 MB/s的速度輸入系統。

2. 因此，該系統也將被以每秒大約350插入物的速率（其中，每個對象從64KB到128KB而異），做插入到數據庫

3. 數據庫將始終如一地被搜索和經由多個更新線程。

從我的理解中，我列出的所有Object DB都使用緩存來存儲數據庫對象。 eXtremeDB的聲稱，因爲它是專門爲內存，這樣可避免緩存邏輯的開銷等，通過谷歌搜索查看更多：主內存與RAM磁盤數據庫：一個基於Linux的基準

So..I'm剛有點困惑。對象DB可以用於實時系統嗎？它與MMDB一樣「快」嗎？

Answer 1

從根本上說，MMDB和OODB的區別在於MMDB有一個期望，即其所有數據都基於RAM，但在某個時刻仍然保留在磁盤上。而OODB更傳統，因爲沒有期望整個DB適合RAM。

MMDB可以通過放棄持久數據不一定必須「匹配」RAM數據的概念來利用這一點。

的方式與持久什麼是去工作，是它寫在以某種方式更新數據到磁盤。

幾乎所有的數據塊都使用某種日誌的這一點。這些日誌基本上是附加到文件的「原始」數據頁面，或者可能是單個事務。當文件變得「太大」時，將啓動一個新文件。

一旦日誌中到主存儲適當合併，日誌將被拋棄（或重複使用）。現在

，粗，在RAM DB可以通過附加事務日誌文件只是存在，它的重新啓動時，它只是加載在日誌中RAM。所以，實質上，日誌文件就是數據庫。

這種技術的缺點是時間更長，更多的交易你有更大的日誌/ DB是，這樣長的DB的啓動時間。但是，理想情況下，您還可以「快照」當前狀態，從而消除所有日誌，並有效壓縮它們。

以這種方式，數據庫必須管理的所有例行操作都是將頁面附加到日誌，而不是更新其他磁盤頁面，索引頁面等。因爲理想情況下，大多數系統不需要「啓動「通常，開始時間可能不是問題。

所以，在這種方式中，內存數據庫可以比誰擁有與磁盤不同的合同，維護日誌和磁盤頁面的面向對象數據庫更快。通過這種方式，一個面向對象數據庫可以更慢，如果整個DB適應在RAM中，正確緩存，僅僅是因爲你在正常操作期間招致磁盤操作日誌操作之外，Vs的內存數據庫，其中這些操作發生的「維護」任務，可以在停機時間和/或安靜時間進行調度。

至於是否這兩種系統都能滿足你的實際性能需求，我不能說。

Answer 2

的後端的數據庫（讀寫器進程，緩存，鎖管理，TXN日誌文件，ACID語義）是相同的，所以RDBS和麪向對象數據庫實際上是非常相似的在這裏。區別在於應用程序員的接口。你的數據模型是否複雜，由許多具有真正繼承關係的類組成？然後OO是好的。它是相對平坦和簡單嗎？然後去RDB。關係的性質是什麼？它是否像指針一樣設置？然後去RDB。是更復雜的，像（有序）列表，數組，地圖？那麼你應該去OO。另外，你有沒有需要與其他應用程序集成的獨立應用程序？然後OO就OK了。您是否必須與其他應用程序共享數據（即多個應用程序訪問相同的數據庫）？那麼這對於面向對象來說是一個破壞行爲，你應該堅持RDB。數據庫的架構是否穩定或您期望其頻繁發展？ OODB是糟糕的廣告模式演變，所以如果您希望頻繁更改，請堅持使用RDB。