63

タイトルからもわかるように質問は明確ですが、賛否両論についてあなたの考えを聞かせていただければ幸いです。それらの違い。

更新: 分散キャッシュ/ロック メカニズムなどの利点と、アプリケーションに適応させる際の構成が非常に簡単なため、Hazelcast を使用することにしました。

4

7 に答える 7

93

最大のオンライン広告および e コマース プラットフォームの 1 つで、両方を試してみました。私たちは ehcache/terracotta (サーバー アレイ) から始めました。これはよく知られており、Terracotta に支えられており、hazelcast よりも大きなコミュニティ サポートを持っています。
実稼働環境 (分散型、1 ノード クラスターを超えた) でそれを取得すると、状況が変わり、バックエンド アーキテクチャが非常に高価になったため、hazelcast にチャンスを与えることにしました。

Hazelcast は非常にシンプルで、設定のオーバーヘッドがなくても、そのとおりに動作し、非常に優れたパフォーマンスを発揮します。

私たちのキャッシング レイヤーは 1 年以上 hazelcast の上にあり、非常に満足しています。

于 2011-03-11T09:59:19.840 に答える
19

Ehcache は Java システムの間で人気がありますが、他のキャッシング ソリューションよりも柔軟性が低いと思います。私はHazelcastで遊んでみましたが、はい、それは仕事をしました。実行するのは簡単でした.Ehcacheよりも新しいです. Ehcache は Hazelcast よりもはるかに多くの機能を備えており、より成熟しており、大きな支持を得ていると言えます。

古き良き Memcache、Membase (現在の CouchBase)、Redis、AppFabric、永続性の有無にかかわらずキー値ストアを提供するいくつかの NoSQL ソリューションなど、すべての異なるプロパティとソリューションを備えた、他にもいくつかの優れたキャッシュ ソリューションがあります。それらはすべて、CAP定理、またはトランザクションとともにBASE定理を実装するという意味で、異なる特性を持っています。

どちらがアプリケーションに必要な機能を持っているかをもっと気にする必要があります。繰り返しますが、アプリケーションのCAP定理またはBASE定理を検討する必要があります。

このテストは、ごく最近、Netflix によってクラウド上のCassandraで行われました。約 300 のインスタンスで、毎秒 100 万回の書き込みに達しました。Cassandra はメモリ キャッシュではありませんが、データ モデルはキャッシュのようなもので、キーと値のペアで構成されています。Cassandraを分散メモリ キャッシュとして使用することもできます。

于 2011-11-04T18:50:20.157 に答える
12

Hazelcast はスケールするのに悪夢であり、安定性は依然として大きな問題です。

専用クライアントからグリッド コンポーネントの選択肢は次のとおりです。

  1. どこでもノードの損失を乗り切ることができず、バックアップのポイントを無効にする厄介なバージョン (スーパークライアント)、または
  2. グリッド内の処理ノードへのいかなるタイプの負荷分散も許可しない、非常に遅いネイティブ クライアント オプション。

任意のホストがこのデータ グリッドからレコードを要求できる場合、それは素晴らしい設計ですが、そこから何かを取得するためのこれら 2 つの精彩を欠いたオプションに行き詰まっています。

また、データベース スレッド プールが個々のメンバーをロックし、データベースに何も書き込まないという複数の問題があり、永続的なレコードの損失が頻繁に発生する問題であり、JVM のいずれかを更新するために何時間も全体を停止する必要があることがよくあります。スプリット ブレインもまだ問題ですが、1.9.6 では少し落ち着いたようです。

これを応急処置として使用する代わりに、Ehcache に移行し、データベース層を改善するために結集します。

于 2012-02-24T00:29:26.493 に答える
7

Hazelcast は、ノード (標準ノード) がある場合は常にすべてをシリアル化するため、Hazelcast に保存するデータはシリアル化を実装する必要があります。

http://open.bekk.no/effective-java-serialization/

于 2012-05-30T06:43:46.953 に答える
6

