10

バックグラウンド

私たちは、「高性能」アプリケーション向けのソリューションを考え出すために、懸命に取り組んできました。このアプリケーションは、基本的には高スループットのメモリ内マネージャーであり、ディスクへの同期が行われます。「読み取り」と「書き込み」は非常に高く、1 秒あたり約 3000 トランザクションです。可能な限りメモリ内で実行しようとしますが、最終的にはデータが古くなり、ディスクにフラッシュする必要があり、これが大きな「ボトルネック」になります。アプリはマルチスレッドで、約 50 のスレッドがあります。IPC(プロセス間通信)はありません

試み

最初はこれを Java で書きましたが、一定の負荷がかかるまでは非常にうまく機能し、ボトルネックが発生して追いつくことができませんでした。その後、C# で試してみましたが、同じボトルネックに達しました。これをアンマネージ コード (C#) で試してみたところ、最初のテストでは MMF (メモリ マップ ファイル) を使用すると非常に高速でしたが、運用環境では読み取りが遅くなりました (ビューを使用しています)。CouchBase を試してみましたが、ネットワークの使用率が高いという問題に遭遇しました。これは、私たちの構成が不適切である可能性があります。

追加情報: Java の試み (非 MMF) では、ディスクにフラッシュする必要がある情報のキューを持つスレッドが、ディスクへの「書き込み」を維持できない程度までビルドされます。私たちの C# メモリ マップ ファイル アプローチの問題は、読み取りが非常に遅く、書き込みが完全に機能することです。何らかの理由で、ビューが遅い!

質問

問題は、大量のデータを転送しようとする状況です。誰かが支援できる可能性のあるアプローチまたはアーキテクチャ設計を支援してもらえますか? これは少し大雑把に思えるかもしれませんが、高性能、高スループットの特定の性質によって答えが絞り込まれるはずです。

そのようなレベルで Couchbase、MongoDB、または Cassandra を使用することを保証できる人はいますか? 他のアイデアや解決策をいただければ幸いです。

4

3 に答える 3

3

最初に、高性能でスケーラブルなアプリケーションを構築した経験が (あったとしても) ほとんどないことを明確にしたいと思います..

Martin Fowler は、アプリケーションが単一のスレッドで毎秒約 600 万の注文を処理できるようにする LMAX アーキテクチャについて説明しています。(大量のデータを移動する必要があるように見えるため)役立つかどうかはわかりませんが、そこからいくつかのアイデアを得ることができるかもしれません:http://martinfowler.com/articles/lmax.html

アーキテクチャは、(比較的) 簡単なスケーラビリティを提供するためによく使用されるイベント ソーシングに基づいています。

于 2012-08-17T08:33:16.700 に答える
2

大量のデータとディスク アクセス。どのような種類のディスクについて話しているのですか? HDD は、複数のファイルを扱う場合、ヘッドの移動に多くの時間を費やす傾向があります。(ただし、SSD を使用している場合は問題になりません。) また、メモリ マップト ファイルがページ サイズのチャンクで管理されるという事実を利用する必要があります。可能であれば、データ構造はページ境界に揃える必要があります。

ただし、いずれにせよ、ボトルネックが何であるかを確認する必要があります。たとえば、スレッド同期のために実際に時間を失った場合、データ構造を最適化してもあまり役に立ちません。また、HDD を使用している場合、ページの配置は、何らかの方法ですべてを 1 つのファイルに詰め込むほどには役に立たない可能性があります。したがって、適切なツールを使用して、どのブレーキがまだあなたを妨げているかを突き止めてください。

汎用データベースの実装を使用しても、期待するほど役に立たない場合があります。結局のところ、それらは汎用です。パフォーマンスが本当に重要な問題である場合は、要件を念頭に置いた特別な実装が、これらのより一般的な実装よりも優れている可能性があります。

于 2012-08-17T07:01:30.783 に答える
-1

高速が必要な場合は、書き込みの永続化とキューをできるだけ避け、読み取りでメモリ ソア/キャッシュを使用します。

言語はほとんど関係ありません。\

于 2012-11-02T08:55:43.837 に答える