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

Question

現在、データベース ベンダーを選択しようとしています。

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

私の質問は、特に次のような人々を対象としています。

1) 以前にディスク (ハイブリッド) へのレプリケーションをサポートする Main Memory DB (MMDB) を使用したことがある (すなわち、 エクストリームDB)

または

2) 使用したことがある Versant オブジェクト データベース および/または 客観性データベース および/または 進行状況オブジェクトストア

そして実際の質問は次のとおりです。あなたの経験に基づいて、私のアプリケーションに適したデータベース ベンダーをお勧めできますか。

私のアプリケーションは商用リアルタイムです (読んでください:高パフォーマンス) オブジェクト指向 C++ GIS の種類のアプリで、緯度/経度検索を大量に実行する必要があります (つまり、指定されたエリアで、エリア内の一致するターゲットをすべて検索します...R ツリー インデックス)。

データベースに保存したいデータの種類はすべてオブジェクトとしてモデル化されており、std::list と std::vector を使用するため、当然、オブジェクト データベースは理にかなっているように思えます。私は十分な量の記事を読み、従来の RDBMS はおそらく私が本当に探しているものではないと確信しました。

1. パフォーマンス（List/Vectorなどの動的長さのデータのための結合または複数のテーブル）
2. プログラミングの容易さ（インピーダンスの不一致）

ただし、性能面では、

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

2. したがって、システムは、1 秒あたり約 350 回の挿入の速度でデータベースへの挿入も実行します (各オブジェクトのサイズは 64KB から 128KB まで変化します)。

3. データベースは複数のスレッドを通じて一貫して検索および更新されます。

私の理解では、ここにリストしたオブジェクト DB はすべて、データベース オブジェクトの保存にキャッシュを使用しています。ExtremeDBは、メモリ専用に設計されているため、キャッシュロジックなどのオーバーヘッドを回避できると主張している。グーグルでさらに詳しく見る:メインメモリ vs.RAM ディスク データベース:Linux ベースのベンチマーク

それで…ちょっと混乱しています。オブジェクトDBはリアルタイムシステムでも使用できますか?MMDBと同じくらい「速い」のでしょうか？

Answer 1

基本的に、MMDB と OODB の違いは、MMDB ではすべてのデータが RAM に基づいているが、ある時点でディスクに永続化されると想定していることです。一方、OODB は、DB 全体が RAM に収まるという期待がないという点でより従来的です。

MMDB は、永続化されたデータが RAM 内のデータと必ずしも「一致」する必要はないという概念を放棄することで、これを活用できます。

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

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

ログがメイン ストアに適切に統合されると、ログは破棄 (または再利用) されます。

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

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

このように、DB が管理しなければならないルーチン操作は、他のディスク ページやインデックス ページなどを更新するのではなく、ページをログに追加することだけです。理想的には、ほとんどのシステムはそれほど頻繁に「起動」する必要がないため、おそらく起動時間はあまり問題になりません。

したがって、このようにして、MMDB は、ディスクと別の契約を結んでログとディスク ページを維持する OODB よりも高速になります。このように、DB 全体が RAM に収まり、適切にキャッシュされている場合でも、OODB は遅くなる可能性があります。これは、通常の操作中にログ操作以外のディスク操作が発生するためです。一方、これらの操作が「メンテナンス」として発生する MMDB とは異なります。タスクは、ダウンタイムや静かな時間中にスケジュールできます。

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

Answer 2

データベースのバックエンド (リーダーとライターのプロセス、キャッシュ、ロック管理、txn ログ ファイル、ACID セマンティクス) は同じであるため、RDB と OODB は実際には非常によく似ています。違いは、アプリケーション プログラマへのインターフェイスです。データ モデルは複雑で、実際の継承関係を持つ多数のクラスで構成されていますか?それなら○○がいいですよ。比較的フラットでシンプルですか？次にRDBに進みます。関係の性質は何ですか?ポインタ的なものとセット的なものですか？次にRDBに進みます。(順序付き) リスト、配列、マップなど、より複雑ですか?それなら○○に行けばいいよ。また、他のアプリと統合する必要のないスタンドアロン アプリケーションはありますか?それなら○○でも大丈夫ですよ。他のアプリとデータを共有する必要がありますか (例:複数のアプリが同じデータベースにアクセスします)?その場合、それは OO にとって決定的な問題となり、RDB を使い続ける必要があります。データベースのスキーマは安定していますか? それとも頻繁に進化すると予想されますか?OODB は悪い広告スキーマの進化であるため、頻繁に変更されることが予想される場合は、RDB を使用してください。