顧客ごとにデータベースを作成すると、どのような問題が発生しますか？

stackoverflowポッドキャストから、Fog CreekはFogbugzの顧客ごとにデータベースを使用していることを覚えています。これは、Fogbugz On Demandサーバーに何万ものデータベースがあることを意味すると思います。

Webアプリの開発を始めたばかりで、同様の問題を解決する必要があります（独自の分離データを持つ多くの顧客）。

顧客ごとにデータベースを使用する場合、どのような問題が予想されますか？どうすれば解決できますか？

私の最初の考え

顧客ごとのデータベースの利点

• よりシンプルなデータベーススキーマ
• シンプルなバックアップ-他の顧客に実際に影響を与えることなく、各顧客を順番にバックアップできます。
• 特定の顧客データを簡単にエクスポートできます。
• キャッシュパフォーマンスの向上-よりアクティブなテーブルの1つへの書き込みは、書き込みを実行した単一の顧客にのみ影響します。
• ハードウェア全体で簡単に拡張できます。たとえば、1台から2台のサーバーに移動する必要がある場合、顧客の半分を新しいサーバーに移動するだけです。

欠点

• MySQLは5,000個のデータベースに対応できますか？パフォーマンスは低下しますか？
• スキーマへの変更は、すべてのデータベースに複製するのが難しい場合があります。スキーマのバージョン管理や、データベースをあるバージョンから別のバージョンに移行する方法を理解するスクリプトなど、このための自動化された計画が本当に必要になります。
• すべてのお客様に共通することを行うことは、厄介または不可能かもしれません
• 上記と似ていますが、すべてのお客様に対して実行したい分析は不可能かもしれません。たとえば、すべての顧客の使用状況をどのように追跡する必要がありますか？

このソリューションは、各テナント（顧客）が独自のデータベースを持つマルチテナントデザインと呼ばれます。それを考えると、単一のデータベースである代替アプローチには他のいくつかの考慮事項があります。

1. 単一のデータベースでは、誰もが何であれ同じバージョンを使用する必要があります。一部の顧客をアップグレードし、他の顧客をアップグレードすることはできません。顧客がワイドリリースの準備ができていないアプリケーションの修正プログラムを必要とする場合、これは問題になる可能性があります。
2. 単一のデータベースでは、アップグレードを行うと、すべてのクライアントがダウンします。問題が発生した場合、すべてのクライアントが台無しになります。
3. 単一のデータベースでは、リソースを調整することははるかに困難です。つまり、あるクライアントがデータベースを攻撃している場合、他のすべてのユーザーとは別により多くのリソースを提供することは困難です。
4. ユーザーがアプリケーションの独自のバージョンをホストできるようにすることははるかに困難です。大企業で使用されるソリューションを構築している場合、これは多くの場合スターターではありません。IT部門は、システムへのアクセスを完全に制御したいと考えています。
5. データベースをスケールアップするよりもスケールアウトする方がおそらく安価です。つまり、1つのデータベースをホストするためにより高速なハードウェアに投資してそれらすべてを支配することは、顧客を小規模で安価なデータベースサーバーにスケールアウトできるよりもおそらく高価です。サーバーソフトウェアに大きく依存するため、これを明確に言うことはできません。MySQLを使用している場合、ライセンスコストが無視できるため、これはおそらく正しいです。ただし、たとえばSQL Serverに移行する場合、VPS環境を使用しない限り、スケールアウトははるかに高価になり、スケールアップとスケールアウトの費用対効果は変化します。ただし、データベースが非常に大きくなると、管理にはさらに高度な専門知識が必要になります。非常に大規模なデータベースでは、パフォーマンスを向上させるために、複数のファイルグループで遊んで、特定のインデックスを異なるスピンドルにプッシュする必要があります。要するに、非常に迅速に複雑になります。

個別のデータベースがあるということは、データベースのバージョンをアプリケーション/サイトのバージョンと一致させる更新メカニズムを構築する必要があることを意味します。ただし、個別のデータベースはデータの優れた分離を提供し、IMOはホスティングのコストが低くなります。すべてのシナリオに対するソリューションではありません。システムがホスティングの外部でホストされることは決してなく、顧客の規模を急速に拡大する必要があり、すべてのユーザーが同じバージョンのアプリケーションとデータベーススキーマを使用することが望ましい場合は、確かに単一のデータベースを使用することをお勧めします。

私の経験では、顧客ごとに1つのデータベースを作成するべきではありません。例を挙げましょう。

昨年、私は70のデータベース（5000をはるかに下回る）で作業しました。それぞれが同じスキーマとすべてを使用していました。理論的には、物事は計画通りに進むでしょう（利点のセクションで述べたように）が、実際にはそれほどではありません。スキーマの更新、ユーザーサポート、ソフトウェアの更新に多くの問題がありました。ひどかった。

