database - 各クライアントに単一のデータベースを使用する利点は何ですか？

Question

複数のクライアント用に設計されたデータベース中心のアプリケーションでは、すべてのクライアントに単一のデータベースを使用する方が「良い」と常に思っていました。つまり、レコードを適切なインデックスとキーに関連付けます。Stack Overflowポッドキャストを聞いていると、JoelがFogBugzがクライアントごとに1つのデータベースを使用していると聞いた（したがって、1000のクライアントがある場合は1000のデータベースがある）。このアーキテクチャを使用する利点は何ですか？

一部のプロジェクトでは、クライアントがすべてのデータに直接アクセスする必要があることを理解しています。このようなアプリケーションでは、各クライアントが独自のデータベースを必要とすることは明らかです。ただし、クライアントがデータベースに直接アクセスする必要がないプロジェクトの場合、クライアントごとに1つのデータベースを使用することに利点はありますか？柔軟性の観点から、テーブルの単一のコピーで単一のデータベースを使用する方がはるかに簡単なようです。新しい機能の追加、レポートの作成、および管理が簡単になります。

Joel（経験豊富な開発者）が彼のソフトウェアは別のアプローチを使用していると言うのを聞くまで、私は「すべてのクライアントに1つのデータベース」の方法にかなり自信を持っていました。

多数のレコードがあるとデータベースの速度が低下すると言われていると聞きましたが、特に適切なインデックスとキーが使用されている場合は、メリットのあるリレーショナルデータベースでその問題が発生することはありません。

どんな入力でも大歓迎です！

Answer 1

すべてのクライアントを1つのデータベースに格納するためのスケーリングペナルティがないと仮定します。ほとんどの人にとって、そして適切に構成されたデータベース/クエリにとって、これは最近かなり真実です。あなたがこれらの人々の一人でないなら、まあ、単一のデータベースの利点は明らかです。

この状況では、各クライアントのカプセル化からメリットが得られます。コードの観点からは、各クライアントは分離して存在します。データベースの更新によって、別のクライアントに属するデータが上書き、破損、取得、または変更される可能性はありません。これにより、レコードが別のクライアントに属している可能性があるという事実を考慮する必要がなくなるため、モデルも簡素化されます。

また、分離可能性のメリットもあります。特定のクライアントに関連付けられているデータを取り出して、別のサーバーに移動するのは簡単です。または、組み込みのデータベースメカニズムを使用して、「いくつかの重要なデータを削除しました！」という呼び出しがあったときに、そのクライアントのバックアップを復元します。

簡単で無料のサーバーモビリティが得られます。1つのデータベースサーバーを拡張する場合は、別のサーバーで新しいクライアントをホストするだけです。それらがすべて1つのデータベースにある場合は、より強力なハードウェアを入手するか、データベースを複数のマシンで実行する必要があります。

簡単なバージョン管理が可能です。あるクライアントがソフトウェアバージョン1.0を使い続け、別のクライアントが2.0を必要とし、1.0と2.0が異なるデータベーススキーマを使用している場合、問題はありません。1つのデータベースからそれらを引き出すことなく1つを移行できます。

私はさらに数十を考えることができると思います。しかし、全体として、重要な概念は「シンプルさ」です。この製品は、1つのクライアント、つまり1つのデータベースを管理します。「しかし、データベースには他のクライアントも含まれている」という問題から複雑になることはありません。それは、彼らが一人で存在するユーザーのメンタルモデルに適合します。すべてのクライアントについて一度に簡単なレポートを作成できるなどの利点は最小限です。1つのクライアントだけでなく、全世界についてレポートを作成する頻度はどれくらいですか。

Answer 2

これは、私が以前に見たアプローチの1つです。

• 各顧客には、マスター顧客データベースに格納された一意の接続文字列があります。
• データベースは、データベースに単一の顧客が存在する場合でも、すべてが CustomerID によってセグメント化されるように設計されています。
• スクリプトは、必要に応じてすべての顧客データを新しいデータベースに移行するために作成されます。その後、その顧客の接続文字列のみを更新して、新しい場所を指すようにする必要があります。

