スケーラビリティ：数百万のテーブルと1つの大きなマスターテーブルおよび数百万のビュー
古い（100万LOC）システムをSAP ADS（以前のSybase）からISAMベース（いわゆるフリーテーブル）ベース）システムからPostgreSQLデータベースに移行する必要があります。
システムは、いくつかの基本情報（大臣ID、クライアントID、会計年度など）をWindowsフォルダーのパスにのみ入れることに関する一種のマルチテナンシーを実装し、 SQLステートメントはこれらを使用して、特定のテーブル（-files）の適切なパスでテーブルアドレスを作成します。
SAPはAdvantage Database Serverのサポートを終了することを決定したため、システムを別の（実際の）RDBMSに移行する必要があります。
少なくともPostgreSQLを使用することを決定しました。これは、これを複製するために使用できるものに少なくともWindowsフォルダーのパスをマップする一種の名前空間（スキーマ）をサポートするためです。
注意すべき大きなこと
ここではmultitenancyという用語を使用していますが、実際には次のようなものではありません。
- テナントのサブ情報スペースは、継続的に維持されるいくつかのマスターデータを共有します。
- メタデータモデル全体が、お客様のシステムにロールアウトされる特定のソフトウェアバージョンにバインドされている
- 私たちは現場に多くのさまざまな顧客システムを持っています（つまり、長期にわたって提供されたすべてのユースケースを追跡できませんでした）。
- 実際のコードの変更は、予期しない副作用に関してエラーが発生しやすい
- 全体として、私たちは Big Ball of Mud を持っています。これは、熱心な取り組みのためにリファクタリングのためのスペースをあまり残しませんが、法的要件のために継続的に適用される機能が必要です（税法は変わります）など）、または顧客（製品管理）の要求。
したがって、上記のことは、私たちが
- 既存の事実上のアプリケーションに影響を与えるような方法でデータベースをリファクタリングしたくない
- すべてのお客様のシステムインストール（単一のWindowsラップトップインストールから企業のWindowsファイルサーバーシステムまで）に適切に機能するデータベース設計のパスをとる必要があります
ローマへの主要な道
ATMでは、これを行う方法として2つの主要なアプローチについて説明しています。
- 特定のPostgresSQL
SCHEMAインスタンスにあるテーブルインスタンスへの各フォルダーに表示される既存のADSテーブルをPostgreSQLテーブルオブジェクトに移行します。 - 既存のADSテーブルをPostgreSQLmaster-tableオブジェクトに移行し、マスターテーブルに含まれるマッピングテーブルと参照キーを含むそれらのビューを作成します。これらの
SCHEMA名が一意のIDを使用してマップされる別のテーブル。
どちらのアプローチもすでに技術的にほぼ解決されており、既存のシステムをいずれかの方法で移行できます。
しかし、私たちが取るべき道を検討するポイントはまだあります。
- 一部のアーキテクトは、1つのマスターテーブルに数十億行あると、SQLステートメントのパフォーマンスに大きな影響を与える可能性があると直感しています。
- 他の人（私のような）は、ビュー/マスターテーブルモデルには、DB全体の設計効率に関していくつかの利点があると主張しています。
私たちはすでに測定を行っていますが、いくつかのアドバイス、おそらくいくつかの経験、あるいはDB設計のアイデアの他の選択肢についても聞きたいと思います。どのアプローチがより適切にスケーリングできるかについてです。
いくつかのエッジデータ：
- システム全体は現在、約1000の基本的なテーブル構造（+400の列フィールドを持つものもある）を維持しています。
- multitenancyパスが10.000までのお客様がいます。
- それらの（マスター）テーブルの一部は、数十億の範囲の行を維持する必要がある場合があります。
- インデックスは（一見）ADSでは安価であるため、既存のISAMテーブルで使用されるインデックスの多くが時々あります。
すでに気付いたこと：
- ビューと単一のテーブルオブジェクトを介してマスターテーブルに適用されるSQLステートメントのパフォーマンスへの影響は、データ行の量に応じた線形スケーリング（I '例示的な
EXPLAIN ANALYZEサーバ側）。 SCHEMAごとのテーブルの使用pg_catalogは大きくなる傾向があり、特にpg_catalog.pg_attributesテーブル。これらを使用して実行されるすべての操作（PostgreSQLクエリオプティマイザーを含む）は、膨大なビッグデータコンテンツに影響を受ける可能性があります。- 現在、すべてのテーブルに単一のテーブルスペースを使用しています。各仮想ディレクトリパスのテーブルスペースを整理することもできますが、これはDB設計を複雑にしすぎて、他の問題を引き起こす可能性さえあります。
- 前に述べたように、そのような量の関係のための単一のテーブルスペースは、PostgreSQLと基盤となるNTFS Windowsファイルシステムではうまく拡張できないようです。
- 基礎となるNTFSシステムに関しては、作成される各ファイル用に予約された最小ブロックサイズがあり、PostgreSQLは
pg_classrelationオブジェクト。テーブル、インデックス、BLOBフィールドなどが含まれます。
ここでの観察で私が提供したものは少し偏っていますが、代替案について、または私たちが議論しているこれらのモデルのいずれかについて絶対に行くことについて尋ねたいと思います。
私の上司は賢い人であり、彼は私がビューモデルをサポートする建築家の1人であることを知っているので、実際に短所を教えてくれる宿題としてくれました。
では、漠然としたアーキテクチャアドバイスを紹介します。
フォルダーをスキーマではなく単一のテーブルのインデックスと同等に考えるのは正しいと思います。
ただし、ビューを介して単一のテーブルにアクセスすると、問題が発生する場合があります。ビューでSQLを実行するのではなく、SQLステートメントを変更することを常にお勧めします。
次に、データのせん断量も問題になる可能性があります。パフォーマンスを維持するには、何らかの方法で分割する必要がある場合があります。
同じスキーマで複数のデータベースを作成し、データをテナントや日付で分割することで分割することをお勧めします。
これには、必要に応じて物理的に異なるハードウェアにデータを移動できるという利点があります。もちろん、デメリットは、スプリット全体で効果的にクエリを実行できないことです。
実際のテーブルを作成します。次に、実際に外部キー制約を適用し、実際にそれらを使用するエンティティのサブセットにのみ適用されるインデックスを作成できます。同時に使用する場合の競合を減らすことができます。 RDMSのメリットを実際に楽しむことができます...
* Unless *単一のテナントに対して単一のdbを小さく（数ギグ）維持できるようにデータをシャーディングできる、明確で独立したテナンシーがいくつかありますand使用パターンは、数ギグのデータに、いくつかの有用なインデックスと比較的少ない書き込みがあるようなものです。