私たちはFirebirdを使用し、製品の出荷後に採用されましたが、これにより、分離されたデータベースを使用しないという知識が得られました。

私は私が言っている、あなたはそれをやってのけることができないとは言わないよ、物事は非常に間違って行くことができるあなたの利点のリストは、リスクを取るために十分に魅力的な音はありませんでした、と正直に言うと。それらのほとんどは、単一のデータベースで実現できます。

各顧客のバージョンを追跡するために別のデータベースを保持することをお勧めします。そのため、最後の変更が行われたかどうかを追跡できます。

アップグレードのスクリプトを作成するのはそれほど難しくありません...データベースのカタログを調べ、必要な変更を適用して各データベースを最新バージョンに更新するものを書くことができます。何らかの理由でアップグレードすべきでないものをスキップする可能性があります。

mysqlの「データベース」は単なるスキーマであるため、Gaiusが指摘したように、すべてが同じサーバーインスタンスから実行されている場合は、変更しようとしているテーブルの名前を修飾するか、情報を取得できます。

alter schema.table ...
select ... from schema.table

...

複数のサーバーに分割する場合でも、複数のサーバーに接続するスクリプトを作成して、すべての変更を適用できます。アナリティクスについても、マスターデータベースのフェデレーションテーブルを使用して多数のデータベースリンクを設定し、テーブルから読み取るだけであるため、1か所からデータにアクセスできます。

...

また、スタック交換にmySQLを使用しておらず、SQL Serverを使用していることに注意してください。

そして、その規模でmysqlにどのようなパフォーマンスオーバーヘッドがあるのか​​わかりません。mysqlで30を超える「データベース」を取得したことはないと思います。

同じ数のテーブル（162）と同じテーブル構造を持つ750以上の顧客データベースを持つWeb / DBホスティングクライアントがあります。合計すると、クライアントの顧客データはすべて合計524GB（95％InnoDB）になります

これらすべてのデータベースが、循環レプリケーションを介して9台のDBサーバーで13Gのinnodbバッファープールと競合することを想像してください。そのハードウェア構成でのスケールアウトは十分ではありませんでした。すぐに、クライアントにスケールアップすることをお勧めします。

最近、このクライアントを、はるかに高い処理能力を備えた3つのDBサーバーに移行しました（常に、書き込みの多い環境ではSSDに近づかないでください！MySQL 5.0.90からMySQL 5.5.9にアップグレードしました。劇的な違いはほとんど瞬時に見られました。

数百のクライアントが同じメモリとディスクリソースを使用している場合、スケールアウトは線形的に使用量を減らすため（O（n））、nはマルチマスター環境のDBサーバーの数に基づいているため、スケールアウトも考慮する必要があります。

クライアントの場合、私の会社は、MySQL 5.5の9台のDBサーバー（Quad Code、32GB RAM、824G RAID10）からより高速なDBサーバー（Dual HexaCore [12 CPU]）、192GB RAM、1.7TB RAID10）に減らしています。 .9（テーブルに複数のCPUを活用する）。さらに、各3GBの50パーティションに150GBのinnodbバッファープールを想定します（複数のInnoDBバッファープールはMySQL 5.5の新機能です）。クライアントの独自のインフラストラクチャでは、小規模なスケールアウトでありながら大規模なスケールアップが機能していました。

ストーリーの道徳：テーブルの設計が不適切な場合、スケールアップまたはスケールアウトが常に解決策とは限りません。つまり、インデックスページにマルチカラムインデックスの偏ったキー集団がある場合、インデックスの偏った部分からキーをクエリすると、テーブルスキャン後のテーブルスキャン、または少なくともMySQLクエリによって除外されたために使用されないインデックスになりますオプティマイザ。適切な設計に代わるものはありません。

MySQLはデータベースを個別のディレクトリに作成するため、基になるオペレーティングシステムと、処理できるフォルダ/ファイルハンドルの数に大きく依存します。最新のオペレーティングシステムでは問題になりませんが、そこから多くのボトルネックが発生します。

データベースまたはアプリの異なるバージョンをホストする必要があるということは何もありません。顧客ごとに1つのdbを実行し、データベースとアプリの1つのバージョンを使用してデータを分離するだけでは何が問題になりますか？もちろん、各顧客データベースは、現在の作業バージョンのテンプレートから複製する必要があります。セキュリティとデータ分離の観点から、これは理想的だと思います。

唯一の欠点は、新しいバージョンを作成するときに各データベースを手動で更新する必要があることです。ただし、これは簡単に自動化できます。