どのデータベースバックエンドを使用する必要があるかを知るために、Web アプリケーションデータを保存する際に従うべき一般的な経験則はありますか? 1 日あたりのヒット数、データの行数、または選択時に考慮すべきその他の指標はありますか?
私の最初の考えは、これの順序は次のようになるということです(ただし、必ずしもそうとは限りません。それが私が質問している理由です)。
- フラットファイル
- BDB
- SQLite
- MySQL
- PostgreSQL
- SQLサーバー
- オラクル
それほど簡単ではありません。唯一の一般的な経験則は、現在のソリューションが追いつかなくなったときに別のソリューションを探す必要があるということです。これには、異なるソフトウェア (グローバルに固定された順序である必要はありません)、ハードウェア、またはアーキテクチャの使用が含まれる場合があります。
別のランダム ストレージ バックエンドに切り替えるよりも、memcachedのようなものを使用してデータをキャッシュすることで、おそらくより多くのメリットが得られるでしょう。
ヘビーウェイト (SqlServer、Oracle) のいずれかが必要になると思われる場合は、最初にそれらのいずれかから開始する必要があります。データの移行は非常に困難です。長期的には、トップから始めてそこにとどまるほうがコストはかからないでしょう。
あなたのランキングは具体的すぎると思います。非常に小さなデータ セットの場合はフラット ファイルなどから始めて、SQL のような構文を必要としない少し大きなデータ セットの場合は DBM のようなものに進み、その後、ある種の SQL データベースに進むことができます。
しかし、誰がそのすべての書き直しをしたいですか? 結合、ストアド プロシージャ、トリガー、外部キー検証などへのアクセスがアプリケーションに役立つ場合は、データセットのサイズに関係なく、SQL データベースを使用してください。
どちらを選択するかは、保持しているデータの量よりも、クライアントの既存のインストールと利用可能な DBA スキルに依存する必要があります。
言い換えれば、データベースのサイズが唯一の考慮事項ではなく、おそらく最も重要な要素ではないということです。
これに対する包括的な答えはありませんが、ほとんどの場合、フラット ファイルを使用することはお勧めできません。それらを解析する必要があり(私は推測します)、それらはうまくスケーリングしません。Oracle や SQL Server (または無料のオプションを探している場合は MySQL、Postgres) などの適切なデータベースから始めることをお勧めします。オーバーヘッドがほとんどないため、後で多くの労力と頭痛の種を節約できます。また、愚かでない方法でデータを構造化できるため、データをどのように出し入れするかではなく、データをどうするかを自由に考えることができます。
それは実際にデータと、それをどのように使用するかによって異なります。私の以前のポジションの 1 つで、ポリゴン データ型を使用してデータを管理できるため、存在するネイティブの地理的位置とタイムゾーンの拡張機能により、Postgres を使用していました。私たちはそれを行う必要があり、ストアド プロシージャやビューなども使用したいと考えていました。
さて、私が働いていた別の場所では、データが正規化された標準的な行ごとのデータであるという理由だけで、MySQL を使用していました。
SQL Server には長い間 4 GB のデータベース制限がありました (SQL Server 2000 を参照)。しかし、その制限にもかかわらず、古いデータが消去される小規模から中規模のアプリケーションにとって非常に安定したプラットフォームであり続けています。
現在、Oracle と SQL Server 05/08 を使用して作業した結果、安定性、スケーラビリティ、および柔軟性の最高峰が必要な場合は、これら 2 つが最善の策であると言えます。エンタープライズ アプリケーションの場合は、それらを強くお勧めします (単に、私が現在働いている場所で使用しているためです)。
その他の考慮事項:
この質問は本当にあなたの状況に依存します。
展開先のサーバーを制御でき、必要なサービスをインストールできる場合は、MySqlまたはMSSQL Expressサーバーをインストールし、既存のデータベースフレームワークに対してコーディングするのと、フラットファイル構造に対してコーディングするのは時間の価値がありません。検討の。
アプリケーションによるデータベースの使用率は、最も重要なものです。主にどのクエリが最も頻繁に使用されますか (SELECT、INSERT、UPDATE)?
SQLite を使用している場合、それは小さなアプリケーション向けのギアですが、「Web」アプリケーションの場合は、MySQL や SQL Server のような大きなものかもしれません。
スクリプトの書き方と Web アプリケーション プラットフォームも重要です。Microsoft プラットフォームで開発している場合は、SQL Server の方が優れた代替手段です。
また、ソリューションの「顧客」も備えなければならない要件を忘れないでください。小規模企業向けの商用アプリケーションを作成する場合、Oracle は適切な選択ではない可能性があります... しかし、複数のキャンパス間でデータを共有する必要があり、適切な規模の IT 部門を持つ大企業向けにカスタマイズされたソリューションを作成する場合は、 Oracle と Sql Server のどちらを選択するかは、顧客がすでに展開している可能性が最も高いものに帰着します。
Embarcadero の優れたツールがあるため、現在のデータ移行はそれほど悪くはありません。代わりに、顧客のニーズに応じて決定を下すことができます。
ファイアーバードはどうですか?それはそのリストのどこに当てはまりますか?
通常、使用しているフレームワークで一般的に受け入れられているものを使用します。したがって、.NET => SQL Server、Python (Django または Pylons 経由) => MySQL または SQLite を実行している場合。
ただし、フラットファイルはほとんど使用しません。
「バックエンドの馬力」だけで RDBMS ソリューションを選択することには、さらに多くの意味があります。たとえば、失敗したトランザクションをロールバックできるようにコミットメント制御を行う機能はその 1 つです。理由。
メガトランザクション レートのアプリケーションでない限り、ほとんどのデータベース エンジンで十分です。そのため、ソフトウェアにいくら払いたいか、必要なハードウェアとオペレーティング システム環境で実行できるかどうか、どのような専門知識を持っているかが問題になります。そのソフトウェアの管理において。
オプションがある場合は、SQL Server が最適です。これは主に、堅実な手順と機能にアクセスでき、データベースのバックアップ機能が完全に信頼できるためです。(使用している言語ではなく) データベース自体の内部にできるだけ多くのロジックをまとめると、セキュリティとパフォーマンスが向上します。インジェクション攻撃を受けにくい。
選択肢があるとすれば、MySQL を優先して検討するのは、主に読み取りアクセスに使用される大規模でかなり単純なデータベースを使用する場合だけです。これは、最近著しく改善された MySQL を非難するものではなく、選択の余地がない場合は喜んで使用しますが、更新/挿入アクティビティを伴うより複雑なシステムでは、一般に MSSQL が優れたオプションです。
その進行は苦痛に聞こえます。MS 製品 (特に有料の SQL Server) をどこかに含める場合は、スタック全体を使用することもできます。
SQL Server Compact -> SQL Server Express -> SQL Server Enterprise (clustered).
最初に SQL Server Compact でアプリを対象とする場合、すべての SQL コードは変更なしで次のバージョンにスケールアップすることが保証されます。SQL Server Enterprise よりも大きくなった場合は、おめでとうございます。それは彼らが持つべき良い問題と呼ばれるものです。
また、戻って SO ポッドキャストを確認してください。彼らはこれについて簡単に話したと思います。
あなたのリストは主観的だと思いますが、私はあなたのゲームをプレイします.
フラットファイル
BDB
SQLite
MySQL
PostgreSQL
SQLサーバー
オラクル
テラデータ