7

上限数万リクエスト/秒で 60,000 -> +90,000 リクエスト/秒を見たいです。

私のセットアップは次のもので構成されています。

ユーザー ---> Web アプリ --> メッセージ キュー --> パーサー --> データベース?

パーサーは現在、COPY を使用して約 18750 レコード/秒を解析/詰め込むことができるため、パーサーを追加し始めるまではその範囲に制限されていることに言及する必要があります。これは今のところ大きな懸念事項ではありません。

できるだけ多くのレコードをできるだけ早く一括アップロードする機能を必要とするシステムがあります。この同じシステム (またはアプローチ方法によって異なる場合があります) は、次のような分析タイプのクエリに応答できる必要があります。

winq = "player = '@player' および " +
       "(type = 'award' or type = 'return') and hand = hand_num"
lostq = "player = 'player' および " +
        "type != 'award' and type != 'return' and hand = hand_num"

.....別のテーブルにキーオフされているため、(ユーザーごとに) 10 ～ 15,000 回。言うまでもなく、これらの結果は今のところ 10/ページでページ分けされています。

私は以下を見てきました：（これらはすべて同じサーバー上にあると仮定します）

  • mysql (reg. run of the mill rdbms) -- 15 ～ 20,000 リクエスト/秒の範囲に入ることができました。現在の状況では、これをスケールアウトしようとすると、スケールする必要があるたびに別のホスト/データベースが必要になります。これは実行できません。

  • couchdb (ドキュメント指向のデータベース) -- 700 リクエスト/秒を超えませんでした。これが私たちのお尻を救うことになることを本当に望んでいました-チャンスではありません！

  • vertica (列指向のデータベース) -- 1 秒あたり 60000 リクエストに達していました。クローズド ソースで、非常に高価です。これはまだオプションですが、個人的にはまったく好きではありませんでした

  • tokyocabinet (ハッシュベースのデータベース) -- 現在、1 秒あたり 45,000 回の挿入と 1 秒あたり 66,000 回の選択が行われています。昨日これを書いたとき、毎秒約 5555 リクエストで動作する FFI ベースのアダプターを使用していました。これは私が今まで見たデータベースの中で群を抜いて最速です!!

  • terracotta -- (vm クラスタ) 現在 jmaglev と一緒にこれを評価しています (maglev 自体が出てくるまで待ちきれません) -- これは最も遅いです!

たぶん私はこの問題に間違ったアプローチをしているだけかもしれませんが、RDBMS は非常に遅いといつも聞いていました。

試験条件::

私の開発ボックスの仕様は次のとおりです。

デュアル 3.2 GHz インテル、1 ギガ RAM

Mysql mysql.cnf の編集は次のとおりです。

key_buffer = 400M # は 16M でした
innodb_log_file_size = 100M # 以前は存在しませんでした
innodb_buffer_pool_size = 200M # 以前は存在しませんでした

更新::

テラコッタは私たちのアプリケーション構造にあるかもしれませんが、速度がひどく、ヒープの使用率が悪いため、すぐにデータベースを置き換えることはありません.

一方、tokyocabinet の NON-FFI ruby​​ ライブラリ (tyrant/cabinet を意味する) が超高速で、現在 1 位であることは非常に嬉しかったです。

4

8 に答える 8

6

非常に大きなスケーラビリティを実現するには、次の 2 つの点に注目する必要があります。

  • シャーディング: データ セットを重複しないグループに分割します。リクエストからサーバーにマップするための簡単で迅速な方法があります。(af で始まるプレーヤー、サーバー 1; gq、サーバー 2... など...)
  • キャッシング: Memcache を使用して、いくつかの非常に一般的な選択クエリの出力を記憶します。これにより、頻繁にディスクにアクセスする必要がなくなります。
于 2009-02-17T23:12:35.833 に答える
1

ゲームの大物はオラクルですが、それは大金です。

安くしたい場合は、別の条件で価格を支払う必要があります。

  • DB を複数のインスタンスに分割し、負荷を分散します。
  • 結果をキャッシュする可能性があるため、実際の DB アクセスが削減されます。
于 2009-02-17T23:17:27.990 に答える
0

postgresqlを試しましたか？mysql よりも高速である必要があります。とにかく、複数のサーバー (分割データベース) で負荷を分散する必要があります。複数のデータベース (たとえば、各クライアント用) を作成し、それらの小さなデータベースと同期する 1 つの集中型データベースを作成できます...

于 2009-02-18T22:12:59.913 に答える
0

ojracが言ったように、シャーディングとキャッシング。

もう 1 つのオプションは、一歩下がって、より少ないクエリで作業を行う方法を見つけることです。あなたがくれたちょっとした情報から、「もっといい方法があるに違いない」と思わずにはいられません。あなたがいくつかの要約テーブルを与えた例から（オプションのキャッシュを使用して）、簡単に勝つことができます。

ハイパーテーブルなどは、一部のデータ アクセス パターンでより優れたパフォーマンスを発揮しますが、典型的なデータベースには非常に適しているように思えます。

ええ、CouchDB はがっかりするほど遅いです。

于 2009-02-18T00:21:10.630 に答える
0

書き込みの多いアプリで永続的にデータをすばやく保存する一般的な方法は、追加専用ログを使用することです。ログ ファイルが独自の回転ディスク上に適切に展開されている場合、書き込み/追加操作ごとのディスク シーク時間が最小限に抑えられます。

メタデータを更新して、各書き込み後に主キーのオフセットを知ることができます。

これを行うmysqlストレージエンジンがあり、mysqlを使用したいです。もう 1 つのオプションは、frotdb のような新しい nosql データベースの 1 つです。

SSDも使ってみましたか？

この問題を解決するためのオプションはたくさんありますが、手作業が必要になる可能性があります。

于 2010-01-08T13:33:57.240 に答える
0

ユーザー ---> Web アプリ --> メッセージ キュー --> パーサー --> データベース?

メッセージキューは何のために必要ですか? これらは通常、大きなパフォーマンスの問題です。

于 2009-02-17T23:25:16.503 に答える
0

redisを試しましたか? 彼らは、110000 SETs/秒、81000 GETs/秒の速度を約束します。リストとセットをサポートする高度なキー値データベースです。

于 2009-09-22T22:23:56.517 に答える
0

どのシステムも、必要なすぐに使えるパフォーマンスを提供するとは思えません。おそらく、使用しているマシンのハード リミットに達し始めるでしょう (ほぼすべての書き込み集中型データベースでは、I/O リミットにかなり早く到達します)。何らかの分析が必要になる場合がありますが、ほとんどの場合、ディスクがボトルネックになります。ソリッド ステート ディスクを使用する場合と同様に、より多くの RAM が役立ちます。

ただし、使用する実際のデータベースに関係なく、おそらく何らかのクラスタリングが必要になるでしょう。データ自体をシャーディングするか、MySQL を使用してリードスレーブを設定すると、ノード間で負荷が分散され、求めているスループットが得られます。

また、MongoDB は素晴らしいです。一見の価値があるかもしれません。

于 2009-09-22T22:41:59.110 に答える