問題タブ [terracotta]

Java クラスタリング (つまり、HA ソリューションの実装) の経験について人々から聞きたいと思います。別名。Terracotta、JGroups など。Web アプリである必要はありません。カスタム スタンドアロン サーバーの作成経験も重要です。

更新:私はもう少し具体的になります-> Webアプリのクラスタリングにはあまり興味がありません(引き出してスタンドアロンで実行できる場合を除きます)。私はそれが機能することを知っています。しかし、セッション クラスタリング以上のものが必要です。プログラミングの容易さ、サポートされるトポロジ (つまり、単一のデータセンターと WAN 経由)、サポートされるノードの数の観点からソリューションを検討します。直面する問題、回避策。現時点では、Terracotta と JGroups で POC (概念実証) 作業を行って、アプリ (Web コンテナーの外部にあるスタンドアロン) に取り組む価値があるかどうかを確認しています。

私はこれに数日間取り組んできましたが、いくつかの解決策を見つけましたが、どれも信じられないほど単純でも軽量でもありませんでした。問題は基本的に次のとおりです。10 台のマシンのクラスターがあり、それぞれがマルチスレッド ESB プラットフォームで同じソフトウェアを実行しています。同じマシン上のスレッド間の同時実行の問題はかなり簡単に処理できますが、異なるマシン上の同じデータに対する同時実行の問題はどうでしょうか?

基本的に、ソフトウェアは Web サービスを介して顧客のデータをある企業から別の企業にフィードする要求を受け取ります。ただし、顧客が他のシステムに存在する場合もあれば、存在しない場合もあります。そうでない場合は、Web サービス メソッドを介して作成します。したがって、ある種のテスト アンド セットが必要ですが、他のマシンが競合状態を引き起こさないようにロックアウトするための何らかのセマフォが必要です。以前、1 人のローカル カスタマーに対してリモート カスタマーが 2 回作成されたという状況がありましたが、これはあまり望ましくありません。

私が概念的にいじった解決策は次のとおりです。

1. フォールト トレラントな共有ファイル システムを使用して、お客様に応じて各マシンでチェックされる「ロック」ファイルを作成します。

2. データベースで特別なテーブルを使用し、ロック レコードの「テストと設定」を行うためにテーブル全体をロックします。

3. スケーリングを支援するオープン ソース サーバー ソフトウェアである Terracotta を使用しますが、ハブ アンド スポーク モデルを使用します。

4. メモリ内の「ロック」の同期レプリケーションに EHCache を使用します。

この種の問題を経験したことがあるのが私だけだとは想像できません。どのように解決しましたか？社内で何か調理しましたか、それともお気に入りのサードパーティ製品はありますか?

現在 RAM に制限されているアプリケーションをスケールアップするために、Terracotta を評価しています。これは共同フィルターであり、ユーザーごとに約 2 キロバイトのデータを保存します。Amazon の EC2 を使用したいのですが、これは RAM が 14GB に制限されていることを意味します。これにより、約 700 万ユーザーというサーバーあたりの効果的な上限が得られます。これを超えてスケ​​ーリングできる必要があります。

これまでの私の読書に基づいて、Terracotta は各サーバーで使用可能な RAM よりも大きなクラスター化されたヒープを持つことができると考えています。各サーバーが 14GB しかサポートしていない場合に、30GB 以上の効果的なクラスター化ヒープを持つことは実行可能でしょうか?

ユーザーごとのデータ (大部分は float の配列) は非常に頻繁に変更され、1 分間に数十万回も変更される可能性があります。これらの変更のすべてが、発生した瞬間にクラスター内の他のノードに同期される必要はありません。一部のオブジェクト フィールドのみを定期的に同期することはできますか?

別のスレッドによって書き込みロックされているにもかかわらずオブジェクトの値を読み取ることを意味する「ダーティリード」は、 TerracottaのWebサイトに記載されていますが、可能性を気にしない場合でも、使用すべきではないと聞いています。ロックされたオブジェクトをダーティリードすると、古いデータが取得される可能性があります。

Terracottaでダーティリードを使用した経験のある人はいますか？古い値を読み取る可能性を気にしない場合は、安全に使用できますか？

エンタープライズ製品ではなく、Terracottaのオープンソース製品を使用した経験のある人はいますか？具体的には、クラスターを管理するためのエンタープライズツールなしでテラコッタを使用する価値があるかどうかに興味がありますか？

過度に単純化された使用法の概要：私たちは予算が限られている小さなスタートアップであり、数百万のレコードを処理し、1日あたり数十万のページビューに対応する必要があります。

