hazelcastとehcache
タイトルにあるように質問は明確です。adv。/ disadvについてのアイデアを聞いていただければ幸いです。それらの違い。
PDATE： Hazelcastを使用することに決めました。これは、分散キャッシング/ロックメカニズムなどの利点と、アプリケーションに適応する際の設定が非常に簡単だからです。
最大のオンライン広告および電子商取引プラットフォームの1つで、両方を試しました。 ehcache/terracotta（サーバーアレイ）から始めました。これはよく知られ、Terracottaに支えられており、hazelcastよりも大きなコミュニティサポートがあります。
実稼働環境（1ノードクラスターを超えて分散）で状況が変化したとき、バックエンドアーキテクチャが非常に高価になったため、hazelcastにチャンスを与えることにしました。
Hazelcastは非常にシンプルで、言うことを実行し、設定のオーバーヘッドなしで非常にうまく機能します。
キャッシングレイヤーは1年以上にわたってhazelcastの上にありますが、非常に満足しています。
EhcacheはJavaシステムで人気がありますが、他のキャッシングソリューションよりも柔軟性が低いと感じています。Hazelcastをいじくりまわしました。 EhcacheはHazelcastよりもはるかに多くの機能を備えており、より成熟しており、その背後に大きなサポートがあります。
他にもいくつかの優れたキャッシュソリューションがあり、古き良きMemcache、Membase（現在のCouchBase）、Redis、AppFabricなどのすべての異なるプロパティとソリューション、永続性の有無にかかわらずキーバリューストアを提供するいくつかのNoSQLソリューションもあります。それらはすべて、CAP定理、またはトランザクションとともにBASE定理を実装するという意味で、異なる特性を持っています。
アプリケーションで必要な機能を持っているものについてさらに注意する必要があります。再び、アプリケーションのCAP定理またはBASE定理を検討する必要があります。
この test は、Netflixによってクラウド上で Cassandra を使用してごく最近行われました。約300のインスタンスで 毎秒100万回の書き込み に達しました。 Cassandraはメモリキャッシュではありませんが、データモデルはキーと値のペアで構成されるキャッシュのようなものです。分散メモリキャッシュとして Cassandra を使用することもできます。
Hazelcastはスケーリングするのが悪夢であり、安定性は依然として大きな問題です。
グリッドコンポーネントの専用クライアントは次のとおりです。
- どこでもノードの損失に耐えられず、バックアップのポイントを無効にする乱雑なバージョン（スーパークライアント）、または
- グリッド内の処理ノードへの負荷分散を一切許可しない、非常に遅いネイティブクライアントオプション。
ホストがこのデータグリッドからレコードを要求できる場合、それは甘いデザインになりますが、そこから何かを取り出すためのこれらの2つの不十分なオプションに固執しています。
また、データベーススレッドプールが個々のメンバーでロックされ、データベースに何も書き込まず、永続的なレコードの損失を引き起こすという複数の問題は頻繁に発生する問題であり、JVMのいずれかを更新するために何時間も停止する必要があります。スプリットブレインも依然として問題ですが、1.9.6では少し落ち着いたようです。
これをバンドエイドとして使用する代わりに、Ehcacheに移行するために集結し、データベース層を改善します。
Hazelcastは私にとって悪夢でした。クラスタ化されたWebsphere環境で「動作」させることができました。 「作業」という用語は大まかに使用します。まず、Hazelcastのすべてのドキュメントは古く、廃止されたメソッド呼び出しを使用した例を示しています。 Javadocsでコメントなしでドキュメントに新しい例を使用しようとするのは非常に困難です。また、J2EEコンテナーコードは、WebsphereでXAトランザクションをサポートしていないため、この時点では機能しません。 J2EEの唯一の例に明示的に続くコードを呼び出すと、エラーがスローされます（Milestone 3.0がこの問題に対処しているようです）。 HazelcastをJ2EEトランザクションに参加させることを忘れなければなりませんでした。 HazelcastはEJB/Non-J2EE以外のコンテナ環境に確実に適合しているようです。 Hazelcast.getAllInstances（）を呼び出すと、あるエンタープライズから別のエンタープライズに切り替えたときに、Hazelcastの状態に関する情報を保持できません。Java Beanを使用します。データにアクセスすると、同じJVMで多くのHazelcastインスタンスが起動します。また、Hazelcastからのデータの取得は高速ではありません。NativeClientを使用して、クラスターのメンバーとして直接使用してデータを取得しようとしました。リストには、Hazelcastに625個のオブジェクトしか含まれていません。リストに対して直接クエリを実行できず、その機能にアクセスするためだけにマップを保存したくありませんでした（SQL操作はマップ上で実行できます）。 Hazelcastはリスト（デルタ）（変更内容）だけを渡すのではなく、リスト全体をシリアル化してネットワーク経由で送信するため、625個のオブジェクトの各リストを取得するのに0.5秒かかります。サーバーのアドレスクラスターになりたかった。デフォルトのマルチキャスト設定は機能せず、グーグルでのグループディスカッションから、他の人々も同様にこの問題を経験しています。総括する;最終的には、8時間の過酷なプログラムによる構成と試行錯誤を経てクラスター内で8台のマシンが通信するようになりました（ドキュメントはほとんど役に立たないでしょう）が、それを行ったとき、それぞれに作成されるインスタンスとパーティションの数を制御できませんでしたJVMは、EJB/J2EE用のHazelcastの半分の性質のため、非常に低速でした。私が取り組んでいる失業保険アプリケーションに実際のユースケースを実装しましたが、データベースへの直接呼び出しを行うコードははるかに高速でした。私がやろうとしていることを実装するために別個のサービスを本当に使いたくなかったので、Hazelcastが宣伝どおりに機能していたら、クールだっただろう。 MongoDBを広範囲に使用しているため、メモリキャッシュ全体をスキップして、オブジェクトを別のリポジトリ内のドキュメントとしてシリアル化するだけです。
Hazelcastはノード（標準1）があるたびにすべてをシリアル化するため、Hazelcastに保存するデータはシリアル化を実装する必要があります。
Ehcacheの利点の1つは、大規模なパフォーマンスラボで広範なパフォーマンス、フェールオーバー、およびプラットフォームテストを行う企業（Terracotta）によって支援されていることです。 Terracottaはサポート、補償などを提供します。多くの企業にとって、そのようなことは重要です。
私はHazelcastを使用したことはありませんが、使いやすく、機能すると聞いています。 Hazelcast対Terracotta/Ehcacheのスケーラビリティやパフォーマンスに関して聞いたことはありませんが、Terracottaが行うスケーラビリティとフェールオーバーテストの量を考えると、Hazelcastが実稼働展開で競争力があると想像するのは困難です。しかし、私はそれが小規模な使用のためにうまくいくと思います。
[バイアス：私はテラコッタの元従業員です。]