私はあなたの記事を読みました (SQL Server パーティショニング: すべてに対する答えではありません)。私のケースでパーティショニングを使用することに驚くかどうかはわかりませんが、1 秒あたり約 1000 レコードを保存する必要があります。このデータはモバイル ノードの位置に関するものであり、これらのデータが私のデータベースを作成します。大きすぎるので、データベースを分割する必要があると思いますか?
4 に答える
1
1秒間に1000回というのは、たいしたものではありません。
- 24時間365日毎秒ですか？
- 定義されたウィンドウで？
- ピークは毎秒 1000 ですが、通常はそれ以下ですか?
最近のシステムは 2,000 万行/月 (さらに 5,000 ～ 8,000 万行の整理後) で増加しており、パーティショニングのようなことは考えていません。
于 2009-02-22T16:20:44.160 に答える
0
問題のテーブルにインデックスが付けられていると仮定すると、インデックスのいずれかが使用可能なRAMを超えた場合、2つのオプションのいずれかが確実に保証されます。当然のことながら、そのうちの1つは、RAMを増やすことです。もう1つはもちろん、垂直分割です。
gbnの回答は、月（または週、または日）に追加されるレコードの数など、言及していない考慮すべきいくつかの良いことを提供します。（平均）レコードの大きさに関するRichardのコメントも重要です。特に、インデックスの平均レコードの大きさに関しては、インデックスにテーブルのすべてのフィールドが含まれていないと想定しています。
しかし、gbnの答えも私には少し無謀に思えます。月に2,000万行で成長しており、「パーティション分割のようなものを考えている」ことすらありません。上記でほのめかされたような十分な測定基準がなければ、これは災害の可能性のあるレシピです。RAMやパーティショニングを増やすことを検討する前に、現在および/または予想される成長率をどれだけ長く維持できるかを判断するだけでも、少なくともそれについて考える必要があります。
于 2009-05-09T23:16:41.517 に答える
0
それはたくさんのデータです。
データのライフサイクルはどのようなものですか。つまり、限られた期間だけレコードを保存する必要がありますか? たとえば、1 か月後に特定のデータをアーカイブしたり、データ ウェアハウスに移動したりできますか?
処理する予定のデータ量を考えると、簡単にスケーリングできるアーキテクチャを使用したいと思うでしょうか? このため、Amazon Ec2 などのクラウド タイプのサービスや、Azure プラットフォームでの SQL Data Services の使用を検討することをお勧めします。
http://www.microsoft.com/azure/data.mspx
おそらく、実際に何をしようとしているのか、つまりどのようなビジネス プロセスをサポートしようとしているのかについて、より具体的な詳細を提供していただければ、より具体的な支援を提供できる可能性があります。
このような詳細がなければ、SQL Server のパーティショニングが適切な設計アプローチであるかどうかを確認することはできません。
于 2009-02-22T15:26:21.420 に答える
0
別の RDMS を確認する必要がある場合があります。Verticaを見てみましょう。
于 2009-05-09T22:48:00.307 に答える