Terracotta を持続性ソリューション (データベースの代わり) として使用するのは良い考えでしょうか? 特に、データの整合性の問題とトランザクション システムのサポートについて疑問に思っています。

I've been reading up on so-called "data grid" solutions for the Java platform including Terracotta, GigaSpaces and Coherence. I was wondering if anyone has real-world experience working any of these tools and could share their experience. I'm also really curious to know what scale of deployment people have worked with: are we talking 2-4 node clusters or have you worked with anything significantly larger than that?

I'm attracted to Terracotta because of its "drop in" support for Hibernate and Spring, both of which we use heavily. I also like the idea of how it decorates bytecode based on configuration and doesn't require you to program against a "grid API." I'm not aware of any advantages to tools which use the approach of an explicit API but would love to hear about them if they do in fact exist. :)

I've also spent time reading about memcached but am more interested in hearing feedback on these three specific solutions. I would be curious to hear how they measure up against memcached in the event someone has used both.

わかりません。つまり、そのようなことを信じないようにするトピックがいくつかあります。

たとえば、最新の安定版 (3.0.0-stable) には壊れた Eclipse プラグインがあり、まったく機能しません。さらに、リビジョン間のアップグレードを試みることは、まったく同じリビジョン番号ではないすべてのクライアントとすべてのサーバーに互換性がないため、非常に面倒です。

私はまだ完全なプロファイリングを行っていませんが、Terracotta はすぐに簡単なボトルネックになる可能性があるようです。

StackOverflow さん、どう思いますか? テラコッタをうまく使ったことがありますか、それとも少し未熟だと思いますか?

私は現在、高性能のJavaストレージメカニズムを必要としています。

これの意味は：

1） 1-多くの関係を持つ10,000以上のオブジェクトがあります。

2）オブジェクトは5秒ごとに更新され、システム障害が発生した場合でも最新の更新が保持されます。

3）オブジェクトは、妥当な時間（1〜5秒）でクエリ可能である必要があります。（つまり、このタイムスタンプを持つすべてのオブジェクトを私に与えるか、これらの場所の境界内にあるすべてのオブジェクトを私に与えてください）。

4）オブジェクトは、さまざまなGlassfishインストールで使用可能である必要があります。

現在：

私はJMSを使用してオブジェクトを配布し、HibernateをORMとして使用し、HSQLDBを使用して必要な回復可能性を提供しています。

私はそのパフォーマンスに完全に満足しているわけではありません。特にこれのJMS部分。

Stack Overflowの調査を行った後、これがより良い解決策になるかどうか疑問に思っています。私はテラコッタが私に与えるものについての経験がないことを覚えておいてください。

私はTerracottaを使用してシステム全体にオブジェクトを分散しますが、他の何かがそれらのオブジェクトの属性を「照会」する機能を提供する必要があります。

これは合理的に聞こえますか？これらのパフォーマンスの制約を満たしますか？他にどのような解決策を検討する必要がありますか？

次のように機能する、分散する必要のあるシステムがあります。tomcatによって提供されるサーブレットは、多数の共有（分散）フィールドを持つスレッドを起動して生成します。エルゴ、スレッドをルートとして設定し、サーブレットコンストラクタから通常どおりスレッドを生成しようとしました。ただし、ロギングは、共有しようとしているRunnableのコンストラクターが終了しないことを示しています。何が原因でしょうか？

私のサーブレットには、ルートとして共有しようとしているスレッドのインスタンスがあり、ロギングは、runnableを実装するクラスのコンストラクター（UpdaterThread）が終了するまですべてが正常であることを示しています。

私は次のものを持っています：

サーブレット：

印刷"新しいスレッドの作成"; updaterThread = new UpdaterThread（args）; 印刷"スレッドを起動します。"; new Thread（updaterThread）.start（）;

これで、Tomcatコンソールの出力に「LaunchingThread」が表示されなくなりましたが、UpdaterThreadコンストラクターの最後まですべてのprintステートメントを表示できます。UpdaterThreadは、マップ（サーブレットによって共有される）、文字列、SQL接続、ステートメント、ReentrantReadWriteLock、Long、および一時的なブール値と共有されないLongへの参照を維持します。

UpdaterThreadのコンストラクターで、共有マップへの参照と文字列の値を渡します。テラコッタを有効にしないと、このポイントを超えることができます。何が原因で、TomcatとTerracottaがエラーメッセージなしでハングするのでしょうか。rrwlロックは、後のメソッドが呼び出されるまで使用されませんが、プログラムの実行ではそれほど遠くまでは行きません。ヘルプ？