データベースサイズの見積もり

Question

データベースサイズの見積もりの​​観点から、新しいアプリケーションを開発するときに何をすべきかと思いました。

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

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

私のジレンマは、私のWebアプリケーション（この段階でのコスト）のためのホストされたソリューションに向いていることです。十分なSQL Serverスペースを購入しないことで自分自身を撃てたくはありませんこれに対するプレミアム）。

Answer 1

データベーススキーマをお持ちの場合、サイジングはかなり簡単です。推定される行*各テーブルの平均行サイズ*インデックスのいくつかの要因*オーバーヘッドのその他の要因。今日のストレージの値段が非常に低いということを考えると、トラフィックが非常に多い（または大企業向けのアプリを構築する）場合を除き、サイジングは問題ではありません。私自身のサイジングの演習のために

、私は常にExcelスプレッドシートのリストを作成しました：

• COL 1：
• COL 2成長する各テーブル：バイト単位で推定列のサイズを
• COL 3 ：（アプリケーションに応じて年またはMAXあたり、）行の推定＃
• COL 4：指数因子（私は常に2に設定し）
• COL 5：オーバーヘッド因子（私は常に1.2に設定し）
• COL 6：総カラム（COL 2 X 3 X 4 X 5）

COL 6（全列）の合計、プラス成長テーブルなしのデータベースの初期サイズ、あなたのサイズの推定値です。あなたはもっと科学的になることができますが、これは私の素早く汚い方法です。

Answer 2

推定のコストはそうちょうどそれが実行してみましょう、

ほとんどのホスティングプロバイダは、各月の終わりに使用ammountで容量を販売するストレージのコストよりも大きくなる可能性が高い

Answer 3

決定します。

• どのように多くの日あたりの訪問者は、各タイプのレコードが訪問ごとに作成されますどのように多くのV
• 、N1、N2、N3 ...
• トン各レコードタイプ、S1、S2、S3の彼大き...

EDIT：親指の良いルールは一日= 2 * Vの*あたり2回

総成長である指数因子（N1を忘れてしまいました* S1 + N2 * S2 + N3 * S3 + ...）

Answer 4

私の経験則がある従うこと

• 私はどのように多くのユーザーを期待していますか？
• 投稿できるコンテンツは？
• ユーザーレコードはどのくらいですか？
• ユーザーが追加できるコンテンツアイテムの量はどれくらいですか？
• どのくらいですIを追加しますか？
• これらのコンテンツアイテムはどれくらいの期間生存しますか？永遠に？ほんの数週間？

乗算ユーザレコードサイズユーザの倍の数;コンテンツアイテムのサイズを乗じたユーザーの数を追加します。 （便利なファッジファクタのために）2を掛けます。