Hazelcast分散データグリッドと実行製品の実務経験はありますか？どのようにあなたのために働いていますか？このようなシンプルなAPIと機能は、このようなシンプルなツールでは本当にうまくいくと思われます。私は非常にシンプルなアプリケーションをいくつかやっており、これまでのところ広告されているように動作するようです。だから私は現実世界の現実のチェックを探しています。ありがとうございました。RealWorld HazelCast
は一般的に、あなたがいずれかを選択します。それは、独自のマルチキャストアルゴリズムを使用するか、独自のIPのを指定させることができ、その開発にいくつかの問題はまだ、まだ
http://code.google.com/p/hazelcast/issues/list
があります。私たちはLAN環境で試してみましたが、うまくいきます。パフォーマンスはそれほど悪くはないが、ほとんどの場合更新に失敗したため、監視ツールはうまく機能しませんでした。あなたが現在の問題と一緒に暮らすことができれば、すべての手段によってそれが実現します。私は慎重にそれを使用しますが、それは素晴らしい作業ツールIMHOです。
更新： 私たちは数ヶ月間Hazelcastを使用してきましたが、うまくいきました。設定は比較的簡単に設定でき、新しい更新では読み取り/書き込み操作で許可されるスレッドの数などの小さなものをカスタマイズするのにも十分に包括的です。
ヘイズキャストの代替手段がある場合は、最初にこれらを見てください。私たちは生産モードで稼動していますが、それはまだかなりバギーです。未解決の問題をチェックしてください。 しかし、Spring、Hibernateなどとの統合はかなりいいですし、セットアップは本当に簡単です:)
バージョン1.8以降では、主に分散ロック機能を使用していました。素晴らしいことですが、いくつかの回避策やバグが見つかりましたが、比較的速く修正されています。
1日あたりのロック数は1.8Mで、これまでのところ問題はありませんでした。
バージョン1.9.4.4からの使用をお勧めします。
複雑なトランザクションサービスと統合された本番では、Hazelcast（1.9.4.6現在）を使用しています。データベースの即時処理の問題を軽減するために追加されました。私たちは、頻繁にすべてのトランザクションサービスを少なくとも1時間は停止する必要があることを発見しました。残念ながら、スーパークライアントノードを停止すると、スプリットブレインの問題が発生し、グリッドがレコードを失い、完全に強制的に強制的に実行されるため、スーパークライアントモードでクライアントを実行しています（これは、ネイティブクライアントより約4倍高速です）。サービスのシャットダウン。私たちは、この製品をほぼ一年間私たちのために働かせようと努力してきました。そして、2人のヘイルキャストの代理人が手伝ってもらうために支払ったことさえあります。彼らは解決策を作り出すことができませんでしたが、おそらくそれが間違っていると私たちに知らせることができました。彼らの意見では、それはうまくいくはずですが、かなり無駄な旅行でした。
この時点では、ライセンス料で年間6フィートを超えることがあります。現在、グリッドを維持し、パフォーマンス要件を満たすために、約5倍のリソースを使用しています。最適化されたデータベーススタック。これは絶対に間違った決断でした。
この商品は私たちを殺しています。慎重に、控えめに、そして単純なサービスのためだけに使用してください。
自分の会社とプロジェクトが現実世界とみなされる場合は、ここに私の経験があります。無限で永続的な「RAM」に賛成して外部（ディスク）ストレージを排除することに近づきたいと思っていました。 CRUD配管を排除して、いわゆる「中間層」の90％を占めることがあります。他にも利点があります。RAMはあなたの "データベース"なので、複雑なキャッシュやHTTPセッションの複製は必要ありません（これは、厄介なスティッキセッションテクニックを排除します）。
私はRAMが未来であり、Hazelcastはメモリ内のデータベース（クエリ、トランザクションなど）をすべて持っていると思うので、私はミニフレームワークを抽象化して書いています：永続ストレージからデータをロードするBLOBを格納することができます。最も速いのはMySQLです）。なぜ、私がHazelcastの組み込み永続性サポートが気に入らなかったのかを説明するのは長すぎます。むしろ一般的で初歩的なものです。彼らはそれを削除する必要があります。独自の分散型および最適化されたwrite-behindとwrite-throughを実装することは、ロケット科学ではありません。私は一週間を過ごしました。
パフォーマンステストを開始するまでは問題ありませんでした。インデックス、ポータブルシリアル化、明示的コンパレータなどのすべての最適化を行った後、クエリは遅くなります。インデックス付きフィールドの単純な「より大きい」クエリは、60Kの1Kレコード（マップエントリ）のセットで30秒かかります。私はHazelcastチームができること全てをやったと信じています。私が言うことは嫌いですが、Javaコレクションは、超最適化されたC++コードの通常のデータベース使用と比べてもまだ遅いです。それに対処するいくつかのオープンソースのJavaプロジェクトがあります。しかし、この時点では、クエリの永続性は受け入れられません。単一のローカルインスタンスで即座に実行する必要があります。結局、メモリ内の技術です。
私はデータベースのためにMongoに切り替えましたが、Hazelcastは共有ランタイムデータ、つまりセッション用に残しました。クエリのパフォーマンスが向上したら、私は元に戻します。
Ignite（http://apacheignite.readme.io/docs/overview）を評価しています。それはヘーゼルキャストと同じ特徴を持っています - 少なくとも私が必要とするもの。私はあなたに1週間で知らせます。 –
*インデックス付きフィールドの単純な「より大きい」クエリでは、60Kの1Kレコード（マップエントリ）のセットで30秒かかる*このデータは非常に非現実的に間違っているため、適切なパフォーマンス解析中にフラグを立てる必要があります。それはとても恐ろしいように見えます。私は "なぜそんなに多くの人がそれを使うのですか？" /ミリ秒のレイテンシと1秒あたりの100kのインサートを議論しているネット上でのパフォーマンステストはなぜそんなに多くなっていますか？」最後に、私自身のテストの妥当性について質問し始めました。 –
当社のeコマースアプリケーションでHazelcastを使用して、在庫が一貫していることを確認します。
私たちは、SKUの在庫アイテムが原子的な方法で変更されていることを確認するために分散ロックを広範囲に使用しています。
また、すべてのノードで共有されるキャッシュ目的の分散マップも使用します。 Hazelcastのスケーリングノードは非常にシンプルで、すべてのCPUコアを使用するため、Redisや他のキャッシングフレームワークよりも利点があります。
可用性（供給&の要求）が一貫しており、アトミックであり、利用可能であることを確認するために、電子商取引アプリケーションで過去3年間のHazelcastを使用しています。&スケーラブル。 IMap（分散マップ）を使用してデータをキャッシュし、入力プロセッサーを&の読み取り操作で実行し、ロックを心配することなくIMap上で高速なメモリー内操作を実行します。
解決しましたか？問題を特定したり、別のテクノロジに移行したりしましたか？あなたが言及したライセンス料は何ですか？ azelcastのコアは無料です、と私は考えました。 –
古い（あなたは何を見ましたか）（http://qph.is.quoracdn.net/main-qimg-2776209b9d9d72eef92d0910e8c72e13）joke – Crowie
@james、この回答が長い時間前に与えられたとすれば、現在の状況はどうですか？ヘーゼルキャスト。新しいリリースで問題を解決できましたか、他のソリューションで作業しましたか？知っておもしろいですか？ – frewper