3

こんにちは、みんな！

私のクライアントは現在、毎日 300 万から 400 万の挿入を実行する SQL Server データベースを持っています。現在のDBは奇妙にレイアウトされていますIMHO：着信データは「現在の」テーブルに移動し、夜間のレコードは対応する月次テーブル（つまり、MarchData、AprilData、MayDataなど）に移動されます。これは現在のテーブルの正確なコピーです（スキーマ的にはi平均）。読み取りはすべての月次テーブルと現在のテーブルを UNION したビューから行われ、挿入と更新は現在のテーブルに対してのみ行われます。データを 13 個のテーブルに分割したのは、これらすべてのテーブルが個別のデータ ファイルを使用し、それらのデータ ファイルが 13 台の物理ハード ドライブに書き込まれているという事実によるものだと説明されました。したがって、各テーブルには独自のハード ドライブが割り当てられ、おそらくビューのパフォーマンスが向上します。私は何を

私は、このアプローチが本当に最善のアプローチなのだろうかと思っていました。それとも、別のアプローチを検討できますか? データベースは約 300 ～ 400 GB で、1 日あたり 1.5 ～ 2 GB ずつ増加していることに注意してください。時折、12 か月以上前のレコードを別のデータベース (アーカイブ) に移動します。

どんな洞察も高く評価されます。

4

2 に答える 2

2

MS SQL Server を使用している場合は、パーティション テーブルとインデックスを検討してください。

つまり、行を何らかの値、つまり年と月でグループ化できます。各グループは、独自のインデックスを持つ個別のテーブルとしてアクセスできます。したがって、すべての行にアクセスしなくても、2011 年 2 月の売上を一覧表示、要約、および編集できます。分割テーブルはデータベースを複雑にしますが、非常に長いテーブルの場合、パフォーマンスが大幅に向上する可能性があります。また、異なるディスクに値を格納する「ファイル グループ」もサポートしています。

この MS 製のソリューションは、1 つの重要な点を除いて、あなたのものと非常に似ているように見えます。それは、一晩でレコードを移動しないことです。

于 2011-03-26T03:22:46.010 に答える
0

データを 13 個のテーブルに分割したのは、これらすべてのテーブルが個別のデータ ファイルを使用し、それらのデータ ファイルが 13 台の物理ハード ドライブに書き込まれているという事実によるものだと説明されました。各テーブルには専用のハード ドライブがあり、

そのための声明が 1 つあります。IDIOTS AT WORK です。

  • テーブルはディスクではなく、複数のデータ ファイルにまたがるファイル スペースに保存されます。これに注意してください...つまり、13 ディスクに 12 個のデータ ファイルを持つ 1 つのファイル スペースを持つことができ、テーブルは 13 個のテーブルすべてに分散されます。負荷を分散するためにばかげた愚かなゲームをプレイする必要はありません。ドキュメントを読むだけですでに可能です。

  • それでも、13 枚のディスクが速いとは思えません。本当。私は個人的に小さなデータベース (わずか 800 GB) を実行しており、データだけで 6 つのディスクがあり、現在の仕事の割り当ては 3 桁のディスク (つまり 100 以上) です。13 枚のディスクを大規模なデータベースと呼ばないでください。

  • とにかく、UNIONではなくパーティション化されたテーブル（エンタープライズ版の機能ではありますが、標準のSQLサーバー）がデータを分散する必要があるべきです。

データベースは約 300 ～ 400 GB で、1 日あたり 1.5 ～ 2 GB ずつ増加していることに注意してください。

まともなサーバーを入手してください。

私は、このアプローチが本当に最善のアプローチなのだろうかと思っていました。

  • ああ、ハードウェア。高さ 2 ～ 4 ラック ユニット、SAS バックプレーン、ディスク用 24 ～ 72 スロットのデータベース用の SuperMicro ボックスの 1 つを入手してください。はい、1 台 1 台のコンピューターです。

  • 明らかにデータベースを扱うべきではない誰かが思いついた、毎月​​の blabla テーブルのがらくたを廃棄します。すべてが 1 つのテーブルに。ファイルスペースと複数のデータ ファイルを使用して、すべてのテーブルの負荷分散をさまざまなディスクに処理します。そうでもなければ...

  • ...あなたは実際に、そのようなディスクの実行が重大な怠慢であることを認識しています. RAID 5またはRAID 6またはRAID 10が適切です。そうしないと、ディスクに障害が発生したときにサーバーがダウンする可能性があり、600GBデータベースの再設定には時間がかかります. 私は自分のデータ ディスクに RAID 10 を実行していますが、個人的には約 10 億行のテーブルを持っています (そして、仕事で 1 日に約 10 億行を追加しています)。データベースのサイズが小さいことを考えると、SSD のカップルも役立ちます....それらの IOPS バジェットは、おそらく 2 ～ 3 個のディスクに移動して、より多くの速度を得ることができることを意味します。それが不可能な場合、私の賭けは、それらのディスクが 7200 RPM の低速の 3.5 インチ ディスクであるということです... エンタープライズ レベルのディスクへのアップグレードが役立つでしょう。 )

とにかく、これは本当にひどく設定されているように聞こえます。残念ながら、私の研修生がそのような賢いものを思いついたことを嬉しく思います (それは間違いなく研修生の頭を超えているでしょう) か、私の開発者は私がそれを見つけた瞬間に私のために働くのをやめるでしょう (ひどい無能さに基づいて、感じます)法廷で自由に争うことができます）

再編成します。また、バッチ処理にも注意してください。バックアップと重複しないように、時間をずらして処理する必要があります。単なる単純な低速ディスクで提供できる IO は非常に限られています。

于 2011-03-26T06:01:45.487 に答える