Terracotta を持続性ソリューション (データベースの代わり) として使用するのは良い考えでしょうか? 特に、データの整合性の問題とトランザクション システムのサポートについて疑問に思っています。
2 に答える
Terracotta はトランザクション(変更されたオブジェクトのトランザクションから同期されたブロック) ですが、JTA に準拠しておらず、準拠する必要もありません。ここでは、トランザクションについてかなり長い説明と、Terracotta に関するよくある誤解について説明します。
私は、データの有効期間と、Terracotta を使用する機会を特定する際の考え方をどのように組み立てるべきかについてのブログ記事を書きました。要するに、Terracotta のスイート スポットは、永続性と可用性が必要な場合 (アプリがクラッシュする可能性があってもデータは必要) であるが、データが長期的に必ずしも重要ではない場合のユース ケースです。
標準的な例は、ショッピング カートの情報など、Web アプリのユーザー セッションのコンテキストで重要なデータです。Web アプリがクラッシュした場合でもショッピング カートを維持できるように、そのデータを永続的に保持する必要があります。しかし、カート自体は購入される場合とされない場合があります。したがって、購入するまで Terracotta に保管し、「記録システム」データとしてデータベースに保存します。
歴史的に、データベースに格納されたデータは常に、ビジネスの長期的な成功に不可欠な「記録システム」データ (顧客、注文など) でした。今日の「ステートレス」アーキテクチャ (実際にはステートレスではない) では、すべての中期データをデータベースに押し込みます。これは、データベース (追加の作業とストレージ) と開発者 (ORM を使用している場合でも、オブジェクト リレーショナル インピーダンスの不一致を処理する必要がある) を不必要に罰していることを意味します。より良いアプローチは、それをオブジェクトに残し、Terracotta でクラスター化することです。最近の多くの Terracotta ユーザーは、この手法を使用してデータベースのフットプリントを大幅に削減し (数百万ドルを節約)、同時にスケーリング能力を高めています。
データベースとの統合ポイントと、ハンドオフを確実に行う方法の問題があります。これは、最近リリースされたExaminator (Spring / Terracotta / Tomcat / MySql リファレンス Web アプリケーション) のユース ケースとして見られました。試験が進行中の場合、状態 (質問への回答、無作為化された選択肢の順序、レビュー用にマークされた質問) が Terracotta に保存されます。ただし、試験が完了すると、結果のスコアが計算され、データベースに長期保存されます。
これを安全に行うために、最初に Terracotta のオブジェクトでデータベースの行 ID を生成し、次にデータをデータベースに保存し、次に Terracotta から削除する Hibernate キー戦略を使用します。このシナリオでは、データベースに保存した後、Terracotta から削除する前にアプリがクラッシュした場合、競合状態になる可能性があります。その場合、アプリケーションはデータを db に再保存しようとし、2 つの行を作成する可能性があります。ただし、事前に生成された ID により、行が以前に正常に書き込まれたかどうかを判断し、その問題を回避できます。
要約すると、Terracotta がすぐにデータベースを置き換えるとは思いません。ほとんどのショップでそのように見なされるには、操作が新しすぎる. 使用モデルは大きく異なります。ヒープに対するクエリまたは SQL 機能はありません (クエリ機能はオブジェクト モデルによって定義されます)。私はそれが可能であり、はるかに安価で簡単な代替手段である中期的なデータ使用に取って代わり始めていると考えています. しかし、長期保存のために実験を始めている人もいます。
Terracotta は Java のみです。他の言語で (JVM を使用せずに) いくつかのスクリプトを作成する可能性がなくても、このテクノロジに縛られても問題ない場合は、それを使用してください。
Terracotta でデータベースを削除するという記事は本当に良かったです。