顧客ごとにデータベースを作成すると、どのような問題が発生しますか？
Fog CreekFogbugz の顧客ごとにデータベースを使用することを、stackoverflowポッドキャストから覚えています。これは、Fogbugz On Demandサーバーに数万のデータベースがあることを意味します。
Webアプリの開発を始めたばかりで、同様の問題を解決する必要があります（多くの顧客が独自の分離データを持っています）。
顧客ごとにデータベースを使用する場合、どのような問題が予想されますか？どうすれば解決できますか？
私の最初の考え
顧客ごとのデータベースの利点
- よりシンプルなデータベーススキーマ
- よりシンプルなバックアップ-他の顧客に実際に影響を与えることなく、各顧客を順番にバックアップできます。
- 特定の顧客データを簡単にエクスポートできます。
- キャッシュパフォーマンスの向上-よりアクティブなテーブルの1つへの書き込みは、書き込みを実行した単一の顧客にのみ影響します。
- ハードウェア全体での拡張が容易です。たとえば、1台から2台のサーバーに移動する必要がある場合、顧客の半分を新しいサーバーに移動します。
欠点
- MySQLは5,000のデータベースに対応できますか？パフォーマンスは悪いのでしょうか？
- スキーマへの変更は、すべてのデータベースにわたって複製するのが難しい場合があります。実際には、スキーマのバージョン管理や、データベースをあるバージョンから別のバージョンに移行する方法を理解するスクリプトなど、自動化された計画が必要です。
- すべてのお客様に共通することを行うと、不便または不可能になる場合があります
- 上記と同様ですが、すべてのお客様に対して実行したい分析は不可能になる可能性があります。たとえば、すべての顧客の使用状況をどのように追跡する必要がありますか？
このソリューションはマルチテナント設計と呼ばれ、各テナント（顧客）は独自のデータベースを持っています。そのため、単一のデータベースである別のアプローチには、他にもいくつかの考慮事項があります。
- 単一のデータベースでは、何があっても全員が同じバージョンでなければなりません。一部のお客様のみをアップグレードすることはできません。これは、顧客が幅広いリリースの準備ができていないアプリケーションの修正プログラムを必要とする場合に問題になる可能性があります。
- 単一のデータベースでは、アップグレードを実行すると、すべてのクライアントが停止します。何かがうまくいかない場合、すべてのクライアントが台無しにされています。
- 単一のデータベースでは、リソースを調整することははるかに困難です。つまり、1人のクライアントがデータベースを攻撃している場合、他のすべての人から分離したリソースを増やすことは困難です。
- ユーザーが自分のバージョンのアプリケーションをホストできるようにすることははるかに困難です。大企業で使用されるソリューションを構築している場合、これは多くの場合、重要なことではありません。彼らのIT部門は、システムへのアクセスを完全に制御したいと考えています。
- データベースをスケールアップするよりもスケールアウトする方が安上がりです。つまり、1つのデータベースをホストしてそれらすべてを統治するために、より高速なハードウェアに投資する必要があることは、顧客をより小規模でより安価なデータベースサーバーにスケールアウトできるよりもおそらくコストが高くなります。これは、サーバーソフトウェアに大きく依存するため、断定できません。 MySQLを使用する場合、ライセンスコストはごくわずかであるため、これはおそらく本当です。ただし、たとえばSQL Serverに移行した場合、VPS環境を使用しない限り、スケールアウトのコストははるかに高くなり、変更によるスケールアップとスケールアウトの費用対効果が大きくなります。ただし、データベースが非常に大きくなると、管理にはこれまでにないレベルの専門知識が必要になると言えます。非常に大規模なデータベースでは、パフォーマンスを向上させるために、複数のファイルグループを試し、特定のインデックスを異なるスピンドルにプッシュする必要があります。要するに、彼らは非常に速く複雑になることができます。
別のデータベースがあることは、データベースのバージョンをアプリケーション/サイトのバージョンと一致させる更新メカニズムを構築する必要があることを意味します。ただし、個別のデータベースはデータの優れた分離を提供し、IMOはホスティングのコストが低くなります。すべてのシナリオに対応できるわけではありません。システムがホスティングの外部でホストされることはなく、顧客を迅速にスケールアップする必要があり、すべてのユーザーが同じバージョンのアプリケーションとデータベーススキーマを使用することが望ましい場合は、単一のデータベースを使用することをお勧めします。
私の経験では、顧客ごとに1つのデータベースを作成するべきではありません。例を挙げましょう。
昨年私は70のデータベース（5000をはるかに下回る）を使用し、それぞれが同じスキーマとすべてを使用していました。理論的には、（利点のセクションで説明したように）計画どおりに進みますが、実際にはそれほどではありません。スキーマの更新、ユーザーサポート、ソフトウェアの更新に関して多くの問題がありました。それはひどかったです。
私たちはFirebirdを使用しており、製品の出荷後に採用されましたが、これにより、別々のデータベースを使用しないでください。
私はあなたがそれを引き出すことができないと言っているわけではありません、私は物事は非常にうまくいかない可能性がありますと言っています。それらのほとんどは、単一のデータベースで実行できます。
別のデータベースを保持して各顧客のバージョンを追跡したい場合があるため、最後の変更が行われたか、行われていないかを追跡できます。
アップグレードのスクリプトを作成することはそれほど難しくありません...データベースのカタログを調べ、必要な変更を適用して各データベースを最新バージョンにして、何らかの理由でアップグレードしてはならないものをスキップするようなものを書くことができます。
Mysqlの「データベース」は単なるスキーマなので、Gaiusが指摘したように、すべてが同じサーバーインスタンスから実行されている場合は、変更しようとしているテーブルの名前を修飾するか、次の情報を取得できます。
alter schema.table ...
select ... from schema.table
...
複数のサーバー間で物事を分割し始めた場合でも、複数のサーバーに接続するスクリプトを作成して、すべての変更を適用できます。分析の場合も、マスターデータベースで federated tables を使用して一連のデータベースリンクを設定し、テーブルから読み取るだけなので、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サーバー（クアッドコード、32GB RAM、824G RAID10）からより高速なDBサーバー（デュアルHexaCore [それはまさに12 CPU]、192GB RAM、1.7TB RAID10）に減らしています。 .9（表では、複数のCPUを利用しています）。さらに、それぞれ3 GBの50パーティションに150 GBのinnodbバッファープールがあるとします（複数のInnoDBバッファープールはMySQL 5.5の新機能です）。小規模なスケールアウトですが、大規模なスケールアップが、クライアントの独自のインフラストラクチャで機能していました。
ストーリーのモラル：不適切に設計されたテーブルがある場合、スケールアップまたはスケールアウトは常に解決策とは限りません。つまり、インデックスページにマルチカラムインデックスのキー集団が偏っている場合、インデックスの偏った部分からキーをクエリすると、テーブルスキャン後にテーブルスキャンが発生するか、少なくともMySQLクエリによって除外されているために使用されないインデックスが発生します。オプティマイザ。適切な設計に代わるものはありません。
MySQLは個別のディレクトリにデータベースを作成するため、基になるオペレーティングシステムと、それが処理できるフォルダー/ファイルハンドルの数に大きく依存します。最新のオペレーティングシステムでは問題になりませんが、ボトルネックの多くはそこから発生します。
異なるバージョンのデータベースまたはアプリをホストする必要があるということは何もありません。顧客ごとに1つのdbを実行し、1つのバージョンのデータベースとアプリを用意するだけでデータを分離することの何が問題になっていますか？もちろん、各顧客データベースは、現在の作業バージョンのテンプレートから複製する必要があります。セキュリティとデータ分離の観点から、これは理想的だと思います。
私が目にできる唯一の欠点は、新しいバージョンを作成するときに各データベースを手動で更新する必要があることです。これは簡単に自動化できます。