7

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

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

また、ローカル データベースへのレプリケーションを含む他の戦略も検討したいと考えています。これを実装するために、自分で面倒な作業をしすぎる必要はありません。

いくつかの経験または可能な代替手段を探しています。

4

6 に答える 6

3

「さらに、アプリケーションを正常にシャットダウンしない電力損失が発生する可能性があるため、どのソリューションにも、電源の再投入に耐えられる永続的なキャッシュが必要です。」

Hibernate レベル 2 キャッシュを使用した解決策は既に頭に浮かんでいます。しかし、あなたは本当の要件が何であるかを言いませんでした。あなたは現実的でないネットワークを持っています。大丈夫です、あなたは現実的でない電源を持っています。それもOKです。では、どのレベルのサービスを達成したいですか? 許容できるものとできないものは何ですか?

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

より明確にするために、データベースのローカル レプリカまたは少なくともその一部があるとします。ローカルで行われた変更をキュー/保存する方法を知っているとしましょう。電源障害の場合に備えて、これらの変更をハードドライブに保存するとします。接続が再び利用可能になったときに、変更をメイン データベースにマージできるとします。

それはすでに多くの仮定です。わかりましたが、停電後に 1 台のハードドライブに障害が発生した場合はどうなりますか? ハードドライブは電源障害を嫌い、電源障害で破損する傾向があり、さらには破損する可能性があることをご存知ですか?

そこで、RAID を構成し、無停電電源装置を追加します。それはすばらしい。OS から電源障害イベントを検出します。現在のトランザクションを終了し、正しくシャットダウンします。RAID は、ディスク障害からユーザーを保護します。

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

Wi-Fi がオンになっている場合でも、電源は完全に機能します... 中央データベースの信頼性はどうですか? 定期的なバックアップはありますか? またはクラスタリング ソリューションですか。とにかく、中央データベースは信頼できますか?

データベースの観点からは、クラスタまたはバックアップを使用し、トランザクションを使用してデータの一貫性を確保するのは簡単です。データを失う可能性はありますが (特にクラスターを使用していない場合)、たとえば最後のバックアップまで回復できるはずです。

ただし、オフラインで (データベースを使用できない状態で) 作業したい場合、データベースを変更できるのは自分だけではない場合、競合が発生します。これは、キャッシュ、休止状態、その他の技術的な問題ではなくなりました。

これは機能上の問題です。いくつかの変更がオフラインで発生し、マージする必要がある場合はどうすればよいですか? 許容できるものは何ですか? そうではないもの。これは、再接続時に最新の変更が適用され、古い変更が破棄される可能性があります。または、潜在的な競合が検出され、ユーザーに対処するよう促します。キューに入れられた変更を適用して、それらすべてを適用することができます...

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

于 2011-05-09T00:20:34.043 に答える
2

How about queuing up db operations on a durable/persistent message queue, and let some messaging middleware handle the network problem?

Depending on how you do it, consistency problems (well, "anomaly" is the right word I guess) can arise, but if you have unreliable network and still want decent performance, then settling for relaxed consistency could be the way to go.

I would be hesitant to use EhCache etc. They were not designed for this and hence you might have to "stretch" the framework. Message queues on the other hand have solutions that were designed for such scenarios.

于 2011-05-01T01:23:08.893 に答える
2

休止状態とデータベースの間のようなネットワークで成功することは期待できません。

高レベルのアトミック操作のセットを定義してから、(たとえば) 一連の安らかなサービスを定義することをお勧めします。または、必要に応じて、soap を使用して、再試行やその他すべての厄介な詳細を処理する信頼できるメッセージングの WS-* オプションを調べることができます。

または、リンクを介した cassandra のようなものが SQL よりもうまく機能するかどうか、またはレプリケーションで重要な何かがあるかどうかを調べることができます。

于 2011-04-30T23:18:24.250 に答える
1

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

ただし、トランザクション ログを圧縮して保存することはできます。

于 2011-05-01T00:34:45.187 に答える
1

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

ちなみに、Hibernate は組み込み環境にダンプするには少し太ります。代わりに myBatis を検討することをお勧めします。

于 2011-05-11T17:11:29.263 に答える
0

Daffodil Replicator (http://enterprise.replicator.daffodilsw.com/index.html) は、JDBC ソース間の複製を可能にします。双方向の更新、マージ、競合の解決、および部分レプリカをサポートしています。

これは、メイン データベースをローカル (部分) レプリカと同期するために使用できます。休止状態を使用してローカル レプリカ データベースと通信し、他のすべてをそのプロセスの外で行うことができます。

于 2011-05-15T17:00:06.293 に答える