1つの大きなデータベースといくつかの小さなデータベース

（A）テーブルプレフィックスを使用して1つのMySQLデータベースにアプリケーションのインスタンスをデプロイするか、（B）アプリケーションの各インスタンスに異なるMySQLデータベースを使用できる状況があります。たとえば、

セットアップ「A」：

central_database
  app1_table1
  app1_table2
  app1_tablen
...
  appn_table1
  appn_table2
  appn_tablen

最終結果は、多くのテーブルを持つ大きなデータベースになります。

セットアップ「B」：

app1_db
  table1
  table2
  tablen

...

appn_db
  table1
  table2
  tablen

最終結果は、いくつかのテーブルを持つ多くのデータベースになります。

すべてが等しい（データの量、アプリインスタンスの数など）、どちらのアプローチを採用する場合の長所と短所は何ですか？データベースのパフォーマンスとメンテナンスに有害なものは何ですか？アプリケーションはPHP 5ベースで、Apache 2.xで実行され、MySQL 5.xを実行しています。

あなたの時間と考えに感謝します！

私は、複数のサーバーに分散した、1000のデータベースの最良の部分でシステムを実行しました。これらはすべて同一の構造であり、各マシンにあるテンプレートデータベースと同期されました。

これにより、データベースが過度に過負荷になった場合にデータベースを別のdbに移行することができ、クライアントミックスが変更されると、異なるサーバーに新しいデータベースを作成して、サーバー間で負荷を分散できました。これはシステムから得た最大の利点でした。複数の複雑なクエリを別々のサーバーで同時に実行する複数の大きな塊があったからです。

これの素晴らしい点は、各サーバーが過負荷になり始め、ミックスに別のサーバーを追加し、いくつかのデータベースを新しいサーバーに移行し、うまくいくように、自分の速度でサーバーを構成に追加できることです。サーバーの負荷分散セット。必要なときにシステムにスケールを追加する、本当に素晴らしく簡単な方法です！

単一の巨大なデータベースアプローチではなく、このアプローチを採用した理由は、作成される可能性のあるデータベースのサイズが大きかったためです。1000個のデータベースにはそれぞれ200個のテーブルがあり、データベースは何億ものデータ行で構成されていました！

単一のデータベース構成では、特定のテーブル（約8個）に数十億行のデータが必要であり、dbの合計サイズは10Tbを超えていました。5TbのRAID 10ストレージを備えた複数のサーバーがあり、それぞれに多くのデータベースがありました。

それが私がすることです！それがあなたの意思決定に役立つことを願っています... :)

構築しているアプリケーションはSaaSアプリケーションですか？その場合、3番目のアプローチを検討することをお勧めします-1つのDBを持ち、すべてのアプリケーションインスタンスに共通の構造を持ち、1つの違いがあります-すべてのテーブルにuserid / applicationid列を追加します。これにより、アプリケーションの開発/保守コストが大幅に削減されます。私の経験では、これはマルチテナントデータを保存するための最良のアプローチの1つです。

マルチテナントデータアーキテクチャに関するMicrosoftのこの素晴らしいホワイトペーパーも参照してください。

また、あなたが言及したアプローチの利点/欠点を強調しています。

セットアップBは管理がずっと簡単です

それぞれtablenが異なるフォルダーにあります。OSの制限をテストしたくない場合、これは非常に有益です。

たとえば、私の雇用主は自動車ディーラーのCRMシステム用にMySQLをホストしています。クライアントは800のディーラーを持っています。各ディーラーデータベースには、160のテーブルがあります。これは128,000のテーブルです。

• セットアップAでは、128,000のテーブルすべてが1つのデータベースの下に置かれます。
• セットアップBでは、160個のテーブルの各セットが/ var / lib / mysqlの下のサブフォルダーにあります。

OSおよびiノード（Windowsの場合はFATテーブル）を処理する機能の観点から、これにはフォルダーごとの最大ファイル数が含まれます。

• セットアップAでは、1つのフォルダーの下に約128,000個のファイルがあります。お使いのOSは、1つのフォルダーの下にある多くのファイルをサポートできますか？
• セットアップBでは、そのような心配はありません。

ALTER TABLEまたは他のDDL を使用してテーブル構造をtweekする必要がある場合：

