SQL テーブルのサイズが大きすぎるという厳密なルールはありますか?
名前と値のペア形式で SCORM 追跡データを保存しています。コースごとにユーザーごとに 4 ～ 12 行になる可能性があります。数百のコースと数千のユーザーが存在するため、これは悪いことになるのでしょうか?
18467 次
10 に答える
12
魔法の数は数十億です。数十億行のデータに到達するまでは、それほど多くのデータについて話しているわけではありません。
計算する。
コースごとにユーザーごとに 4 ～ 12 行...数百のコースと数千のユーザー?
400,000 ～ 1,200,000 行。行ごとに 1000 バイトと仮定しましょう。
それは 400Mb から 1.2Gb のデータです。Apple Store で 100Gb ドライブを 299 ドルで購入できます。299 ドル以上の請求可能な時間を簡単に費やして、もはや重要ではない詳細に汗をかくことができます。
1Tb (1,000 Gb) のデータに到達するまでは、多くのデータについて話しているわけではありません。
于 2009-03-18T21:11:34.330 に答える
10
私は個人的に 5,000 万行のテーブルを運用していますが、これは私が聞いたものよりも小さいものです。パーティショニングを使用して構造を最適化する必要があるかもしれませんが、環境でシステムをテストするまでは、時間を無駄にするべきではありません。あなたが説明したことはかなり小さいです
SQL Server 2000 および 2005 を使用していたことを付け加えておく必要があります。各 DBMS には独自のサイズ制限があります。
于 2009-03-18T21:09:38.920 に答える
6
100 (コース) * 1000 (ユーザー) * 10 (レコード) はわずか 100 万です。これはローエンドですが、適切なデータベースであれば問題なく処理できるはずです。
あいまいに聞こえるのは、名前と値のペアです。これにより、適切なインデックスを作成する能力が制限されます。これは、優れたパフォーマンスにとって重要です。
于 2009-03-18T21:11:57.700 に答える
4
厳格な規則はありませんが、数値を取得するための困難で迅速な方法があります。
実際のデータの予想される形式 (例: 同様の規則性、文字、パターンなど) に大まかに近似したダミー データをテーブルに入力するプログラムを作成します。 ダミー データを使用した実際のクエリを使用して、行数を徐々に増やしながらパフォーマンス テストを実行します。おそらく 1000 行または 10000 行単位で表に表示されます。
クエリのパフォーマンス (たとえば、1 秒あたりに完了したクエリ) が許容範囲を超えた時点で、行数が「大きすぎます」となります。
于 2009-04-10T05:29:16.923 に答える
3
私はかつて、名前と値のペアのテーブルに 3 億行を超える Web フォーム システムに取り組んでいました。フォームの多くは、フォーム送信ごとに 300 行を超えていました。パフォーマンスは実際にはそれほど悪くはありませんでしたが、クエリを実行するのは完全に PITA でした! 私のSQL書き込み能力は、このギグの生涯にわたって確実に向上しました.
しかし、私見ですが、標準の正規化されたテーブルを支持してそれを取り除くという意見がある場合は.
于 2009-03-18T21:29:52.600 に答える
2
あまり。それはすべてビジネス ニーズに依存し、推定行数をサポートする製品を購入する必要があります。
于 2009-03-18T21:08:59.203 に答える
0
私は2B行のデータを含むテーブルを作成しようとしたデータベースに取り組んできましたが、それは機能しませんでした。5億に達し、再設計されました。このような大きなテーブルを操作する際の最大の落とし穴の1つは、削除にかかる時間でした。古いレコードをアーカイブしてからメインテーブルから削除するというアプローチをよく目にします。テーブルが十分に大きいため、インデックスが再構築されるときに削除が何時間も実行される場合。
カットオフがどこにあるかはわかりませんが、腸の感触は、テーブルが1,000万行を超えるとおそらく大きすぎることを示しています。私たちのアプローチは、データを日付で分割することでした。そのため、1週間のデータのテーブル、数か月の別の要約テーブル、および数年の別の要約テーブルが作成されました。これは、データウェアハウスで非常に一般的です。ところで、これはSQL 7.0でしたが、DBがこのタイプのものでまだ優れているかどうかを知りたいですか？
于 2009-03-18T22:41:24.317 に答える
0
あなたの質問は、答えよりも多くの質問を促します。
- どのデータベースエンジンを使用していますか? これなしで良い答えを作るのは難しいです。
- テーブル構造は何ですか？データ型に応じて、テーブルがディスク上でどのようにレイアウトされるかはこれに依存します。
- ユーザー/コースごとに1つのレコードを保存しないのはなぜですか? SCORM データを保存しているので、これは、完了、成功、試行、合計時間などの標準的な SCORM データを保存していることを意味すると思います。このために複数の行を作成する必要はありません。
SCORM データを格納するデータベースをいくつか構築しましたが、あなたが提案するようなタグ/値システムを使用する必要はありませんでした。
ただし、覚えておきたいことの 1 つは、テーブル内の行数ではなく、テーブルのサイズ (バイト単位) です。単に：
テーブル サイズ = 行サイズ (平均) * 行数
尋ねるべき質問は、「どのくらいのテーブルが大きすぎるか」ということです。
于 2012-12-31T14:10:49.480 に答える