H2データベースは、大きなテーブルを持つ組み込みデータベースとして適していますか？

Question

私たちのアプリケーションは、現在、組み込みデータベースとしてH2を使用して、我々は次のシナリオを持っている：

• H2は「一時的なデータベース」として使用されています。 H2に挿入されたデータは、アプリケーション・タスクによって30分ごとにOracleデータベース（「公式」データベース）に周期的に送信/挿入され、H2から削除されます。

• このメインの「テンポラリテーブル」は、1時間に1つのテーブルに平均183行挿入されています。

• 私たちは、照会のためだけにメインのアプリケーション・タスクで使用される2つの他の大きなテーブル（それぞれ2,100万と150万レコード）を持っています。最後の同期以降にOracleで作成、更新、削除されたH2行を更新して、Oracleからこれらの表を増分更新する別のアプリケーション・タスクがあります。 30分ごとに発生します。

  我々は何の問題もなく、これまでに1.5年間のH2を使用しているが、我々はRed Hat official documentationでH2に関する次の警告を見つけた

：

しかし、それは生産に使用すべきではありません環境。これは、アプリケーションのテストと構築に必要なすべての標準をサポートしていますが、実稼働環境で使用するには堅牢ではなく、スケーラビリティがない、非常に小さく自己完結型のデータソースです。

このようなシナリオでは、H2は本番環境で使用するように設計されており、信頼性がありますか？

これをサポートするベンチマークはありますか？ H2 official performance benchmarkは実行時間とパフォーマンスの使用状況を示しますが、データ量については何も言及していません。

Answer 1

組み込みH2データベースはメモリ内または永続的ですか？私の主な関心事はフェイルオーバーです。 JVMがダウンすると、最後のOracle同期ポイント以降のデータは失われます。

それ以外では、埋め込まれたH2データベースはアプリケーションと同じJVM内でのみ使用できます。したがって、複数のJVMを持つ高可用性アーキテクチャにスケールアウトすることはできません。各JVMには独自のH2データベースがあり、JVM全体でそのデータを共有することはできません。

最後に、ヒープの問題があります。メモリ内のJVMを使用している場合は、データ量に応じてヒープが増加し、RAMを使い果たす可能性があります。ガベージコレクタがヒープを使い果たしないようにするために、スラッシングが発生する可能性があります。

その他の制限は、ここで見つけることができる：http://www.h2database.com/html/advanced.html#limits_limitations