むかしむかし、数階の大きさのコンピューターがあり、複数のオペレーターが1台の強力なコンピューターで作業していました。 その後、この技術の奇跡はデスクトップサイズにまで縮小し、すべての家庭に搭載することができました。 繰り返しになりますが、「クラウドコンピューティング」はイノベーションと見なされています。うーん、すべては複数の端末と1つの強力なコンピューターデータセンターに帰着します。 さて、Googleデータセンターがラップトップのサイズに縮小されるまで待ちましょう...
はじめに
2000年以降、頭字語SaaS（サービスとしてのソフトウェア）という用語は、開発者、設計者、顧客、およびITに関連する他の多くの人々の生活に入りました。 SaaSの本質は、請負業者がソフトウェアを開発し、サーバーに配置し、そのパフォーマンス、セキュリティ、顧客の可用性（通常は複数）を維持し、サーバーおよびその他の費用を自然に支払うことです。
クライアントはサービスの使用に対して支払いを行い、サーバーの購入と保守については考えません。 このアプローチは、クライアントにとってより安価であり、請負業者に利益をもたらします（ライセンスと著作権侵害の問題を解決し、最も重要なことに、1つのサービスを複数のクライアントに提供できるため）。 ただし、クライアントは請負業者を信頼する必要があります。 彼のデータはすべて遠く、遠くにあります。
当然、そのような決定により、データの配置と分離の分野で妥協を模索しました。
例なしで何かを伝えることは非常に問題があるので、抽象的な問題を考えてください。
挑戦する
- 競争するためにニュースをフォローする必要がある大企業がいくつかあります。
- ニュース-インターネット全体に散らばる情報。
- サービスとして、特定の方法でインターネット上で必要な情報を収集し、データベースに保存して、クライアントに表示できるようにするシステム。
- 一定期間（6か月から1年）後、データはアーカイブに転送されます（メインデータベースから削除されます）。
クライアントにとって、このようなシステムの利便性は明らかです。会社の従業員がシステムに入り、より有益で便利な作業に必要なすべてのデータを確認します。 請負業者は、開発されたシステムの不正使用を心配することはできません。最も重要なことは、タスクが同じであるため、このシステムを複数のクライアントで同時に使用できることです。データベース構造も同じです。 そして、ここで決定木が分岐しますが、それについては後で詳しく説明します。
合計：データベースに書き込みおよび読み取りを行い、お互いについて何も知らない顧客が何人かいます。 それらを互いに分離し、ハードウェアとソフトウェアを効果的に使用する必要があります。
解決策：マルチテナント
さまざまな顧客のデータを共有するために思い浮かぶ最初のソリューションは、さまざまなデータベースに格納されます（分離アプローチ）。 別の方法として、追加フィールドTenantIDを入力して1つのデータベースにすべてのデータを保存し、それらを区別することができます（一般的なアプローチ）。 ロジックの二重性にもかかわらず、2つのソリューションではなく、それ以上がありました。 この事実は、msdnから借用した写真に非常に説得力を持って示されています。
異なるデータベース
このソリューション-最初に思い浮かぶのは、データ共有の最も単純な実装です。
このアプローチでは、コードはクライアント間で共有され（共通のUIファイルとビジネスロジックが使用されます）、データは論理的に（場合によっては物理的に）共有されます。
利点：
- 単純な拡張性（クライアントを追加するには、新しいデータベースを作成して構成ファイルを構成するだけです）。
- シンプルなスケーリング-異なるクライアントのデータベースを別々のサーバーに配布できます。
- 個性-一部のクライアントに対して個別の設定を行うことができます（データベースを別のDBMSに配置することもできます）。
- 簡単なデータバックアップ-データベースのロールバック中に他のクライアントで何かが壊れた場合、他のクライアントはアクセスしません。
短所：
- 高価な とても高い。 サーバーごとにサポートされるデータベースの数は限られています。つまり、このようなソリューションでは（すべてが1つのデータベースに格納される方法とは異なり）より多くの鉄、より多くの鉄-より多くの管理者、サーバー領域、電気料金が必要になります。
- 高価な 再び高価です。 1つのサーバーに複数のデータベースがあり、その合計量がRAMを超える場合、データはページファイルにダンプされるため、ハードディスクにアクセスしますが、これは非常に遅いです。 方法として-サーバーを追加購入します。
その結果、高価格にもかかわらず、これはセキュリティが主な目標であり、支払いを希望する顧客（銀行など）にとって最も適切なソリューションです。
共通データベース、異なるスキーム
そこで、すべてを1つのデータベースに保存することにしました。追加のTenantIDフィールドを導入せずにどのように保存するのでしょうか。 さまざまなクライアントからの情報をさまざまなテーブルに保存します。 このメソッドを実装するには、 スキーマが役立ちます 。 本質的に、スキーマは特定のリソース（テーブルなど）を含む「名前空間」であり、特定のアクセス許可を付与できます。
利点：
- スキームのおかげで、アクセス共有はDBMSレベルで行われ、追加の開発は必要ありません（工数を節約します）。
- データベースの削減-ハードウェアリソースの削減、節約。
- 優れた拡張性-クライアントを追加するときに、標準スキームに基づいて新しいスキームを作成し、アクセスを設定すれば完了です。 すべてのスキームは標準に基づいているという事実にもかかわらず、いくつかの変更を受ける可能性があります。 分離は保持されるため、列、テーブルなどを編集できます。
短所：
- それでも、データは一緒に保存され、論理的に分離されています。
- データベースは同じであるため、バックアップとリカバリの問題は、あるクライアントからのテーブルが飛んだ場合、データベースの単純なロールバックはすべての顧客のデータを過去に戻しますが、これは受け入れられません。 古いデータと新しいデータを選択的にロールバックし、マージする必要があります。手順は、データベース全体をロールバックするよりも少し複雑です（ある日、RAIDミラーで2本のネジがほぼ同時に死んだとき、私はこれを自分の経験で感じました。デッドスクリューから...）;
結論として、顧客が隣に住むことをいとわない場合、このオプションは非常に効果的です。 以前のバージョンよりも多くのお客様が1台のマシンで解決できるようになります。
一般的なデータベース、一般的なスキーム
3番目のオプションは、すべてを1つのデータベースと共通テーブルに保存することです。 このオプションを実装するための前提条件は、顧客間で情報を共有するための追加フィールドTenantID（または必要に応じてCustomerID）の導入です。
利点：
- 安価で、すべてが1つのテーブルセットに格納されます。
- クライアントの追加とは、単にクライアントテーブルに新しいレコードを作成することです。
短所：
- 柔軟性はありません。すべてのクライアントが1つのテーブルと列のセットを使用します。 個人主義のクライアントの外観-松葉杖とパッチの前兆;
- 独自の権利分離システムを開発するために工数と神経を費やした。
- バックアップと復元では、これは本当に惨事です。前のアプローチでテーブル全体を削除して復元できた場合、1つのテーブルで必要なレコードを探して上書きする必要があります。
合計で、クライアントが多く、サーバー（お金）が少ない場合、およびすべてのハードドライブが同時にミラーを使用していない場合は、このアプローチが最適です。
厳しい現実
誰もが最初のオプション（異なるデータベース）を購入できるわけではないため、共通のデータベースでオプションを使用するのが最も便利です。 しかし、この方法では、いくつかの予期しない驚きを待っています。
したがって、最も安価なオプションを有効なオプションとして選択します。 私たちの拠点が落ちていないと想像し、ハードドライブは永遠です。 そして今、私たちのシステムは1年間正常に機能しており、誰もが満足し、ギガバイトのデータが蓄積され、突然すべてがゆっくりと動作し始めます。 DBMSはブラックボックスではなく、設定する必要があります。 問題はありふれています-データは1つのテーブル、1つのファイルに書き込まれます。つまり、データは次々にハードドライブに到達します。 1台のクライアントでデータがどのようにサンプリングされるか想像してみましょう。ハードドライブのヘッド（SSDハードドライブのファンは私を許してくれます）がバッファ内のすべてをゆっくりと読み取り、必要なTenantIDのレコードがすぐに表示されない場合があります。 ここで、あるクライアントのデータをアーカイブに転送する必要があることを想像してください（データベースにデータを削除します）。
あなたが言うインデックス？ -私は高価だと言います。 さらに、インデックスが存在する場合でも、データはディスクの異なる部分に残ります。
パーティショニングと呼ばれるDBMSのエンタープライズバージョンで利用できる非常にエレガントなソリューションがあります。その本質を図に見ることができます。
パーティショニングを使用すると、あるクライアントのデータは、他のクライアントとは別の場所に順番に配置されます。 簡単にするために、各クライアントのデータは個別の論理ドライブにあると想定できます。 この機能はDBMSレベルでサポートされているため、ドライバーを作成して車輪を再発明する必要はありません。
追記
この記事は翻訳ではありませんが、当然ながらマルチテナントの本質を概説する英語の情報源があります。
関連リンク：
www.developer.com/design/article.php/3801931
msdn.microsoft.com/en-us/library/aa479069.aspx
msdn.microsoft.com/en-us/library/aa479086.aspx
D.スルコフに感謝 およびDMinsky （これらは異なるDmitriyです）
追記後
この機会を利用して、今年の金曜日、金曜日のほとんどの金曜日に皆さんにお祝いを申し上げます。