• セットアップAでは、特定のテーブル名とそれに対応するクエリに対して、アクセス（変更）する前に、PHP（または特殊なMySQLスクリプト）を使用して必要なDDLのスクリプトを作成する必要があります。
• セットアップBの下で、正しいデータベースに接続し、毎回同じ名前のテーブルにアクセスします。アクセスパラダイムは常にクリーンです。
  • 特定のデータベース
  • 特定のフォルダの下 /var/lib/mysql
  • 固有のテーブル名。

異なるデータベースを異なるディスクに配置する場合：

• セットアップAでは、別のディスクに移動されたすべてのテーブルのシンボリックリンクは、「フォルダー内のiノードの数」問題のみを悪化させます。ディスクI / Oおよび全体的なテーブルアクセスはさらに複雑になり、.frmファイルに繰り返しアクセスするため、サーバー全体の負荷が増加します。
• セットアップBで、データベースフォルダー全体を別のデータマウントに移動するだけです。ディスクI / Oはオンデマンドで配布できます。
• 警告：InnoDBには強くお勧めしません

比phor的に言えば、どちらがいいですか？

• ベッドルーム1つ、バスルーム1つ、キッチン1つを備えた巨大なアパートメント（SetupA）
• それぞれが寝室、バスルーム、キッチンを備えた複数のアパートメント（SetupB）

アパートのラジエーターの修理に関しては：

• セットアップAでは、すべてのテナントが不便であり、関与する必要があります。これは、すべてのビジネスのように、影響を受けるテナントと全員の前で話し合う必要があるためです。
• セットアップBを使用すると、テナントが壁やパイプで叩く音を聞く以外に、私生活を続けることができます
• このリストとその比phorは延々と続く

IHMO予算は、設計/インフラストラクチャの決定を推進する原動力となる可能性がありますが、クライアントごとにデータベースを分離することは簡単です。

また、SaaS製品を所有しており、Dave Rixが言及したのと同じセットアップを使用しています。

各顧客には独自のデータベースがあります

私はさらにいくつかの提案をしたいと思います：

• データベースの場所（ip）、データベース名、顧客名を保存する、負荷分散されたデータベース（コントローラー）が必要です（マスターマスター）。このコントローラーは、アプリケーションが各顧客データベースの場所を認識する場所です。

• アプリケーションは好きな場所に配置できます。世界中の多くのデータセンターにデータベースを配置できます。

• アプリケーションは必要なだけ拡張できます。Web SaaSの場合、顧客がログインするときと同じように、各データベースを指す負荷分散されたWebサーバーファームを作成できます。

• 他のユーザーに影響を与えることなく、一部の顧客向けにカスタマイズされたVIEW /データベースを作成できます。ビジネスの一部としてカスタマイズを提供しようとする場合、それは重要です。

• 2つのWebファームとデータベースファームをセットアップできます。1つは「EDGE」リリース用、もう1つは「STABLE」リリース用です。次に、すべての顧客に適用する前に、物事をテストし、すべてが期待どおりに機能していること（つまり、品質保証[QA]）を喜んで確認する少数の顧客グループが必要です。

• 少なくとも1日に1回は、データベースごとに自動バックアップジョブが必要です。

• 複製を行うには別のサーバーが必要です。同じ量の「マスター」および「スレーブ」ホストサーバーを確保できない場合、同じホストで多くのデータベースを複製できます（同じホストのサーバーごとに異なるポートを使用します）。

  たとえば、5つのマスターサーバー+ 5つのデータベースが異なるポートで実行されている1つのスレーブサーバー-十分なRAMがあれば十分です。

• 「移行」ツールを使用して、必要なときにいつでも1つのデータベースを別のサーバーに移動する必要があります。

• 収益を保護するには、VIPのお客様をより安全で利用可能なデータベースサーバーに移行する必要があります。多くの場合、顧客の20％が収益の80％を占めています。特別な顧客の世話をします。

• 「最後のバックアップ」を行い、顧客が退職したときにデータベースを削除するには、バックアップ削除「ガベージ」コレクターが必要です。

• 新しいアカウントにエクスポートして使用するデータベースイメージが必要です。

• 既存のアカウントに新しいパッチを適用するには、データベースパッチツールが必要です。

• subversionやgitなどのバージョン管理ツールを使用して、すべてのSQLパッチのバージョンを保持し、独自の番号付けも作成します。xxx-4.3.0.sql-パッチ適用がうまくいかない場合があり、パッチ適用タスクを回復/完了する方法を知っておく必要があります。

さて、これは私の会社で、それぞれ約600個のテーブルを持つ約5,000個のデータベースを持つ製品を使って行うことです。