10

少し前に、数百万人のユーザーを抱える当社の Web サイトで、顧客のユーザー アクションをログに記録して報告するための新しい統計システムを検討しました。

データベースの設計は非常に単純で、foreignId (200,000 の異なる ID)、datetime フィールド、actionId (30 の異なる ID)、いくつかのメタ情報 (smallints のみ) を含む 2 つのフィールドを含む 1 つのテーブルを含みます。他のテーブルへの制約はありません。さらに、小さいインデックスを使用するとユーザーがタイムアウトになるため、削除できない 4 つのフィールドをそれぞれ含む 2 つのインデックスがあります。すべてのクエリにこのフィールドが含まれているため、foreignId は最も重要なフィールドです。

SQL サーバーの使用を選択しましたが、実装後はリレーショナル データベースが最適とは思えません。1 日に 3,000 万件のレコードを挿入することはできません (挿入のみであり、更新は行いません)。データベースを読み取ります。インデックスを十分に高速に更新できないためです。エルゴ: 私たちは大きな問題を抱えています :-) 問題は一時的に解決しましたが、まだ

リレーショナル データベースは、この問題には適していないようです。

BigTable のようなデータベースはより良い選択でしょうか? またその理由は? または、この種の問題に対処する際に、他により良い選択肢はありますか?

注意。この時点で、4 GB メモリと Win 2003 32 ビットを備えた単一の 8 コア Xeon システムを使用しています。私の知る限り、RAID10 SCSI。インデックス サイズは、テーブル サイズの約 1.5 倍です。

4

8 に答える 8

12

あなたのシステムは、インデックスなしで 1 秒あたり 3000 レコードを挿入できますが、2 つの非クラスター化インデックスを追加すると約 100 レコードしか挿入できないと言います。I/O で許可される最大スループットが 3k/s である場合、2 つのインデックスを追加すると、理論的にはスループットが約 1000 ～ 1500/秒に低下します。代わりに、劣化が 10 倍悪化します。適切な解決策と答えは「依存」であり、深刻なトラブルシューティングとボトルネックの特定を実行する必要があります。それを念頭に置いて、あえて推測するとしたら、考えられる犯人は次の 2 つです。

A. 非クラスター化インデックスを追加すると、ダーティ ページの書き込みがより多くの割り当て領域に分散されます。解決策は、クラスター化されたインデックスと各非クラスター化インデックスを独自のファイル グループに配置し、3 つのファイル グループをそれぞれ RAID 上の個別の LUN に配置することです。

B. 非クラスター化インデックスの選択性が低いため、読み取りと書き込みの間で競合が大きくなり (キーの競合と%lockres% の競合)、挿入と選択の両方で長いロック待機時間が発生します。考えられる解決策は、読み取りコミット スナップショット モードで SNAPSHOT を使用することですが、既に高い IO ストレスにさらされている可能性があるシステムのバージョン ストア(つまり tempdb) に大量の IOを追加する危険性について警告する必要があります。2 番目の解決策は、レポートにデータベース スナップショットを使用することです。これにより、IO ストレスが軽減され、より適切に制御できます (tempdb バージョン ストアは関係ありません) が、レポートはリアルタイム データではなくなります。

私は B) が原因である可能性が高いと考える傾向がありますが、適切な調査と適切な根本原因分析の必要性を再度強調しなければなりません。

「RAID10」はあまり正確な説明ではありません。

  • RAID 0 部分のスピンドルはいくつですか? 彼らは短い縞模様ですか？
  • LUN の数は?
  • データベース ログはどこにありますか?
  • データベースはどこにありますか?
  • パーティションはいくつですか？
  • tempdb はどこにありますか?

リレーショナル データベースがこのようなものに適しているかどうかという質問については、そのとおりです。回復可能性、可用性、ツールセットのエコシステム、ノウハウ、開発の容易さ、展開の容易さ、管理の容易さなど、考慮すべき要素は他にもたくさんあります。リレーショナル データベースはワークロードを簡単に処理できます。適切なチューニングが必要なだけです。1 日に 3,000 万回の挿入 (1 秒あたり 350 回) は、データベース サーバーにとっては小さな変化です。しかし、CPU の数に関係なく、32 ビット 4GB RAM システムはデータベース サーバーとは言えません。

