web-dev-qa-db-ja.com

純粋なJavaデータベースの代わりに/レコードを保存するためのキャッシュ

私は顧客に販売するアプリケーションを作成しました。その一部は、固定制約（遅いCPU）を持つハードウェアメーカーです。アプリはJavaである必要があるため、単一のパッケージとして簡単にインストールできます。

アプリケーションはマルチスレッド化されており、オーディオレコードを維持します。この特定のケースでは、INSERT SOMEDATA FOR RECORDがあり、各レコードはオーディオファイルを表します（これはさまざまなスレッドで実行できます）。その後、後で（x、y、z）でSELECT SOMEDATA WHERE IDSを取得します。シングルスレッドの場合、3番目のステップは、このテーブルのすべてのデータを実際に削除することです。

主な制約はcpu、遅い単一のcpuです。メモリも制約ですが、アプリケーションが無制限の数のファイルを処理できるように設計されているという点でのみです。したがって、大量のメモリがあったとしても、すべてをディスクではなくメモリに保存すると、最終的にはメモリが不足します。

私のJavaアプリケーションでは、すべてのデータを保存するためにH2データベースを使い始めました。しかし、ソフトウェアはいくつかの遅い単一CPUサーバーで実行する必要があるため、使用するCPUサイクルを減らしたいと思います。もう一度見たいのはデータベースです。

多くの場合、データベースにデータを挿入するのは、データをヒープから切り離すためだけです。そうしないと、メモリが不足し、後でデータを取得するときに、データを更新する必要がなくなります。

したがって、ehCacheのようなキャッシュの使用を検討しましたが、これには2つの問題があります。

  • データが破棄されないことは保証されません（キャッシュがいっぱいになった場合）
  • 一度に1つのレコードしか取得できませんが、リレーショナルデータベースでは、レコードのバッチを取得できますが、これは潜在的なボトルネックのように見えます。

これらの問題を解決する代替手段は何ですか？

javadatabaseh2ehcache
3
Paul Taylor

Oracle のようなリレーショナルデータベースは数十年（41年）古くなっていますが、当時利用可能なCPUサイクルの数を想像できますか？ 1970年の調査に基づいており、専門家によく理解されており、テスト、文書化、信頼性、一貫性（チェックサム）、保守可能（データ損失ゼロのバックアップ）、正しく使用された場合のパフォーマンス（すべての種類のインデックス）、ネットワーク経由で安全にアクセス可能、スケーラブル、等が明らかにここで発明されていません。

今日、PostgreSQLのような無料のオープンソースデータベースも数多くあります。これらの要件は非常に控えめで、将来的に新しい要件を簡単に実装できる可能性があり（予測は困難です）、他のデータベース（JDBC、JPA）と互換性があります。

しかし、はい、多少のオーバーヘッドがありますが、通常、ハードウェアはプロジェクトの後半でアーキテクチャを変更するよりも安価で、CPUサイクルはもはや高価なリソースではありません（Raspberry Pi、スマートフォンなどを考えてください）。

0
JohannesB

あなたの質問とMark Bramniksに対するコメントから、私はこれを理解しました：

  • CPUの制約：CPUが非常に遅いため、CPUを集中的に使用しないでください
  • メモリの制約：すべてのデータがメモリに存在できるわけではありません
  • ディスクの制約：非常に遅いディスク、ソリューションはディスクから大量のデータを読み書きしないでください

これらは非常に厳しい制約です。通常、CPU対メモリまたはメモリ対ディスクを「取引」します。あなたの場合、これらはすべて制約です。 ehCacheを見たとおっしゃいましたが、このソリューション（およびおそらくmemcachedなどの他のソリューション）はH2よりも軽量ではないと思います。

あなたが試すことができる1つの解決策は、MappedByteBufferです。このクラスにより、ファイルの一部をメモリに置くことが可能になり、必要に応じてそれらの部分がスワップされます。しかし、これには代償が伴います。飼いならすのは簡単なことではありません。必要なデータを見つけるには、独自のアルゴリズムを作成する必要があります。より大きなマシンの追加コストに対して、それが機能するまでにかかる時間を考慮してください。時には、より良いハードウェアがソリューションです。

0
Wouter Oet

役立ついくつかのアイデア

  1. 単一のCPUで実行していて、H2への置換を確認したいとします。したがって、H2は多くのCPUパワーを「消費」し、アプリケーションは「遅い」と主張されています。しかし、CPUではなくディスクが遅いことが原因であるとしたら、結局のところ、データベースはデータをディスクに格納し、ディスクが遅くなる可能性があります。この理論を確認したい場合-ディスクをRAMでバックアップされたドライブにマップし（Linuxでは簡単な作業です）、同じCPUで再度測定します。

  2. 実際にH2はユースケースでCPUを集中的に使用していると結論付けた場合、クエリを最適化するために時間を費やす価値があるかもしれませんが、これはデータベースを置き換えるよりもはるかに安価です。

  3. さて、H2を使い続けることができない場合は、この「追加のみ」のユースケースに本当に最適化されているLuceneを検討してください（「後でデータを取得するので、「追加のみ」のフローがあることを理解しています。データを更新する必要はありません。Luceneにはインデックス作成を処理する独自のスレッドも必要であるため、とにかくCPUオーバーヘッドが予想されます。ただし、この使用例ではLuceneが高速になる可能性があります。価格はluceneはリレーショナルモデルを実装していないため（おそらく、部分的には高速である必要があるため）、「簡単な」クエリを取得できません。特に、JOINとトランザクション管理がありません。 RDMBSのように単一のテーブルから条件を取得する場合、説明のとおり「上位ヒット」を取得する必要はありません。

0
Mark Bramnik