2

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

これの意味は：

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

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

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

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

現在：

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

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

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

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

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

4

9 に答える 9

4

あなたが尋ねたものではないことは知っていますが、 HSQLDB からH2に切り替えることから始めたいと思うかもしれません。H2 は、比較的新しい純粋な Java DB です。これは HSQLDB を書いたのと同じ人によって書かれており、彼はパフォーマンスがはるかに優れていると主張しています。しばらく使っていますが、とても満足しています。非常に迅速な移行 (Jar の追加、接続文字列の変更、データベースの作成) になるはずなので、試してみる価値があります。

一般に、私は、アプリケーションを別のアーキテクチャーで書き直す前に、自分が持っているものを最大限に活用しようとすることを信じています。最初にボトルネックを特定するためにプロファイリングを試みます。

于 2009-04-06T03:59:10.257 に答える
2

最初、Lucene はあなたの友達ではありません。(読み取り専用)

兵馬俑は、論理層でスケーリングされます! あなたの問題は処理ロジックに関連していないようです。ストレージ/通信ポイントの周りにあります。

  1. ボトルネックを特定してください！Storage/Logic/JMSの処理時間とオーバーヘッドをベンチマーク！
  2. 優れた JMS フレームワーク (ActiveMQ など) と優れた/調整された構成で JMS の問題を解決します。
  3. おそらく、分散キー=>値ストアがあなたの友達です。プロジェクトヴォルデモートを試してみてください！
  4. Hibernate と HSQL にとどまりたい場合は、Hibernate の第 2 レベルのキャッシュと接続プーリング (c3po、コンテナー駆動...) をチェックしてください。
于 2009-04-06T13:11:21.130 に答える
2

何人かの Terracotta ユーザーが過去にこのようなシステムを構築したので、それが可能であることを証明できます。:)

Compass は Terracotta を使用したクラスタリングをサポートしているため、役立つ場合があります。クラスター化されたデータ構造を作成する方法に注意するだけで、さらに高速になる可能性があると思います。

あなたの要件とテラコッタについて：

1) Terracotta の観点からすると、10k オブジェクトは非常に小さい

2) 5 秒の更新レートは問題にならないようです。ノードの数と、利用できる自然なパーティション分割があるかどうかによって異なります。すべての更新は永続的です。

3) 1 ～ 5 秒のクエリ時間は非常に簡単に思えます。ルックアップのために適切に編成された独自のデータ構造を構築することは、注意が必要な部分です。明らかに、すべてのデータをスキャンすることは避けたいと考えています。

4) Terracotta は現在、Glassfish v1 および v2 をサポートしています。

Terracotta フォーラムに投稿すれば、この問題について Terracotta の目玉が増える可能性があります。

于 2009-05-27T14:31:49.840 に答える
1

更新率が非常に高いため、インデックスが作成されたドキュメントを更新する方法がないため、Luceneはほぼ間違いなくあなたが探しているものではありません。すべてのオブジェクトバージョンをインデックスに保持し、最新のタイムスタンプを持つバージョンを選択する必要があります。これにより、パフォーマンスが低下します。

私はDBの専門家ではありませんが、最近ニュースになっている分散DBソリューションのいずれかを調べる必要があると思います。（CouchDB、Cassandra）

于 2009-04-06T06:38:48.843 に答える
1

私は現在、セット + リスト セマンティクスを提供する非常に (非常に) 高速なキー/値分散ハッシュ DB のクライアントの作成に取り組んでいます。DB は C99 であり、GCC が必要です。現在、1 秒あたり 30,000 の get/sets という現在の障壁を破るために、古き良き Java ネットワーク IO と戦っています。1週間以内に完了することを願っています。私のアカウントから私に連絡してください。ショーの時間になったら戻ってきます。

于 2009-04-06T03:41:39.910 に答える
1

JMS に使用しているベンダーはわかりませんが、そこにボトルネックがあったとしても驚かないでしょう。ActiveMq から 1 秒あたり 100 を超えるメッセージを取得できませんでした。また、確認応答の構成、キュー サイズなどに関して何を試しても、CPU を数パーセント以上ソークすることはできませんでした。

解決策は、多くのクエリを 1 つの JMS メッセージにまとめることでした。クエリ数が 200 に達したとき、またはタイムアウト (20 ミリ秒を使用) に達したときにメッセージのバッチを送信する単純なクラスがあり、これによりメッセージ スループットが劇的に向上しました。

于 2009-04-06T07:35:58.520 に答える
1

多分あなたは見てみる必要があります: Prevayler .

オブジェクトは常に mem にあります。オブジェクトへの「変更」は保持されます。時々、スナップショットを作成できます。すべてのオブジェクトが永続化されます。

于 2009-04-06T11:26:50.867 に答える
0

保証されたメッセージングは​​、揮発性メッセージングよりもはるかに遅くなります。すべてのオブジェクトが数秒ごとに更新される場合、更新のバッチ処理（500の変更、または時間によっては1〜10ミリ秒の価値）、揮発性メッセージングの送信、およびトランザクションのバッチ処理を検討できます。この場合、帯域幅によって制限される可能性が高くなります。ユースケースを調整すると、小さいバッチサイズも効率的に機能する場合があります。帯域幅が重要な場合（たとえば、接続が10 MB以下の場合は、JMSを介した圧縮を使用できます）

カスタムソリューション（これも簡単かもしれません）を使用すると、はるかに高いパフォーマンスを実現できます。たとえば、HazelcastとJGroupsは無料です（データベースの同期を行うノードを追加して、メインアプリの速度が低下しないようにすることができます）。50万の耐久性のあるメッセージ/秒のオーダーを処理する商用製品があります。

于 2009-05-27T06:02:11.707 に答える
0

Terracotta + jofti = クエリ可能な永続的なクラスター化されたデータ構造 Google で terracotta querymap を検索するか、tusharkhairnar.blogspot.com にアクセスして querymap ブログを参照してください データベースを更新するために timasync を統合することもできます。データベースは、キャッシングおよびデータベース オフロード メカニズムとしてテラコッタを使用する記録システムです。非同期更新をバッチ処理して高速化することもできるため、db にはかなり最近のデータが含まれます。

Tushar tusharkhairnar.blogspot.com

于 2009-07-03T18:07:51.710 に答える