私の部署は、大規模な Oracle データベースの一部をハッシュ パーティショニング/シャーディングに移行することを決定しました。エンティティを異なるスキーマに分割します。私は、これに対するさまざまな JPA 実装の適合性を評価するためにスパイクを実行する任務を負っています。
私が注目するように言ったのは、EclipseLinkと Apache OpenJPA/Sliceの 2 つです。過去に Hibernate のみを使用していましたが、Hibernate Shardsはベータ版であり、積極的に開発されていないようです (最後のリリースは 2007 年でした)。そのため、検討していません。
私は自分自身で評価と試験的な実装を行う予定ですが、与えられた時間内にこれらの実装の全体的な品質について良い感触を得られるとは思えません。実稼働環境で OpenJPA や EclipseLink を使用している場合、特にデータベースが共有されている場合は、経験 (肯定的および否定的)、全体的な品質に関する意見、および同じようにするかどうかについてお聞きしたいと思います。機会があればまた選びます。
EclipseLinkのデータ分割サポートは、2.2リリースの基本製品の一部としてリリースされました。
ハッシュパーティショニング、他のいくつかのタイプのパーティショニング（値、範囲）、およびユーザー定義のポリシーをサポートします。2.3リリースには、Oracle RAC、UCP、およびWebLogicGridLinkの統合サポートも含まれています。
http://java-persistence-performance.blogspot.com/2011/05/data-partitioning-scaling-database.htmlを参照してください。
OpenJPA スライスは、シャード データベース環境での JPA アプリケーションの 1 つのオプションになる可能性があります。
OpenJPA Slice はバージョン 1.2 以降で使用でき、Websphere 7.0 以降にも同梱されています。Slice の基本的な使用規約は、まったく同じ JPA ベースのアプリケーション コードを保持して、データベース スキーマにまったく影響を与えることなく、水平に分割されたデータベース シャードを操作することです。データベース シャードは、さまざまなベンダーのものである可能性があります。
スライスは、どのシャード/スライスが新しいインスタンスを永続化するか、クエリがスライスのサブセットをターゲットにする方法などをユーザー アプリケーションが制御できるようにするポリシー ベースの設計に従います。
基本的な制限 (すべてのシャード環境で一般的) は、永続ドメイン モデルがツリー制約スキーマに準拠する必要があることです。基本的に、インスタンス x がシャード A に格納されている場合、x の永続的なクロージャ、つまり x から直接的または間接的に到達可能なインスタンスのセットも、同じシャード A に格納する必要があります。x を永続化すると、Slice はクロージャを自動的に計算します。
アプリケーションがそのような制約に耐えることができる場合、Slice は適している可能性があります。
国コードや通貨コードなど、特定のインスタンスがクロージャ間で共有される場合があります。スライスには、このような「マスター データ」のようなインスタンスを複数のシャードにレプリケートする機能があります。
アーベル/シャーディングに可換な集計操作 (MAX、MIN、SUM) がサポートされています。AVG などの非アーベル集約はサポートされていません。ソート済みまたはトップ N クエリもサポートされています。
Slice の詳細については、次のリファレンスを参照してください。
[1] OpenJPA ユーザーマニュアル: http://openjpa.apache.org/builds/latest/docs/manual/manual.html#ref_guide_slice
[2] IBM Developerworks の記事: http://www.ibm.com/developerworks/java/library/os-openjpa/?ca=drs-
必要に応じて、アプリケーション開発者だけでなく、BI ユーザーや DBA などからもシャーディング ロジックを隠す外部ツールを使用できます。ScaleBaseを確認してください。