3

マップするプロジェクトのパフォーマンス テスト/最適化を行っています。

a document <--> Java object tree <--> mysql database

ドキュメント、Java クラス、データベース スキーマ、およびマッピング用のロジックは、HyperJaxb3 で編成されています。その ORM 部分は、休止状態によって提供される JPA です。

約 50 の異なるエンティティがあり、それらの間には明らかに多くの関係があります。アプリケーションの主な機能は、ドキュメントをロードしてから、データを新しいドキュメントに再編成することです。各着信ドキュメントのすべての部分は、最終的に 1 つの発信ドキュメントで送信されます。リレーショナルな世界に住みたくないのですが、トランザクション セマンティクスはこのアプリケーションに非常に適しています。多額の資金と政府の規制が関係しているため、すべてが 1 回だけ配信されるようにする必要があります。

機能的には、すべてが順調に進んでおり、パフォーマンスはまともです (かなりの量の微調整の後)。各ドキュメントは数千のエンティティで構成され、最終的にデータベースに数千の行が作成されます。ドキュメントのサイズはさまざまで、挿入のパフォーマンスは、挿入する必要がある行の数にほぼ比例します (驚くことではありません)。

大幅な最適化の可能性があると思いますが、これが私の疑問です。

各ドキュメントは、エンティティのツリーにマップされます。ツリーの「葉」の半分には、送信ドキュメントの生成方法の決定には使用されない多くの詳細情報が含まれています。つまり、多くのテーブルの内容によってクエリ/フィルター処理できる必要はありません。

適切なエンティティ サブツリーを BLOB にマップして、現在通常の方法で処理している行の大部分を挿入/更新/インデックス付けするオーバーヘッドを節約したいと考えています。

私の最善の策は、カスタム EntityPersister を実装し、それを適切なエンティティに関連付けることです。これは正しい方法ですか？休止状態のドキュメントは悪くありませんが、実装する必要があるかなり複雑なクラスであり、javadoc を見た後、多くの疑問が残ります。出発点として使用できる、具体的でありながら単純な例を教えていただけますか?

この最適化にアプローチする別の方法について何か考えはありますか?

4

1 に答える 1

1

大量のバイナリ データを保存する際に、同じ問題に遭遇しました。私が最もうまくいった解決策は、オブジェクト モデルの非正規化です。たとえば、マスター レコードを作成してから、バイナリ データを保持する 2 番目のオブジェクトを作成します。マスターでは@OneToOne、セカンダリ オブジェクトへのマッピングを使用しますが、関連付けを遅延としてマークします。これで、データは必要な場合にのみロードされます。

速度を低下させる可能性のある 1 つのことは、outer join休止状態がこのタイプのすべてのオブジェクトに対して実行されることです。これを回避するには、オブジェクトを必須としてマークします。しかし、データベースが大きなパフォーマンス ヒットをもたらさない場合は、そのままにしておくことをお勧めします。通常の結合を取得しようとすると、Hibernate はバイナリ データをすぐにロードする傾向があることがわかりました。

最後に、1 回の SQL 呼び出しで大量のバイナリ データを取得する必要がある場合は、HQLfetch joinコマンドを使用します。例: from Article a fetch join a.dataここで、a.data はバイナリ ホルダーとの 1 対 1 の関係です。HQL コンパイラは、これを 1 回の SQL 呼び出しですべてのデータを取得する命令と見なします。

HTH

于 2013-01-18T01:33:09.807 に答える