50.000以上のショップで1つのデータベースを使用するのは良い考えですか？

Shopifyがすべてのショップに対して1つのデータベースのみを使用することを知っています。しかし、そのようなビッグデータを使用してデータベースをどのように処理できるでしょうか。50.000以上のショップで単一のデータベースを使用することは良い考えですか？

注：SQL Serverの観点から回答しているので、SQL Serverに固有のいくつかの概念について説明しますが、これらのすべての概念には、他の主要なRDBMSプラットフォームにも同等の利点と制限がある同等のものがあると思います。

他の潜在的な長所/短所について考えるとき、私はおそらくこの回答の編集も続けるでしょう。

まあ、それは本当にスキーマ、ボリュームなどに依存します。ショップのストアとは正確には何ですか？猫50,000点、製品50,000点、ハチミツ50,000点のデータを保存するのとどう違うのですか

実際にデータを顧客ごとに完全に分離できる場合（郵便番号などのルックアップテーブルやアプリケーション固有のテーブル。単一の中央データベースに入れることができます）：

• ある顧客がアプリケーションを超えた場合、事前に計画CustomerIDして50,000などのファイルグループを作成し、50,000個のファイルグループを用意しない限り、データだけを抽出して別のインスタンス、サーバーなどに移動してスケールアウトする簡単な方法はありません（制限されています）とにかく15,000パーティションに、またはSQL Serverの古いバージョンを使用していて、ファイルグループが多すぎると悲惨な場合があります）。また、パーティショニングにはEnterprise Editionが必要です。

• すべての顧客がこのインスタンスに対して単純に大きすぎることが判明した場合、スケールアウトとは、新しいハードウェアを入手し、そこにデータベース全体を移動することです（そして、将来的にはそれを再度行う可能性があります）。

• 非常に大きなテーブルから行の数％を削除する必要があるため、顧客を削除することも同様に痛みを伴う可能性があり、それは安くはありません。

• おそらく、顧客データが広範囲に分布します（10億行の顧客と5,000人の顧客）。これにより、パラメーターのスニッフィングや、カーディナリティとプランの品質に関連するパフォーマンスに悪影響を与える可能性があります（非常に異なるデータセットに対して同じクエリに対して同じプランを再利用する可能性があるため）。

• すべての顧客は、まったく同じSLAおよびHA / DRプランの対象となります。n分のログバックアップを使用してデータベース全体を完全復旧モードにするか、単純でフル+差分バックアップに依存しています。顧客のエラーのために元に戻す必要がある場合、またはデータベースを特定の時点に回復する必要がある場合は、すべての顧客に影響します。

• データ取得でエラーが発生する可能性があります。たとえば、where句のバグにより、ある顧客が別の顧客のデータ、または他のすべての顧客のデータを表示する可能性があります。

• 法的影響がある場合があります（一部の企業では、他の企業と同じデータベース、特に競合他社のデータベースにデータを配置しないという厳しい要件があります）。

• ある顧客のデータのセキュリティが重要である場合、それを達成することは、テーブル内の分離よりもデータベースの分離を使用する方がはるかに簡単です。

各顧客を個別のデータベースに配置する（または、少なくとも顧客のグループごとに複数のデータベースを配置する）ことのいくつかの利点：

• サイズに関しては、ディスク上でほぼ同じサイズになります。
• データベース（または多数）を別のサーバーに移動するだけでよいので、スケールアウトが簡単です。
• 顧客とそのすべてのデータを削除することは、ほぼに相当しDROP DATABASEます。
• プラン用により多くのメモリを使用している（または顧客ごとのキャッシュ内のプランが少ない）が、少なくともそれらのプランはそれぞれのデータベース内のデータに関連しており、統計/パラメータースニッフィングの問題が発生しにくい。
• さまざまなSLAとDRプランを簡単に作成でき、一部のデータベースを完全に配置し、他のデータベースを単純に配置できます。また、特定の時点に復帰または復元すると、その顧客にのみ影響します。
• より高速なI / Oにさまざまなデータベース（たとえば、優先度の高い顧客）を簡単に配置できます。ファイルグループを使用して単一のデータベースでこれを行うこともできますが、これは管理が非常に困難です（少なくともIMHO）。

いくつかの欠点：

• サイズはさておき、SQL Serverの単一のインスタンスに50,000のデータベースを配置したくないので、これはおそらく複数のサーバーにスケールアウトすることを意味します。
• 各データベースの起動には固有のオーバーヘッドがあるため、起動時間が長くなります。
• アプリは少し賢くする必要があります-where句にCustomerIDを置くだけでなく、CustomerIDのデータベースに動的に接続する必要があります。これは適切な中間層では難しくありませんが、変更です。
• はい、同じテーブルとプロシージャのコピーが多数ありますが、コードとスキーマはデータベース間で同じですが、データが異なるだけです。したがって、コード/スキーマの変更のデプロイは、単一の実行ではなく、単なるループになりました。
• 50,000のデータベースを管理している場合、メンテナンスは少し異なります。全体のサイズはほぼ同じですが、プロセスを変更する必要があります。50,000のデータベースすべてを一度にデフラグ/再インデックス付け/バックアップすることはできません。とはいえ、以前の仕事では500〜1,000の同一データベースでインスタンスを管理しました。3つの同一データベースと750の同一データベースの管理の違いは、単にかかる時間です。