2

非常に複雑な Java EE アプリケーション (Java バックエンド + Spring HTTP Invoker を介して通信する GRails フロントエンド) には、大量の恐ろしいレガシー コードがあります。現在、Jboss で実行されます (後で Tomcat に移行されます)。

信頼性を高め、パフォーマンスを向上させるには、クラスタ化可能にする必要があります。

問題は、アプリケーションが現在、複製する必要があるビジネス全体に不可欠な多くの深いメモリ内構造を持っていることです (別の ConcurrentHashMap 内の ConcurrentHashMap 内の HashMap 内のリスト内のドメイン オブジェクトなど)。

私が言ったように、多くのレガシー コードがあり、すべてを作り直すことはできません。

現在、私は EHCache で遊んでいますが、明らかに成功していません。キャッシュされたオブジェクトの奥深くにある変更は複製されません。

Terracotta DSO は検討すべきもののように見えますが、これは究極の解決策であり、より一般的な方法で解決することを望んでいる間は、そのような急進的な解決策を導入したくありません。

4

1 に答える 1

1

実際、これはほとんどのキャッシング ソリューションの典型的な問題です。メモリ内の深い構造を扱うため、これに対処する簡単な方法はありません。

たとえば、エンタープライズ グリッド -ギガスペース- これがその方法ですhttp://www.gigaspaces.com/wiki/display/XAP8/Modeling+your+data

これは本当に周りのことを説明しています:

オブジェクトを埋め込む必要がある場合 関連するオブジェクトを埋め込むのは良い習慣ではないことは既にご存じでしょう。ただし、関連するオブジェクトを埋め込むのに適したケースがある場合でも (場合によってはデータの重複を犠牲にして)、次の点に注意する必要があります。

埋め込みとは、直接アクセスできないことを意味します。エンティティが別のエンティティ内に埋め込まれている場合、CRUD 操作を直接適用することはできません。代わりに、通常のクエリを介してスペースからルートの親エンティティを取得し、必要なエンティティを取得するまでオブジェクト グラフを下に移動する必要があります。これは単なる利便性の問題ではなく、パフォーマンスへの影響もあります。埋め込みエンティティに対して CRUD 操作を実行する場合は常に、最初にグラフ全体を読み取り、(更新も必要な場合) オブジェクト グラフ全体を書き戻します。スペースへ。一方、GigaSpaces の非埋め込み関係は、コード内で関係を自分で管理する必要があることを意味します。埋め込み関係を選択するための経験則 エンティティが、それを含むオブジェクトのコンテキストでのみ意味を持つ場合に埋め込みます。例えば、petclinic アプリケーションでは、ペットは所有者を持っている場合にのみ意味を持ちます。この特定のアプリケーションでは、ペット自体は所有者なしでは意味がありません。ペットを所有者から所有者に譲渡したり、所有者なしで獣医にペットを認めたりするためのビジネス シナリオはありません。埋め込みは、データの複製を意味する場合があります。たとえば、Pet クラスと Vet クラスの両方から特定の Visit を参照する場合は、Visit エントリを複製する必要があります。重複を見てみましょう: 重複とは、フットプリントよりもスケーラビリティを優先することを意味します。重複する理由は、クラスター全体のトランザクションを回避するためであり、多くの場合、オブジェクトをスケーラブルな方法で分割する唯一の方法です。複製は、より多くのメモリ消費を意味します: 現在、メモリはコモディティで低コストと見なされていますが、複製には大きな代償が伴います。同じデータを含む 2 つのスペース オブジェクトが存在する可能性があります。複製とは、より寛大な一貫性を意味します。たとえば、ペットと獣医に訪問を追加する場合、両方を更新する必要があります。1 つの (潜在的に分散された) トランザクションで行うことも、2 つの別個のトランザクションで行うこともできます。これは多くのタイプのアプリケーション (例: ソーシャル ネットワーク) では十分かもしれません。投稿を失ったとしても、それは望ましくありませんが、重大な損害は発生しません。対照的に、これは、すべての操作を説明する必要がある金融アプリケーションには適していません。1 つの (潜在的に分散された) トランザクションで行うことも、2 つの別個のトランザクションで行うこともできます。これは多くのタイプのアプリケーション (例: ソーシャル ネットワーク) では十分かもしれません。投稿を失ったとしても、それは望ましくありませんが、重大な損害は発生しません。対照的に、これは、すべての操作を説明する必要がある金融アプリケーションには適していません。1 つの (潜在的に分散された) トランザクションで行うことも、2 つの別個のトランザクションで行うこともできます。これは多くのタイプのアプリケーション (例: ソーシャル ネットワーク) では十分かもしれません。投稿を失ったとしても、それは望ましくありませんが、重大な損害は発生しません。対照的に、これは、すべての操作を説明する必要がある金融アプリケーションには適していません。

hazelcastには、ギガスペースとは異なるデータ アフィニティhttp://www.hazelcast.com/docs/1.9.4/manual/multi_html/ch03.htmlの概念があります。

つまり、単純な解決策はなく、とにかくモデルを再設計する必要があると思います (これがコヒーレンス、ギガスペース、ehcache、hazelcast であるかどうかは関係ありません)。

于 2012-07-27T11:20:56.393 に答える