やあ、
アプリケーションをSAASに準拠させる必要があります。マルチテナンシーを実現するために、データをパーティション化することでした。各パーティションはテナント用になります。このパーティショニングは動的に実行されます。
誰かがこのようなことをしましたか?より良いアプローチは何だと思いますか?
SQL2005を使用しています
よろしくDEE
やあ、
アプリケーションをSAASに準拠させる必要があります。マルチテナンシーを実現するために、データをパーティション化することでした。各パーティションはテナント用になります。このパーティショニングは動的に実行されます。
誰かがこのようなことをしましたか?より良いアプローチは何だと思いますか?
SQL2005を使用しています
よろしくDEE
パーティション スキームごとに 1000 個のパーティションの制限があり、1 つのフィールドでのみパーティション分割できます。そのため、1000 を超えるインスタンスをマルチテナント化する場合は、さらに多くのフープをジャンプする必要があります。複数のパーティション分割されたテーブル上でパーティション分割されたビューを使用して制限を拡張できますが、これにより管理オーバーヘッドが増加します。DMV を使用して、クライアント/テナントごとに新しいパーティションを生成し、問題を管理する独自の自動化システムを作成できますが、それはアプリケーション固有のものであり、一般的なものではありません。
現在、SQL Server には自動動的パーティション分割はありません。SQL Azure の将来のロードマップに関連して PDC09 で言及されていましたが、SQL Server については聞いていませんでした。
別の選択肢は、クライアントごとにデータベースまたは SQL インスタンスです。このアプローチには、必要に応じてスケールアウトする機会がはるかに多くなるという利点があります。また、より大きなデータ センターを検討し始めると、サーバー ファーム全体の SQL インスタンスなど。単一のデータベースにすべてのデータを自動的に格納する場合。
その他の考慮事項:
セキュリティ: パーティション化された単一のデータベースにデータがありますが、データ保護はありません。コード内のバグが 1 つでもあるだけで、あるクライアントのデータを別のクライアントに公開する危険があります。
アップグレード: すべてのクライアントが同じデータベースにアクセスする場合、アップグレードは全か無かのアプローチになります。一部のユーザーを新しいバージョンに簡単に移行し、他のユーザーをそのままにしておくことはできません。
バックアップ: 各パーティションに個別のファイル グループを占有させ、状況の管理を試みることができます。いわば、箱から出してすぐに、すべてのクライアントのバックアップが混在しています。1 つのクライアントが特定のデータへのロールバックを要求した場合、システムの他のユーザーに影響を与えずにロールバックを実行する方法を事前に慎重に計画する必要があります。