事実
- データベース: PostgreSQL (最新)
- プログラミング言語: Java
問題文（簡体字）
概要と詳細の 2 つの表があります。「概要」には数百万の行があり、「概要」の各行には「詳細」に数百万の行が関連付けられている可能性があります。外部キーの details.overview_id は、overview.id を参照します。ほとんどのクエリは一般的な形式SELECT * FROM details WHERE overview_id = xxx AND details.id > yyy AND details.id < zzz;
です。詳細用のテーブルが 1 つしかない場合、クエリは非常に遅くなります (ただし、詳細に関するクエリはほとんど常に主キーに対して行われます)。
DB アクティビティの性質の詳細: 概観に関する INSERT と UPDATE はまれにしか発生しません。詳細に対する INSERT は急速に発生しますが、同じテーブルに対する UPDATE はほとんど発生せず、一括 DELETE は時々発生します。
すでに持っているもの
以前は生の SQL を使用して、テーブルの「詳細」を「概要」の各行に対して分割していました。(実際には、実際にはパーティション化はしませんでした。代わりに、テンプレートに基づいて新しいテーブルを作成しました。これらのテーブルには、overview_id と呼ばれる列がなく (ストレージ スペースを節約できます)、代わりに、overview.id との間のマッピングを行う別のテーブルがありました。特定のパーティション テーブルのテーブル名。) したがって、理解できるように、新しい行が概要に挿入され、行が概要から削除されたときにパーティションが削除されたため、パーティションをオンザフライで生成する必要がありました。これらはすべてアプリケーション内で管理されていました。アプリケーションとデータベースの相互作用は非常に高速ですが、アプリケーション コードはかなり複雑であり、保守が困難であることを示しています。また、生の SQL がいたるところに転がっているため、
現在の目標
現在、このパーティショニングがバックグラウンドで発生する可能性があるメカニズムのオプションを検討しています-おそらく JPA プロバイダー (これは JPA 仕様の一部ではないことを理解しています) によって、基盤となるフレームワーク/レイヤーがスケーラビリティの問題を処理します。
openJPA Slice と EclipseLink を見ました。どちらも、ホスト全体のパーティション (シャード) 管理を提供します。確かにそれが必要です。しかし、単一ホスト内でのパーティション管理も必要です。ただし、これに対するより優れた、またはより洗練された解決策がある場合、またはこれをまったく別の角度から見ることができる場合は、それについて知って本当にうれしいです.
あなたが提供できる洞察に感謝します。
ありがとう。
プラジェシュ