メインメモリDBとオブジェクトDB

Question

現在、データベースベンダーを選んでいます。

私は仲間のデータベース開発者から個人的な意見を求めています。

私の質問は、特に人々をターゲットにされています（つまり、ExtremeDB）

または

2の前にディスク（ハイブリッド）への複製をサポートメインメモリDB（MMDB）を使用している

1） ）Versant Object Databaseおよび/またはObjectivity Databaseおよび/またはProgress ObjectStore

を使用しています。あなたの経験に基づいてデータベースベンダーを推薦できる場合は私のアプリケーションに合ったnce。

私のアプリケーションは、多くの緯度/経度の検索を行う必要がある、商用のリアルタイム（読み込み：高性能）オブジェクト指向のC++ GISアプリケーションです（つまり、エリア内... Rツリーインデックス）。

データベースに保存したいデータ型はすべてオブジェクトとしてモデル化されており、std :: listとstd :: vectorを使用するため、当然Object Databaseが理にかなっているようです。私は（ リスト/ベクトルのような動的長データ用 テーブルを結合または複数の）伝統的なRDBMSはおそらく私が本当に

1. パフォーマンスの面で探しているものをイマイチという自分自身を納得させるのに十分な記事を読みましたプログラミング 性能の点で

しかし（インピーダンス不整合）の

容易さ、

1. 入力データが約40MB/sでシステムに供給されています。

2. したがって、システムはまた、（各オブジェクトが128キロバイトに64KBから変化）秒当たりおおよそ350インサートの速度でデータベースに挿入を行うであろう

3. データベースが一貫して検索し、複数を介して更新されますスレッド。

私の理解から、私がここに挙げたすべてのオブジェクトDBは、データベースオブジェクトを格納するためにキャッシュを使用しています。 ExtremeDBは、特にメモリ用に設計されているので、ロジックのキャッシュなどのオーバーヘッドを避けることができると主張しています。主なメモリとRAMのディスクデータベース：Linuxベースのベンチマーク

だから私はちょうど少し混乱している。オブジェクトDBはリアルタイムシステムで使用できますか？それはMMDBと同じように「高速」ですか？

Answer 1

基本的に、MMDBとOODBの違いは、MMDBはすべてのデータがRAMに基づいていますが、ある時点ではディスクに保存されているということです。 OODBは、DB全体がRAMに組み込まれることは期待できないという点でより一般的ですが、

MMDBは、永続化されたデータがRAMデータに必ずしも一致する必要はないという概念を捨てることによって、これを活用できます。

永続性があるものは、何らかの形で更新時にデータをディスクに書き込む必要があります。

ほとんどすべてのDBは、これに何らかのログを使用します。これらのログは基本的に、ファイルに追加されたデータの「生の」ページ、またはおそらく個々のトランザクションです。ファイルが大きすぎると、新しいファイルが開始されます。

ログがメインストアに正しく統合されると、ログは破棄（または再利用）されます。

ここで、粗いRAM DBはトランザクションをログファイルに追加するだけで、再起動するとログをRAMにロードするだけです。したがって、本質的に、ログファイルはデータベースです。

この手法の欠点は、トランザクションが長くてトランザクションが多いほど、ログ/ DBが大きくなり、DBの起動時間が長くなることです。しかし理想的には、現在の状態を「スナップショット」することもできます。これにより、最新の状態がすべて消去され、効果的に圧縮されます。

このように、DBの通常の操作では、他のディスクページ、インデックスページなどを更新するのではなく、ログにページを追加するだけです。理想的には、ほとんどのシステムでは「起動"それはしばしば、おそらく時間を開始することは問題ではない。

このように、MMDBは、ログとディスクページを維持しながら、ディスクと異なる契約を持つOODBよりも高速になります。このように、DB全体がRAMに格納され、適切にキャッシュされていてもOODBは遅くなる可能性があります。これは、通常の操作ではディスク操作が発生し、タスクは、ダウンタイムおよび/または静かな時間にスケジュールすることができる。

これらのシステムのいずれかが実際のパフォーマンスニーズを満たすことができるかどうかについては、私は言うことができません。

Answer 2

データベースのバックエンド（リーダライタプロセス、キャッシング、ロック管理、txnログファイル、ACIDセマンティクス）は同じです。したがって、RDBとOODBは実際には非常によく似ています。違いは、アプリケーションプログラマとのインタフェースです。あなたのデータモデルは複雑で、本当の継承関係を持つ多くのクラスで構成されていますか？その後、OOは良いです。それは比較的フラットでシンプルですか？次に、RDBに行きます。関係の性質は何ですか？それはポインタのようなものですか？次に、RDBに行きます。リスト（配列）、マップのようにもっと複雑ですか？それからOOに行くべきです。また、他のアプリと統合する必要のないスタンドアロンアプリケーションもありますか？その後、OOはOKです。他のアプリとデータを共有する必要がありますか（つまり、複数のアプリが同じデータベースにアクセスしています）。それはOOのためのディール・ブレーカーであり、RDBを守るべきです。データベースのスキーマは安定していますか、頻繁に進化すると思いますか？ OODBは広告スキーマの変化が激しいため、頻繁に変更する予定がある場合は、RDBに固執してください。