マップするプロジェクトのパフォーマンス テスト/最適化を行っています。
a document <--> Java object tree <--> mysql database
ドキュメント、Java クラス、データベース スキーマ、およびマッピング用のロジックは、HyperJaxb3 で編成されています。その ORM 部分は、休止状態によって提供される JPA です。
約 50 の異なるエンティティがあり、それらの間には明らかに多くの関係があります。アプリケーションの主な機能は、ドキュメントをロードしてから、データを新しいドキュメントに再編成することです。各着信ドキュメントのすべての部分は、最終的に 1 つの発信ドキュメントで送信されます。リレーショナルな世界に住みたくないのですが、トランザクション セマンティクスはこのアプリケーションに非常に適しています。多額の資金と政府の規制が関係しているため、すべてが 1 回だけ配信されるようにする必要があります。
機能的には、すべてが順調に進んでおり、パフォーマンスはまともです (かなりの量の微調整の後)。各ドキュメントは数千のエンティティで構成され、最終的にデータベースに数千の行が作成されます。ドキュメントのサイズはさまざまで、挿入のパフォーマンスは、挿入する必要がある行の数にほぼ比例します (驚くことではありません)。
大幅な最適化の可能性があると思いますが、これが私の疑問です。
各ドキュメントは、エンティティのツリーにマップされます。ツリーの「葉」の半分には、送信ドキュメントの生成方法の決定には使用されない多くの詳細情報が含まれています。つまり、多くのテーブルの内容によってクエリ/フィルター処理できる必要はありません。
適切なエンティティ サブツリーを BLOB にマップして、現在通常の方法で処理している行の大部分を挿入/更新/インデックス付けするオーバーヘッドを節約したいと考えています。
私の最善の策は、カスタム EntityPersister を実装し、それを適切なエンティティに関連付けることです。これは正しい方法ですか？休止状態のドキュメントは悪くありませんが、実装する必要があるかなり複雑なクラスであり、javadoc を見た後、多くの疑問が残ります。出発点として使用できる、具体的でありながら単純な例を教えていただけますか?
この最適化にアプローチする別の方法について何か考えはありますか?