1つのSQLサーバーに配置できるデータベースの数に制限はありますか？

私は、各顧客に独自のデータベースを提供することを計画しているSaaSシステムをセットアップしています。システムは既に設定されているため、負荷が大きくなりすぎた場合に追加のサーバーに簡単にスケールアウトできます。数千、または数万の顧客を獲得したいと考えています。

ご質問

• 1つのSQL Serverで使用できる/する必要があるマイクロデータベースの数に実際的な制限はありますか？
• サーバーのパフォーマンスに影響はありますか？
• それぞれ100 MBのデータベースを10,000個、または1 TBのデータベースを1つ持つ方が良いでしょうか？

追加情報

「マイクロデータベース」と言うとき、「マイクロ」という意味ではありません。私たちは数千の顧客を対象にしているので、個々のデータベースは合計データストレージの1000分の1以下になります。実際には、取得する使用量に応じて、各データベースは100MB程度になります。

10,000個のデータベースを使用する主な理由は、スケーラビリティのためです。事実、システムのV1には1つのデータベースがあり、DBが負荷のかかったときに不快な瞬間がありました。

CPU、メモリ、I / Oに負担をかけていました-上記のすべて。これらの問題を修正したにもかかわらず、ある時点で、世界で最高のインデックス作成を行っていても、望みどおりに成功した場合、すべてのデータを1つの大きなホンキンに入れることはできないことに気付きました'データベース。したがって、V2ではシャーディングを行っているため、複数のDBサーバー間で負荷を分散できます。

昨年、このシャードソリューションの開発に費やしました。サーバーごとに1つのライセンスですが、AzureでVMを使用しているので、とにかく面倒を見てくれます。疑問が生じた理由は、以前は大規模な機関にのみ提供し、各機関を独自に設定していたためです。私たちの次のビジネスは、ブラウザを持っている人なら誰でもサインアップして自分のデータベースを作成できるセルフサービスモデルです。彼らのデータベースは、大規模な機関よりもはるかに小さく、はるかに多くなります。

Azure SQL Database Elastic Poolsを試しました。パフォーマンスは非常に残念でした。そのため、通常のVMに切り替えました。

1つのインスタンスで8〜1万のデータベースを使用するSQL Serverで作業しました。それはきれいではありません。

サーバーの再起動には1時間以上かかる場合があります。10,000個のデータベースの回復プロセスについて考えてください。

SQL Server Management Studioを使用して、オブジェクトエクスプローラーでデータベースを確実に見つけることはできません。

バックアップを行う価値があるためには、実行可能なディザスタリカバリソリューションを用意する必要があるため、バックアップは悪夢です。うまくいけば、あなたのチームはすべてのスクリプトを書くのが得意です。

M01022、およびなどの番号を使用してデータベースに名前を付けるなどの作業を開始しますT9945。たとえば、M001022ではなく、正しいデータベースで作業していることを確認しようとすると、気M01022が散ることがあります。

その多くのデータベースにメモリを割り当てるのは大変な作業です。SQL Serverは最終的に大量のI / Oを実行しますが、これはパフォーマンスに大きな影響を与える可能性があります。10,000社の4つのテーブルにまたがる炭素使用の詳細を記録するシステムを検討してください。1つのデータベースでこれを行う場合、必要なテーブルは4つだけです。10,000個のデータベースでそれを行うと、突然メモリ内に40,000個のテーブルが必要になります。メモリ内のその数のテーブルを処理するオーバーヘッドは相当なものです。これらのテーブルに対して実行される設計するクエリでは、10,000個のデータベースが使用されている場合、プランキャッシュに少なくとも 10,000個のプランが必要です。

上記のリストは、そのような規模で運用する際に計画する必要がある問題のほんの一部です。

おそらく、SQL Serverサービスの起動に非常に長い時間がかかるなど、サービスコントローラーエラーが発生する可能性があります。自分でサービスの起動時間を延長し、次のレジストリエントリを作成できます。

サブキー：HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control
名前：ServicesPipeTimeout
タイプ：REG_DWORD
データ：サービスの起動中にタイムアウトが発生するまでのミリ秒数

たとえば、サービスがタイムアウトするまで600秒（10分）待つには、600000と入力します。

私の答えを書いて以来、私は質問がAzureについて話していることに気付きました。おそらく、SQLデータベースでこれを行うことはそれほど問題ではありません。おそらくより問題があります。個人的には、おそらく単一のデータベースを使用してシステムを設計し、おそらく複数のサーバーにまたがって垂直に分割しますが、顧客ごとに1つのデータベースは設計しません。

したがって、両方の方法には長所と短所があります。アプリケーションや提供しようとしているサービスについて詳しく知ることなく、明確な答えを出すことはできませんが、この問題に関する私の考えの一部を捨てます。

すべてのクライアントに1つのデータベースを使用する必要がある理由の私のケース。

長所

• 簡単なメンテナンス。1つのDBがあるということは、多数ではなく1つの場所でメンテナンスタスクを実行するだけで済むことを意味します。バックアップする1000の異なるデータベースを処理する悪夢を想像してください。1000 DBの統計の更新やインデックスの再構築はDBCC CHECKDBどうですか？

• コードの展開。アプリケーションコードまたはレポートのストアドプロシージャに問題があるとしましょう。簡単に変更する必要があります...次に、その変更を1000以上のDBに展開する必要があります。いいえ、ありがたいです。

• 簡単な可視性。SSMSが1000以上のDB （シャダー）を開こうとしているところを想像してください。問題を事実上役に立たなくし、S​​SMSを開いてレンダリングするのに驚くほどの時間がかかります。念頭に置いて、それはあなたがまともな命名規則を思い付くことができるかどうかです。

