SaaS データベース設計 - 複数のデータベース?スプリット？
https://stackoverflow.com/questions/69128
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian質問
私は、SaaS アプリケーションがさまざまな方法でホストされているのを見てきました。機能とモジュールを複数のデータベースに分割することは良い考えですか?たとえば、User テーブルを 1 つの DB に配置し、機能/アプリ固有のテーブルを別の DB に配置し、おそらく他の一般的に共有されるテーブルを別の DB に配置しますか?
解決
1 つのデータベースから始めます。プロジェクトで必要な場合はデータ/機能を分割します。
LinkedIn から学べることは次のとおりです。
- 単一のデータベースでは機能しない
- 参照整合性は不可能になります
- データ損失が問題になる
- 効果がそれほど高くない場合でも、キャッシュは有効です
- 成長軌道を決して過小評価しないでください
ソース：
他のヒント
高い拡張性 SaaS アプリケーションのスケーリングに適したブログです。前述したように、提案したようにテーブルをデータベース間で分割することは一般的に悪い考えです。しかし、同様の概念はシャーディングです。シャーディングでは、同じ (または類似の) スキーマを保持しながら、データを複数のサーバーに分割します。たとえば、ユーザー 1 ～ 5000 はサーバー 1 に存在し、ユーザー 5000 ～ 10000 はサーバー 2 に存在します。アプリケーションが使用するクエリによっては、スケーリングの効率的な方法となる場合があります。
SaaS アプリケーションの場合、複数のテナントに対して複数のデータベースを使用しますが、通常はモジュールごとに分割しません。
これは、SaaS アプリケーション設計で私が見た中で最も一般的なモデルです。基本スキーマは、アプリケーションに追加するテナントごとに複製されます。
単一データベースを使用すると、外部キーを使用できるため、データの整合性を保つのに最適です。データを複数のデータベースに分割すると、この組み込みのデータ整合性を確保することはできません。データが関連していない場合は問題ありませんが、関連している場合は、あるデータベースに別のデータベースと矛盾するデータが含まれる可能性があります。この場合、データベースを定期的にスキャンして一貫性のないデータを検出し、適切に処理できるようにするコードを作成する必要があります。
ただし、サイト/アプリケーションのスケーラビリティを高める必要がある場合は、複数のデータベースが必要になる場合があります (例:インターネットスケール）。たとえば、各データベースを異なる物理サーバーでホストできます。
必要性を示唆する強力な証拠が見つからない限り、データベースを機能ごとに分割することは良い考えではないかもしれません。多くの場合、単一のトランザクションの一部として 2 つのデータベースを更新する必要がありますが、分散トランザクションの操作ははるかに困難です。さらに、データベースを分割する必要がある場合は、シャーディングを使用できる場合があります。
これを実現するにはさまざまな方法がありますが、マルチテナントの問題は単なるデータ モデルよりもさらに深くなります。製品に問題を起こすのは嫌いですが、チェックしてください SaaSグリッド 私が働いている会社によって、 アプレンダ.私たちは、アプリにマルチテナントを自動的に注入するシングルテナント SOA アプリ (データ アクセスには NHibernate を自由に使用してください) を作成できるクラウド オペレーティング システムです。アプリを公開するときに、データ モデル (分離データベースまたは共有) を選択するなどの操作を行うと、それに応じて SaaSGrid がデプロイされ、コードを変更することなくアプリが実行されます。単一のテナント用であるかのようにコードを記述するだけです。
そもそもなぜデータベースを使用するのでしょうか?
Hadoop、Voldemort (LinkedIn が開発および使用している project-voldemort.com) などの分散ストレージ システムを使用するのが良いと思います。
お金の操作などの機密性の高いデータには db が適していると思いますが、それ以外の場合は分散ストレージを使用できます。
自問してみてください：すべてを個別のデータベースに移動すると、何が得られるのでしょうか?
経営面ではかなりの苦労があったと思います。私は個人的には、すべてを 1 つのデータベースにまとめておき、後で 1 つのデータベースでは解決できない問題に遭遇した場合に、データを複数のデータベースに移行することを望んでいます。
自然な設計を維持します (必要なだけ非正規化し、必要なだけ正規化します)。DB モデルをモジュールに分割し、データの先頭にサービス (データを所有する) を置くことでサービス指向の原則を念頭に置きます。
