信頼性の低いネットワークと低帯域幅を使用する Java ORM の戦略

Question

信頼性の低いネットワークで動作する必要があるシステムのために Hibernate を検討しています。読み取り/書き込みアクセスが必要な中央データベースが 1 つありますが、かなり斑点のある Wi-Fi ネットワーク経由で利用できます。さらに、電力損失が発生してアプリケーションが正常にシャットダウンされない可能性があるため、どのソリューションにも電源の再投入に耐えられる永続的なキャッシュが必要です。最後に、これは適度なメモリとディスク容量しか持たない組み込みシステムであるため、たとえばデータベースの本格的なレプリケーションを実行することは実現可能な戦略ではありません。

私は Hibernate 2nd Level キャッシュの基本を理解しています。この問題を解決するために Ehcache のようなものを使用してこれを構成できるかどうか疑問に思っていますが、その主な目的は可用性ではなくパフォーマンスであるようです。どのような落とし穴があるのか​​。

また、ローカル データベースへのレプリケーションを含む他の戦略も検討するつもりです。これを実装するために、自分であまり重労働をする必要はありません。

経験や代替案を探しています。

Answer 1

Daffodil Replicator（http://enterprise.replicator.daffodilsw.com/index.html）は、JDBCソース間の複製を許可します。双方向の更新、マージと競合の解決と部分的なレプリカをサポートします。

これを使用して、メインデータベースをローカル（部分的な）レプリカと同期させることができます。 Hibernateを使用して、ローカルレプリカデータベースと通信し、そのプロセス以外で他のすべてを実行できます。

Answer 2

「さらに、アプリケーションをきれいにシャットダウンしない電力損失がある可能性があるため、ソリューションにはパワーサイクルに耐えることができる永続的なキャッシュが必要です。」

冬眠レベル2キャッシュを使用して、すでに心に解決策があります。しかし、あなたは本当の要件とは何かを言っていませんでした。あなたは実現不可能なネットワークを持っています。それは大丈夫です、あなたは実現できない電源を持っています。それも大丈夫です。今、あなたはどのレベルのサービスを達成したいですか？何が受け入れられるかどうか？

データ損失は許容されますか？どれだけ受け入れることができますか？どのようなリスクを受け入れますか？

より明確にするために、データベースのローカルレプリカ、または少なくともその一部があるとしましょう。局所的に行われた変更/保存の方法を知っているとしましょう。停電の場合に安全になるように、これらの修正をハードドライブに保存してください。接続が再び確実になったときに、変更をメインデータベースとマージできるとしましょう。

それはすでに多くの仮定です。 OKでも、パワーフールの後に1つのハードドライブが失敗した場合はどうなりますか？ハードドライブは停電が好きではなく、停電時に破損する傾向があるか、損傷する可能性があることを知っていますか？

そのため、襲撃を行い、中断性のない電源を追加します。それはすばらしい。 OSからの停電イベントを検出します。現在のトランザクションを完了し、正しくシャットダウンします。あなたはディスクの障害からあなたを守ります。

わかりましたが、コンピューター全体が機能しなくなったらどうなりますか？火災の場合はどうなりますか？または水害？すべてのディスクが管理され、データが回復できず、中央データベースと同期されていないものが失われます。それは受け入れられますか？

WiFiがオンになっていても、電源は完全に機能します...とにかく中央データベースの信頼性は何ですか？通常のバックアップはありますか？またはクラスタリングソリューション？とにかくあなたの中央データベースが信頼できると確信していますか？

データベースの観点から見ると、クラスターまたはバックアップを使用してトランザクションを使用してデータコンジ率を確保することができます。データを失う可能性があります（特にクラスターを使用していない場合）が、Epempleの最後のバックアップまで回復できるはずです。

ただし、データベースを変更できる唯一のものではなく、オフラインで作業したい場合（データベースは使用できません）、競合が発生します。これは、キャッシュ、冬眠、または技術的な問題ではなくなりました。

これは機能的な問題です。いくつかの変更がオフラインで行われ、合併する必要がある場合はどうすればよいですか？何が受け入れられますか？そうではない。これは、再接続すると、最新の変更が適用され、古い変更が破棄される可能性があります。または、ptential競合が検出され、ユーザーがそれらに対処するように促します。キューに囲まれた変更を適用して、それらのすべてを適用しようとすることができます...

「オフラインモード」を提供できると考える傾向がありますが、ユーザーはオフラインであることに注意する必要があり、最終的な競合解決で中央データベースで変更が永久に変更されている場合は通知が必要です。しかし、それは私の視点です。

Answer 3

HibernateとDatabaseの間でそのようなネットワークで成功することを期待することはできません。

一連の高レベルの原子運転を定義し、それらのための一連の（例えば）安らかなサービスを定義することをお勧めします。または、必要に応じて、SOAPを使用して、信頼できるメッセージングのWS-*オプションを調べて、レトリと他のすべての乱雑な詳細を処理することができます。

または、リンク上のCassandraのようなものがSQLよりもうまく機能するのか、それとも複製で大きなものが機能するかを調査することができます。

Answer 4

耐久性のある/永続的なメッセージキューでDB操作をキューアップして、メッセージングミドルウェアにネットワークの問題を処理できるようにするのはどうですか？

どのように行うかによっては、一貫性の問題（まあ、「異常」が私が推測する正しい言葉です）が発生する可能性がありますが、信頼できないネットワークがあり、それでも適切なパフォーマンスが必要な場合は、リラックスした一貫性のために落ち着くことができます。

私はehcacheなどを使用することをためらうでしょう。それらはこれのために設計されていなかったため、フレームワークを「伸ばす」必要があるかもしれません。一方、メッセージキューには、そのようなシナリオ向けに設計されたソリューションがあります。

Answer 5

2 台のマシン間の接続が散発的に発生するだけの場合は、再生可能なトランザクション ログを保持し、各エントリに処理済みのマークを付けることをお勧めします。ただし、メモリが限られているため、それが難しい場合があります。

ただし、トランザクション ログを圧縮して保存できるかもしれません。

Answer 6

Hibernate（および第2レベルのキャッシュ）はです 本当 これのために設計されていません。私の推測では、おそらく、小規模な埋め込みJava RDBMS（H2またはHSQLDBなど）をローカルの一時キュー（利用可能な最も耐久性のあるモード）として使用してから、バックグラウンドスレッドと同期を実行するのが最善だと思います。その後、ユーザーにある程度のフィードバックを提供するために、その背景スレッドに接続された同期スピナーUIを提供できます。

ちなみに、冬眠は埋め込み環境に捨てるのに少し太っています。代わりにMyBatisを検討したいと思うかもしれません。