短所

• セキュリティ。別のDBとして持っていれば、他の顧客のデータを他人のデータから見ることを防ぐ方が簡単です。ただし、これを防ぐためにできる非常に簡単なことがいくつかあります。

• パフォーマンス。顧客ごとに1つのDBに制限することは、クエリする情報を取得するためにSQLサーバーがスキャンする必要のあるデータが少ないことを意味すると主張できます。ただし、適切なデータ構造と適切なインデックス作成（および可能なパーティション分割）を使用すると、慎重に行うと、問題としてこれをすべて排除できる可能性があります。顧客固有のデータを含む各テーブルに何らかのCompanyIDオーバーヘッドを与えて、そのオーバーヘッドを減らすことをお勧めします。

最終的には、アプリケーション用に1つのDBを用意し、DB自体の内部で顧客データを分割するのが最善策だと思います。1000以上のデータベースを管理するという悪夢と比較して、それがもたらすトラブルは何もありません。

SQL Serverの最大容量仕様には、32,767の制限があると記載されています。

パフォーマンスに影響を与えるかどうかについては、答えは「はい」ですが、パフォーマンスに影響する方法、およびそれが実質的であるかどうかは、無数の要因に依存します。

10,000のデータベースに分割する正当な理由がない限り、1つのデータベースを使用します。1つのバックアップまたは10,000のバックアップ？1つの整合性チェック、または10,000？10,000個の小さなDBを使用する正当な理由があるかもしれませんが、それを決定するのに十分な詳細を与えていません。あなたが尋ねた質問は非常に広範であり、誰もが最良の答えが何であるかを知るには十分な情報がありません。

何がここで話していることで、マルチテナント VS マルチインスタンスのアーキテクチャ。質問では使用しないので、これらの用語を取り上げますが、これはあなたが議論しているものです。「マルチテナントアーキテクチャ」をGoogleにプラグインするだけで、豊富なリソースと議論が見つかります。それについては、本全体が書かれています。

SQL Serverに関するいくつかの優れたリソースはここにあります。

https://msdn.microsoft.com/en-us/library/ff966499.aspx

https://docs.microsoft.com/en-us/azure/sql-database/sql-database-design-patterns-multi-tenancy-saas-applications

マルチインスタンスを支持する説得力のある理由がない限り、デフォルトとしてマルチテナントに強く傾倒するという点で、他の答えがあります。

数千の個別のクライアントデータベースに分割してスケーリングする必要はありません。他の多くの方法がありますが、これは望ましい方法です。クラスタリング、複製、シャーディング、パーティション分割など。車輪を再発明しないでください。個々の顧客レベルでこれを手動で分割する必要があると言う固有のことは何もありません。実際にそうすると、すべての新しい顧客を追加するコストが大幅に増加する可能性があります。

あなたは「何百万人もの」顧客について話している、大規模なクラウドベースのソフトウェアをサービス、Gmailなどと考えて、新しいサインアップごとにまったく新しいデータベースを作成するとは思わないでしょうか？

たとえば、自社のインフラストラクチャで社内でホストする必要がある顧客に製品を販売している場合など、これを促進したい理由があります。ただし、一般的なSAASルールとして、デフォルトとしてマルチテナントアーキテクチャを使用します。

単一データベースの提案の欠点の1つは、データをロールバックすることです。テナントごとにデータベースを設定している場合、各クライアントのデータを個別に（および特定の時点に）復元できます。それらがすべて1つのデータベースにある場合、これははるかに困難になります（INSERT / UPDATE / DELETEステートメントを使用して行う必要があるため、エラーが発生しやすくなります）。

答えてくれたすべての人に感謝します-あなたが考えてくれた点に本当に感謝します。私が得た一般的な感覚は、単一のデータベースが望ましいということでしたが、断片化されたアーキテクチャに有利ないくつかの相殺点を追加し、他の人が言及した懸念のいくつかに対処したいと思います。

シャーディングの動機

（更新された）質問で述べたように、私たちは文字通り何百万人ものユーザーを抱える世界的な大規模な販売を目指しています。世界最高のハードウェアとインデックス作成機能により、1台のDBサーバーで負荷がかかることはないため、複数のサーバーに分散できる必要があります。また、特定の顧客のデータがどのサーバーにあるかを調べる必要がある場合、専用のデータベースを用意するのはそれほど労力ではありません。

懸念への対応

• サーバーの再起動には長い時間がかかります。OKですが、通常の運用ではサーバーを再起動するつもりはありません。システムは最終的に24時間365日オンラインである必要があるため、ダウンタイムが発生する場合は、とにかくスケジュールする必要があります。
• バックアップ/災害復旧：すべてを自動化するCloudBerryを使用しています。問題ない。
• データベースの命名/ SSMSでの検索：命名規則は簡単で、顧客名に基づいているだけです。名前が共有されている場合は、シリアル番号を追加します。
• メンテナンス：各データベースが私が想像するほど小さい場合、手動でインデックスを再構築する必要はないはずです。
• コードのデプロイ： Entity Frameworkを使用しているため、新しいリリースでは、すべてのスキーマの変更が自動的に各データベースに展開されます。しかし、実稼働環境で単純なインデックス調整で修正できるパフォーマンスの問題を発見した場合、そこにプッシュするだけではそれほど簡単ではないことは事実です。一方、各データベースが非常に小さいため、プロダクションシャードのパフォーマンスが著しく低下する可能性はほとんどありません。そして、共通データベースは単一のDBのままであり、これらの懸念は適用されません。

あなたが私が何かを見逃していると思うなら、コメントであなたから返事をうれしく思います！