これにより、最初は単一のデータベースを使用し、多数のクライアントを獲得した後、またはより一般的にはシステムを過剰に使用する顧客が 2 人いる場合に、後で簡単にセグメント化できます。

すべてのデータが同じデータベースにある場合、特定の顧客データを復元するのは非常に困難ですが、アップグレードの管理ははるかに簡単です。

顧客ごとに 1 つのデータベースを使用する場合、すべての顧客を同じスキーマ バージョンで実行し続けるという大きな問題に直面します。これは、多数の顧客固有のデータベースでのバックアップ ジョブを考慮していません。当然のことながら、データを復元する方が簡単ですが、レコードを完全に削除しないようにする (削除済みフラグを付けるか、アーカイブ テーブルに移動するだけ) と、そもそもデータベースを復元する必要が少なくなります。

Answer 3

シンプルにするために。クライアントが自分のデータだけを見ていることを確認できます。レコードが少ないクライアントは、データベースにはあるが自分のものではない数十万のレコードと競合しなければならないというペナルティを支払う必要はありません。すべてのレコードをスキャンする必要があると判断するクエリが存在する場合、すべてがどれだけ適切にインデックス化および最適化されているかは気にしません。

Answer 4

インポートジョブの失敗などが原因で、クライアントの1つが以前のバージョンのデータに復元するように指示した場合はどうなりますか？「データはすべてのクライアント間で共有されているため、それはできません」または「申し訳ありませんが、クライアントXがデータベースの復元を要求したために変更が失われた」と言った場合、クライアントがどのように感じるか想像してみてください。

Answer 5

一度に 1000 台のデータベース サーバーをアップグレードする手間は、かなり単純な自動化によって対処する必要があります。各データベースが同一のスキーマを維持している限り、実際には問題になりません。また、クライアントごとのデータベースアプローチも使用していますが、これはうまく機能しています。

これはまさにこのトピックに関する記事です (はい、これは MSDN ですが、テクノロジに依存しない記事です): http://msdn.microsoft.com/en-us/library/aa479086.aspx。

データ モデルに関連するマルチテナンシーの別の説明: http://www.ayende.com/Blog/archive/2008/08/07/Multi-Tenancy--The-Physical-Data-Model.aspx

Answer 6

スケーラビリティ。安全。当社は、お客様のアプローチごとに1つのDBも使用しています。また、コードの保守も少し簡単になります。

Answer 7

ヘルスケアなどの規制産業では、顧客ごとに 1 つのデータベースが必要になる場合があり、場合によっては別のデータベース サーバーが必要になることもあります。

アップグレード時に複数のデータベースを更新する簡単な方法は、アップグレードをトランザクションとして実行し、必要に応じてアップグレード前にスナップショットを作成することです。運用が順調に進んでいる場合は、任意の数のデータベースにアップグレードを適用できるはずです。

クラスタリングは、インデックスやテーブル全体のスキャンの問題を解決するものではありません。クラスターに移行しても、ほとんど変化はありません。複数のマシンに分散する小規模なデータベースが多数ある場合は、クラスターを使用せずにこれをより安価に行うことができます。信頼性と可用性は考慮事項ですが、別の方法で対処することもできます (クラスターが必要な人もいますが、大多数の人は必要ないでしょう)。

クラスタリングは単純なトピックではなく、RDBMS の世界では実装に費用がかかるため、これについてもう少し詳しい状況をお聞きしたいと思います。Google Bigtable などの非リレーショナルの世界でのクラスタリングについては、多くの話/虚勢がありますが、それらは別の問題を解決しており、RDBMS の便利な機能の一部を失っています。

Answer 8

「データベース」にはいくつかの意味があります

• ハードウェアボックス
• 実行中のソフトウェア (「オラクル」など)
• 特定のデータファイルのセット
• 特定のログインまたはスキーマ

ジョエルは下層の1つを意味する可能性があります. この場合、それは単にソフトウェア構成管理の問題です...たとえば、セキュリティ バグを修正するために 1000 台のソフトウェア サーバーにパッチを適用する必要はありません。

ソフトウェアのバグがクライアント間で情報を漏らさないようにするため、これは良い考えだと思います。あなたの顧客データだけでなく、私自身の顧客データも示した間違った where 句のケースを想像してみてください。