database - 非常に大きなデータセットを持つ関連付けられたテーブルの妥当なクエリ時間はどれくらいですか?

Question

StackOverflow ポッドキャストでは、No . 19で、Joe は、すべてのクライアントに対して 1 つのデータベースではなく、クライアントごとに 1 つのデータベースを持つという Fogcreek の決定について説明しています。それはちょっと私に次のことを考えさせます。

1. 1000 人のユーザーがいると仮定します。
2. 各ユーザーには100 個のクライアントがあります。
3. 各クライアントには1000 個の製品があります。

つまり、1000 x 100 x 1000 = 100,000,000 個の製品がユーザーに関連付けられることになります。ここで、あるユーザーとそのクライアントのすべての製品に対して結合テーブル クエリを実行する場合、この目的のために 1 つのデータベースのみを使用すると、妥当なクエリ時間はどれくらいになるでしょうか?

アップデート

たぶん、私の質問は十分に明確ではありませんでした。上記で説明したように、データセットを使用してあらゆる種類のファンキーなクエリ (最小、最大、グループなど) を実行する必要があると仮定すると、複数のデータベース戦略を使用する方が理にかなっている点まで遅い (またはそうでない) でしょうか。 . 1 DB/クライアント、データベース シャーディングなど

Answer 1

クライアントごとに 1 つのデータベース戦略を採用する主な理由は、セキュリティと管理のしやすさです。100 個のクライアント固有の DB ではなく、単一のデータベースでのバックアップ/復元の概念は効果的ですが、いくつかの欠点もあります。共有データベースの問題には次のようなものがあります。

• ユーザーは、他のユーザーのデータを参照できないようにする追加のセキュリティ手段 (ビューなど) がなければ、データベースから直接報告することはできません。機密データの場合、これはコンプライアンスの問題にもなります。

• アプリケーション全体でセキュリティ モデルを認識する必要があるため、ある程度の複雑さが増します。繰り返しになりますが、機密データの場合、これにはコンプライアンスへの影響があります。

• ある顧客のデータに関係するシステム メンテナンスまたはサポート チケット タスクには、エラーが他のデータに影響を与えるリスクがあります。

複数のデータベースの固有の区分化により、アプリケーションが簡素化され、エラー、構成ミス、およびセキュリティの問題のクラス全体が排除されます。自動化された構成管理と複数の環境への展開に適したアプリケーションを構築すると、複数のインスタンスでも保守がかなり簡単になります。

さらに、あなたが説明しているデータ量とレポートの種類を考えると、レポートを本番サーバーから移動する何らかのレポート サブシステムまたはデータ マートを構築する方がよい場合があります。この種の分析レポートは、トランザクション データベースで使用する正規化されたスキーマのタイプよりも、スター スキーマではるかに効率的です。

Answer 2

答えは、選択した DBMS によって異なると思います。たとえば、Oracle の場合、1 つの大きなデータベースが望ましいことは間違いありません。

また、ユーザー間でクエリを実行する必要はありませんか? たとえば、最も多くの製品を持っているユーザーを見つけます。それとも、これらは本当に 1000 の個別の「プライベート」データベースであり、誰もデータへの全体的なアクセス権を持っていないのでしょうか? それでも、たとえば Oracle は、単一のデータベースでこれに対応する「仮想プライベート データベース」を提供しています。

Answer 3

フィルタリングや集計を行わずに、すべての列と行を取得したい場合は、非常に長い時間待たなければなりません。ここでベンチマークとして使用できる妥当な時間はないと思います。あなたはただ待つ必要があります:)

ただし、これらのタイプのクエリはめったに発生しません (データを移行する場合を除きます - まだ代替手段があります)。通常は、行のサブセット、行のページ、列の選択、または集計が返されます。この場合、「妥当な金額」は、クエリの種類と関連する計算によって異なります。

Answer 4

ほとんどの場合、PK の一部としてユーザーやクライアントを含める必要があるため、マルチテナント シナリオでのパフォーマンスは、シングルテナントの場合と大きく異なる影響を受けません。