于 2009-10-04T21:53:11.560 に答える
7

2 つの特定の問題に苦しんでいる可能性があるようです。あなたが直面している最初の問題は、挿入を実行するたびにインデックスを再構築する必要があるということです - 本当にトランザクションサーバーのライブレポートを実行しようとしていますか (これは通常、ノーノーと見なされます)。第二に、サーバーがデータベースのサイズを変更しなければならないという問題が発生している可能性もあります。十分なスペースが割り当てられており、これを行うためにデータベースに依存していないことを確認してください。

SQL Server のインデックス付きビューのようなものを検討したことがありますか? これらは、メイン テーブルからインデックスを削除し、マテリアライズド ビューに移動するための良い方法です。

于 2009-10-04T19:05:53.597 に答える
3

テーブルをパーティション分割してみてください。このようにして、インデックスの更新はより小さな行セットに影響を与えます。おそらく毎日のパーティショニングで十分でしょう。そうでない場合は、時間単位でパーティション分割してみてください。

于 2009-10-04T19:45:50.013 に答える
2

十分な情報を提供していません。リレーショナル データベースが適切ではないように見えるとあなたが言う理由はわかりませんが、現在パフォーマンスの問題が発生しているという事実以外にはわかりません。RDBMS はどのような種類のマシンで実行されていますか? あなたが外国の ID を持っていることを考えると、リレーショナル データベースはまさにここで求められているものと思われます。SQL Server は、十分なハードウェアで実行されていると仮定すると、1 日あたり 3,000 万回の挿入を処理できるはずです。

于 2009-10-04T19:01:20.877 に答える
2

大量のトラフィックを考えると、レポート用にデータベースを複製するのが最善の方法のようです。ただし、最初にいくつかのことを試してください...

2 つのインデックスではなく、1 つのインデックスを使用します。クラスター化されたインデックスは、おそらく非クラスター化よりも優れた選択肢になるでしょう。一般に、数が少なく幅の広いインデックスは、数が多く幅の狭いインデックスよりも優れたパフォーマンスを発揮します。そして、あなたが言うように、あなたのアプリを殺しているのはインデックス作成です。

ID に何を使用しているかはわかりませんが、GUID を使用している場合は、キーを bigint に変更することをお勧めします。GUID はランダムであるため、インデックスの構築と使用の両方において、インデックスに大きな負荷がかかります。bigint ID 列を使用すると、インデックスはほぼ時系列で実行されます。最近のデータに対するクエリのリアルタイム アクセスに本当に関心がある場合、アクセス パターンは単調に増加するキーに適しています。

于 2009-10-04T19:51:42.623 に答える
0

挿入がどのように管理されているかは言いません。それらはバッチ化されていますか、それとも各統計は個別に書き込まれていますか? 1 回の操作で 1,000 行を挿入する方が、1,000 回の個別の操作で 1 行を挿入するよりもはるかに効率的であるためです。多かれ少なかれリアルタイムのレポートを提供するのに十分な頻度で挿入できます;)

于 2009-10-05T12:43:11.887 に答える
0

アーキテクト/DBA が指摘したように、Sybase IQ は目標にかなり適しているようです (理由として、すべての統計情報を明示的に IQ に移動し、その機能を説明しています)。私は自分自身を立証することはできませんが、過去の経験から彼らが話していることを一般的に知っている私たちの会社の人々にうなずくだけです.

しかし、30mm レコードはすべて保管しなければならないのでしょうか? 事前に集計されたデータを保存する方がよいのではないでしょうか?

于 2009-10-04T19:08:00.027 に答える
0

SQLサーバーについてはわかりませんが、私がずっと前に使用した別のデータベースシステムでは、このタイプのアクティビティの理想的な方法は、更新を保存してから、バッチとしてインデックスをオフにし、新しいレコードを追加してから再インデックスすることでした. これを 1 晩に 1 回行いました。レポートのニーズがこのタイプのソリューションに適しているかどうか、または MS SQL で実行できるかどうかはわかりませんが、可能だと思います。

于 2009-10-04T19:54:17.743 に答える