1

gnu tar に基づく LTO バックアップ/復元ソリューションを開発しています。テープを社内に保管するか、顧客がこれらのバックアップを購入する可能性があります。したがって、特定のバックアップ ソリューションではなく、広く利用可能な無料のソリューションを選択する必要があります。お客様がどのような種類のバックアップ ソリューションを使用しているかわからないためです。

バックアップするデータは簡単に数百万ファイルを超える可能性があり、ファイル レベルの復元用のカタログを作成する必要があります。また、同じプロジェクトに対して、複数の年にわたる作業にまたがる複数のバックアップ セットを用意することができます (顧客は今年プロジェクトを開始し、バックアップが必要で、2 年後に戻ってきて、さらに作業を行う場合があります。新しいバックアップが必要です）

カタログ テーブルはわずか数か月で非常に大きくなるため、このテーブルの管理方法を考える必要があります。パーティションがこれを助けることができると思いました。ただし、パーティショニング (またはその他のソリューション) は、日付に基づくのではなく、プロジェクトに基づく必要があります。時間が経つにつれて、パーティションの数が問題になるのではないかと心配しています。

データベースのテーブル構造は次のようになります。

  • プロジェクト (ID、名前など...)
  • ジョブ (ID、ジョブ名、プロジェクト ID など...)
  • テープ (ID、バーコード、...)
  • job_tape_lnk(ジョブ_id,テープ_id)
  • ボリューム (id、ボリューム名、tape_id)
  • カタログ (id、ボリューム ID、ファイル名、....)

プロジェクトごとにテーブル カタログを分割したいと考えています。これは実現可能ですか？または、データを構造化する別の方法を検討する必要がありますか? MySQL または PostgreSQL のいずれかを使用できますが、パーティショニングの実践経験はありません

4

1 に答える 1

0

一般に、PostgreSQL では、テーブルのパーティショニングは特定の種類の一括操作に役立ちます。それらはあなたには当てはまらないと思うので、他のいくつかのことについて言及します。

  1. 部分インデックス。たとえば、特に大規模なプロジェクトに独自のインデックスを与えることで、後押しすることができます。これはおそらく、ほとんどのワークロードで少なくともテーブルのパーティション化と同じくらい優れているでしょう。

  2. ハードウェアをよく見てください。ここで詳細を提供することはできません。詳細について十分に言及していないためです。

  3. 書き込み負荷が大きくなりすぎた場合の Postgres-XC など、必要に応じてより複雑なソリューションを検討してください。

  4. 行き詰まった場合は、喜んで外部の助けを求めてください。

于 2013-11-06T14:50:27.423 に答える