21

データベースのサイズを見積もるという点で、新しいアプリケーションを開発するときに何をしているのかと思っていました.

たとえば、Web サイトを立ち上げようと計画していますが、データベースのサイズがどれくらい大きくなると予想されるかを見積もるのに苦労しています。私のデータベースのサイズを教えてくれるとは思っていませんが、これを見積もる際の一般的な原則があるかどうか知りたいです。

たとえば、Jeff が StackOverflow を開発したとき、彼は (おそらく) データベースのサイズと成長を推測しました。

私のジレンマは、Web アプリケーション用のホスト型ソリューション (この段階でのコストについて) を使用することであり、できれば十分な SQL Server スペースを購入しないことで自分を傷つけたくないということです (彼らはこれに対して割増料金を請求します)。 ）。

4

4 に答える 4

21

データベーススキーマがある場合、サイジングは非常に簡単です...推定行×各テーブルの平均行サイズ×インデックスの要因×オーバーヘッドのその他の要因です。今日のストレージの価格は途方もなく低くなっているため、サイトのトラフィックが非常に多い場合 (または大企業向けのアプリを構築している場合) を除き、多くの場合、サイジングは問題になりません。

私自身のサイジング演習のために、私は常に Excel スプレッドシートのリストを作成しました。

  • col 1: 成長する各テーブル
  • col 2: 推定列サイズ (バイト単位)
  • 列 3: 推定行数 (アプリケーションに応じて、1 年あたりまたは最大)
  • 列 4: インデックス係数 (私は常にこれを 2 に設定します)
  • 列 5: オーバーヘッド係数 (私は常にこれを 1.2 に設定しています)
  • col 6: 合計列 (col 2 X 3 X 4 X 5)

列 6 (合計列) の合計に、成長テーブルを除いたデータベースの初期サイズを加えたものが、サイズの見積もりです。もっと科学的になることができますが、これは私の手っ取り早い汚い方法です。

于 2009-03-02T00:25:56.433 に答える
0

決定：

  • 1 日あたりの訪問者数 V
  • 訪問ごとに各タイプのレコードがいくつ作成されるか、N1、N2、N3...
  • 各レコード タイプのサイズ、S1、S2、S3...

編集：経験則が2倍であるインデックス係数を忘れました

1 日あたりの総成長 = 2*V * (N1*S1 + N2*S2 + N3*S3 + ...)

于 2009-03-02T00:28:01.857 に答える
0

従うべき私の経験則は次のとおりです。

  • 何人のユーザーが予想されますか?
  • 彼らはどのようなコンテンツを投稿できますか?
  • ユーザーレコードの大きさは？
  • ユーザーが追加できる各コンテンツ アイテムのサイズは?
  • いくら追加しますか？
  • それらのコンテンツ アイテムはどのくらい存続しますか? 永遠に？ほんの数週間？

ユーザー レコード サイズにユーザー数を掛けます。ユーザー数にコンテンツ アイテムのサイズを掛けた値を加算します。2倍します（便利なファッジ係数用）。

于 2009-03-02T00:30:05.067 に答える
-1

見積もりの​​コストは、ストレージのコストよりも大きくなる可能性があります

ほとんどのホスティングプロバイダーは、毎月末に使用される量で容量を販売しているため、そのまま実行してください

于 2009-03-02T00:26:53.433 に答える