Hazelcast は私にとって悪夢でした。クラスター化されたWebsphere環境で「動作」させることができました。私は「働く」という言葉を大雑把に使っています。まず、Hazelcast のドキュメントはすべて古く、非推奨のメソッド呼び出しを使用した例のみを示しています。Javadocs のコメントなしで、ドキュメントの例なしで新しいコードを使用しようとするのは非常に困難です。また、J2EE コンテナー コードは、Websphere で XA トランザクションをサポートしていないため、現時点では機能しません。唯一の J2EE の例に明示的に従うコードを呼び出すと、エラーがスローされます (Milestone 3.0 がこれに対処しているように見えます)。Hazelcast を J2EE トランザクションに参加させることを忘れなければなりませんでした。Hazelcast は、明らかに非 EJB/非 J2EE コンテナー環境に対応しているようです。Hazelcast に電話をかけます。getAllInstances() は、あるエンタープライズ Java Bean から別のエンタープライズ Java Bean に切り替えるときに、Hazelcast の状態に関する情報を保持できません。そのため、データへのアクセスを許可する呼び出しを実行するためだけに、新しい Hazelcast インスタンスを作成する必要があります。これにより、多くの Hazelcast インスタンスが同じ JVM で起動します。また、Hazelcast からのデータの取得は高速ではありません。Native Client と直接クラスターのメンバーの両方を使用してデータを取得しようとしました。Hazelcast に 625 個のオブジェクトのみを含む 51 個のリストを保存しました。リストに対して直接クエリを実行することはできず、その機能にアクセスするためだけにマップを保存したくありませんでした (マップに対して SQL 操作を実行できます)。625 個のオブジェクトの各リストを取得するのに約 0.5 秒かかりました。これは、Hazelcast が単にデルタ (何が変更されたか) を提供するのではなく、リスト全体をシリアル化してネットワーク経由で送信するためです。もう 1 つのことは、TCPIP 構成に切り替えて、クラスターに入れたいサーバーの IP アドレスを明示的にリストする必要があったことです。デフォルトのマルチキャスト構成は機能せず、Google でのグループ ディスカッションから、他の人々も同様の問題を経験しています。総括する; 最終的に、何時間にもわたるプログラムによる構成と試行錯誤を経て、クラスター内で 8 台のマシンが通信するようになりました (ドキュメントはほとんど役に立ちません)。EJB/J2EE 用の Hazelcast は完成度が低く、非常に遅かったため、各 JVM で作成されるインスタンスとパーティションの数を制御することはできませんでした。私が取り組んでいる失業保険アプリケーションで実際の使用例を実装したところ、データベースへの直接呼び出しを行うコードの方がはるかに高速でした。私がやろうとしていることを実装するために別のサービスを使用したくなかったので、Hazelcast が宣伝どおりに機能していれば素晴らしいことでした。私はMongoDBを広範囲に使用しているため、メモリキャッシュ全体をスキップして、オブジェクトを別のリポジトリのドキュメントとしてシリアル化するだけです。私がやろうとしていることを実装するために別のサービスを使用したくなかったので、Hazelcast が宣伝どおりに機能していれば素晴らしいことでした。私はMongoDBを広範囲に使用しているため、メモリキャッシュ全体をスキップして、オブジェクトを別のリポジトリのドキュメントとしてシリアル化するだけです。私がやろうとしていることを実装するために別のサービスを使用したくなかったので、Hazelcast が宣伝どおりに機能していれば素晴らしいことでした。私はMongoDBを広範囲に使用しているため、メモリキャッシュ全体をスキップして、オブジェクトを別のリポジトリのドキュメントとしてシリアル化するだけです。

于 2012-10-24T15:16:23.990 に答える
4

Ehcache の利点の 1 つは、大規模なパフォーマンス ラボで広範なパフォーマンス、フェイルオーバー、およびプラットフォームのテストを行う会社 (Terracotta) によってサポートされていることです。兵馬俑はサポート、補償などを提供します。多くの企業にとって、そのようなことは重要です。

私は Hazelcast を使用したことがありませんが、使いやすく、機能すると聞いています。Hazelcast と Terracotta/Ehcache のスケーラビリティまたはパフォーマンスに関しては何も聞いていませんが、Terracotta が行うスケーラビリティとフェイルオーバーのテストの量を考えると、Hazelcast が本番環境で競争力があるとは想像しがたいです。しかし、私はそれがより小さな用途にはうまくいくと思います.

【偏見:兵馬俑の元社員です】

于 2011-03-09T14:51:37.280 に答える