4

現在、各ユーザーがデータベースを取得するシステムがあります。現在、1 つのデータベースのマルチテナント スキーマに移行しているため、1 つのデータベースで多くの顧客を収容できます。

いくつかの質問：

  1. マルチテナント変換ツールは存在しますか? それとも、テーブルを作成し、他のすべてのテーブルにTenantを追加するだけのプロセスですか?TenantID

  2. データベースと通信するコードをリファクタリングせずにマルチテナントを実装する簡単な方法はありますか?

    データベースとのやり取りをすべて行うOdata.svcがあります (フロント エンド クライアントは、.net フロントエンドから iOS デバイスにまで及びます)。フェデレーションを使用して述語のフィルタリングを実行する方法について少し読んだtenantIDので、コードをまったく変更する必要はありません。これは可能ですか？

  3. データベースに含める必要があるテナントの数に推奨される制限はありますか?

私はこれがばかげた質問であることを収集しています (文字列の長さはどれくらいですか)。Azure で最終ソリューションをホストする可能性が最も高いでしょう。

誰でもできるアドバイスをお待ちしております。私たちはプロセスに根本的な変更を加えているので、下に落ちる前にそれを上回りたいと思っています.

4

2 に答える 2

3

オートメーション？

理論的には、この困難な操作 (シングルテナントからマルチテナントへの移行) をはるかに簡単に実行できるツールを作成できるはずです。ただし、そのような製品の対象者が限られていることを考えると、そのようなツールは存在しないと思います。1つでも浮かび上がってくれたら最高です。

手動変換に関するアイデア

新しいマルチテナント データベース スキーマを設計することから始めます。(これは、すべてのシングル テナント データベース スキーマを、所有している可能性のある共有スキーマとマージすることを意味します。) 従来の考慮事項なしで設計された場合のようにしたいと思います。

明らかにTenantテーブルが必要です。これは、列を持つ既存のシングル テナント テーブルの多くによって参照される必要がありTenant_idます。たとえば、ユーザーを含むテーブルでは、ユーザーをテナントに一意に関連付けるためにこれが必要になります。

単純なProductsテーブル (主キーとして) の場合、列を追加して、複合キー (および)を持つテーブルを生成Product_idできるはずです。しかし、ゼロからアプリケーションを作成した場合は、テナント参照のないテーブルが適切な方法だと思います。これにより、重複を追加する代わりに、テナントが製品を共有することもできます。1つのテナントがTenant_idTenant_idProduct_idProductProduct_id1,2,3 と別の 1,2 では、同じ ID を 2 回使用できないため、単純にテーブルをマージすることはできません。一意の主キー値が必要です。この問題を解決する 1 つの方法は、テナント データベースからすべてのデータをメモリ内オブジェクトに読み取り、そのデータをマルチテナント スキーマに書き込むプログラムを (Java またはその他の高水準言語で) 作成することです。このプロセスは、次のテナント データベースに対して繰り返されます。そうすれば、Product_id値は 1,2,3,4,5 になります。手っ取り早い方法は、各スキーマのすべての ID 値に 1,000、2,000 などの数字を追加し、競合が発生しないことを確認することです。

データベースと通信するコード

データベースがマルチテナントになったことを考慮して、ほとんどのデータベース クエリを書き直す必要があります。これは、あるテナントが別のテナントのデータをいじることを可能にするバグを導入することの影響を考えると、非常に困難な作業です。ただし、いくつかのテクニックを使用すると、このタスクをより簡単に行うことができます。たとえば、テナント ビュー フィルターを使用すると、必要な作業量を大幅に削減できます。

テナント数の制限

マルチテナント構造でテナント数を制限するという推奨事項は見たことがありません。反対に、マルチテナント アプローチの強みは、そのスケーラビリティです。現在、データベース サーバーのクラスターを簡単に作成したり、クラウドベースのソリューションを使用して、必要に応じてハードウェアの能力をシームレスに追加したりできます。

興味のあるリンク

于 2012-09-25T13:21:14.240 に答える
2

正直なところ、私の経験では、これを自動化することはできません。非常に重要なデータをインフラストラクチャからデータ モデルに移動しています。すべてのクエリは、テナントが既に確立されていることを前提に記述されています。したがって、すべてのクエリと SP は、テナント テーブルを参照するように変更され、パラメータ化されます。

第 1 四半期に、各テーブルにテナント ID を追加するだけかどうかを尋ねます。それは 1 つのアプローチですが、私が推奨するものではありません。これにより、誤ったデータを持つ可能性が大きくなります (子が親と同じテナント ID を持っている、またはそれらがすべて同じであるという強制はありません!) テナント テーブルを確実に追加してから、必要なテーブルを慎重に選択する必要があります。それを参照してください。それはすべての人ではありません。必要になるものもあれば、パフォーマンス上の理由からそこに置くことを選択するものもあります。後者を選択した場合、データを意味のあるものに保つために追加のチェック メカニズムが必要になることは間違いありません。

Oracle を使用している場合、できることは、各テーブルをビューに作り直し (上記のすべてを引き続き行う)、tenantID をセッションに詰め込み、その上で細粒度アクセスを実行して、ほとんどの詳細を非表示にすることです。クライアント。ただし、うまく行うのは難しく、SQL Server の同等物が何であるかはわかりません。研究する価値があるかもしれません。

DB をマージする理由は何ですか? クロスDBレポートか何かが必要ですか？それ以外の場合、単一テナントには多くの利点があります (複数のアップグレードとダウンタイムのスケジュール、[非]正規化の方法に応じてパフォーマンスが向上する可能性がある、単一テナント データの抽出/レポートの容易さ、テナントを失った場合の削除の容易さ)。ここでは、クラウド ソリューションとシングル テナントが有利に働く可能性があります。

于 2012-01-23T02:37:41.727 に答える