Oracle TopLinkには、オープンソースのEclipseLinkがJava Persistence API (JPA)実装として含まれています。Oracle TopLinkは、Oracle Application Serverへの高度な統合によってEclipseLinkを拡張します。
ここに記載されている内容は、読者がEclipseLinkの基本的な機能を理解していることを想定しています。チューニングを始める前に、次の概論に目を通すことを検討してください。
「Understanding Queries」(http://www.eclipse.org/eclipselink/documentation/2.5/concepts/queries.htm#CHDGGCJB
)
「Understanding Caching」(http://www.eclipse.org/eclipselink/documentation/2.5/concepts/general004.htm#CHDEEBFG
)
「Understanding Mappings」(http://www.eclipse.org/eclipselink/documentation/2.5/concepts/mappingintro.htm#CHDFEJIJ
)
Oracle TopLinkの詳細は、Oracle Technology Network (OTN)のTopLinkのページを参照してください。
注意:
ここに記載されている内容は、Java EE環境に則したJPAのパフォーマンス・チューニングにおけるクイック・スタート・ガイドの役割を果します。ここでは、パフォーマンス・チューニングに関する一般的な考慮事項と関連のドキュメント・リソースを示しますが、チューニングが必要な分野をすべて網羅しているわけではありません。
最適なパフォーマンスを実現するために、各自のユースケース・シナリオに適用する、チューニングに関する次の考慮事項に従います。
表10-1 EJB/JPAでの効率的なSQL文およびSQL問合せの使用
チューニング・パラメータ | 説明 | パフォーマンス上の注意点 |
---|---|---|
|
パラメータ使用のSQLおよびプリコンパイル文のキャッシュを使用すると、コール頻度の高い問合せのSQLがデータベースのSQLエンジンによって解析およびプリコンパイルされる回数が減少し、パフォーマンスが向上します。EclipseLinkでは、パラメータ使用のSQLがデフォルトで有効になります。ただし、データベースやJDBCドライバの中には、このオプションをサポートしないものもあります。Oracle Application ServerにバンドルされているOracle JDBCドライバは、このオプションをサポートしていませんので注意してください。これを構成するには、 「Understanding Caching」( デフォルト値: |
選択したデータベースやJDBCドライバが前述のオプションをサポートしている場合は、パラメータ使用のSQLのバインディングを有効のままにしてください。 |
|
文キャッシュは、カーソル作成の繰返しと文の解析および作成の繰返しがパフォーマンスに与える影響を軽減するために使用します。文キャッシュによって、データベースを使用するアプリケーションのパフォーマンスが向上します。 注意: Java EEアプリケーションには、データ・ソースの文キャッシュを使用します(EJB3.0/JPAのEclipseLink文キャッシュは使用しません。例: Oracle Weblogicデータ・ソースでこのオプションを設定するには、構成オプション 『Oracle WebLogic Server JDBCデータ・ソースの管理』の文キャッシュによるパフォーマンスの向上に関する項も参照してください。 デフォルト値: Oracle Weblogic Serverデータ・ソースのデフォルトの文キャッシュ・サイズは、1接続当たり文10個です。 |
ご使用のJDBCドライバがこのオプションをサポートしている場合は、文キャッシュを必ず有効にしてください。Oracle JDBCドライバは、このオプションをサポートしています。 |
|
JDBCフェッチ・サイズは、JDBCドライバにとって、追加の行が必要な場合にデータベースからフェッチする行数のヒントとなります。 多数のオブジェクトを返す大規模な問合せに対しては、問合せで使用される行フェッチ・サイズを構成すると、選択条件を満たすのに必要なデータベース・ヒット数が少なくて済み、パフォーマンスが向上します。 ほとんどのJDBCドライバは、デフォルトのフェッチ・サイズとして10を使用します。1000個のオブジェクトを読み取る場合、フェッチ・サイズを256に増やすと、問合せ結果のフェッチに要する時間が大幅に短縮されます。 注意: デフォルト値の場合、JDBCドライバのデフォルト値が使用されます。Oracle JDBCドライバでは、通常10行です。 これを構成するには、問合せヒント デフォルト値: |
最適なフェッチ・サイズが常に明白であるとはかぎりません。通常は、予想される総結果サイズの半分または4分の1がフェッチ・サイズとして最適です。結果セットのサイズが不確かな場合に、誤ってフェッチ・サイズの設定を大きく、または小さくしすぎると、パフォーマンスが低下する可能性がありますので、注意してください。 |
|
バッチ書込みでは、 これを構成するには、 デフォルト値: |
永続性ユニットに対して有効にします。 |
|
これは、EclipseLinkによるエンティティ変更の検出方法をチューニングするための最適化機能です。 デフォルト値: ウィービングを使用する場合は |
最適なパフォーマンスを得るには、デフォルトの |
|
デフォルト値: |
最適なパフォーマンスを得るには、Onのままにします。 |
|
問合せヒント
デフォルト値: |
最適なパフォーマンスを得るために、結果オブジェクトが変更されない問合せには |
|
これらは、大規模な問合せのページングに使用するJPA問合せプロパティです。通常、これらのプロパティは、多数の行を返す問合せの結果セット全体が必要ではない場合に使用できます。たとえば、ユーザーが特定の結果を求めて結果セットを(一度に1ページずつ)スキャンし、レコードが見つかってしまえば残りのデータは破棄するような場合です。 |
大きな結果セットが得られるが、オブジェクトのサブセットのみが必要になるような問合せに対して使用します。 |
|
順序番号の事前割当てを行うと、一連のIDをデータベースに対して同時に問い合せることができ、挿入のたびにデータベースにアクセスしてIDを取得する必要がなくなります。 デフォルト値: |
常に順序番号の事前割当てを使用すると、挿入のパフォーマンスが最適化されます。最適なパフォーマンスを得るには、事前割当てが行えない |
表10-2に、パフォーマンス・チューニング用のエンティティ・リレーションシップ問合せパラメータを示します。
表10-2 EJB3.0エンティティ・リレーションシップ問合せのパフォーマンス・オプション
チューニング・パラメータ | 説明 | パフォーマンス上の注意点 |
---|---|---|
|
バッチ・フェッチには バッチ処理は、SELECT句にオブジェクトが1つしかない問合せに対してのみ実行できます。これを構成するための問合せヒントは デフォルト値: |
必要な表データへの列マッピングを持つ表の問合せに使用します。バッチ・フェッチまたは結合を使用するのは、すべてのデータにアクセスすることがわかっている場合にかぎります。リレーションシップにアクセスする予定がない場合は、インダイレクションを使用してロードを遅らせてください。 バッチ・フェッチは、重複したデータの読取りを回避できるため、結合より効率的です。したがって、バッチ・フェッチがサポートされている問合せのパフォーマンスを最適化するには、結合読取りではなくバッチ・フェッチを使用することを検討してください。 |
|
結合フェッチとは、あるクラスの1回の問合せで、そのクラスと関連オブジェクトのインスタンス作成に必要なデータが返されるようにする、問合せ最適化機能です。 この機能は、データベース・アクセスを減らして問合せのパフォーマンスを改善するために使用します。デフォルトでは、リレーションシップに対して結合読取りは行われません。遅延ロードを使用している場合は、各リレーションシップがアクセス時に別々にフェッチされ、遅延ロードを使用していない場合は、別々のデータベース問合せとしてフェッチされます。 結合の使用は、 結合はJPA仕様の一部ですが、バッチ・フェッチは違います。また、結合の対象となるのは、バッチ・フェッチが行えない問合せです。たとえば、結合は、SELECT句に複数のオブジェクトを含む問合せ、単一の結果を返す問合せ、カーソルおよび最初/最大の結果に対して機能しますが、バッチ・フェッチは機能しません。 「Join Fetching」( デフォルト値: 使用しない |
必要な表データへの列マッピングがある表の問合せに使用します。バッチ・フェッチまたは結合を使用するのは、すべてのデータにアクセスすることがわかっている場合にかぎります。リレーションシップにアクセスする予定がない場合は、インダイレクションを使用してロードを遅らせてください。SELECTのパフォーマンスを最適化するために、バッチ・フェッチがサポートされていない場合は結合を使用することをお薦めします。 |
|
遅延ロードをOnにしていない場合、EclipseLinkは、永続オブジェクトを取得する際に、それが参照する従属オブジェクトをすべて取得します。リレーションシップ・マッピングによってマップされた属性に対して遅延読取り(インダイレクション、遅延ロード、ジャストインタイム読取りとも呼びます)を構成すると、EclipseLinkは被参照オブジェクトのプレースホルダとしてインダイレクション・オブジェクトを使用します。 その属性にアクセスするまで、従属オブジェクトの読取りはEclipseLinkによって遅延されます。その結果、アプリケーションにとって重要なのは取得されたオブジェクトの内容のみであり、関連オブジェクトの内容は重要でないという場合は特に、パフォーマンスが大幅に向上します。 「Using Lazy Loading」( デフォルト値: コレクション・マッピングの場合は デフォルト値: 参照の場合は ( |
すべてのマッピングに対して遅延ロードを使用します。遅延ロードを使用し、バッチ・フェッチまたは結合を使用して被参照オブジェクトを問い合せる方が、即時ロードより効率的です。 リレーションシップのインスタンス化を問合せで強制できるようにする |
EclipseLinkに付属しているデフォルトの内部キャッシュをチューニングできます。Oracle Toplink/EclipseLinkは、Oracle Coherenceとも統合できます。Oracle Coherenceを使用したEclipseLinkエンティティ・キャッシュの構成およびチューニングの詳細は、Oracle Coherenceとの統合を参照してください。
EclipseLink永続性マネージャおよびキャッシュとともに使用するEJB3.0/JPAのデフォルト設定は、ロックなし、キャッシュ・リフレッシュなしで、キャッシュの使用方法はDoNotCheckCache
です。(排他的アクセス権限がない場合に)アプリケーションでキャッシュを使用し、失効したデータをキャッシュから読み取らないようにするには、これらの設定に加えて、その他の分離関連の設定を適切に構成する必要があります。表10-3に、キャッシュ構成オプションを示します。
キャッシュ構成の詳細は、「Understanding Caching」(http://www.eclipse.org/eclipselink/documentation/2.5/concepts/cache.htm#CDEFHHEH
)を参照してください。
注意:
デフォルトでは、アプリケーションが使用データへの排他的アクセス権限を持つ(つまり、EclipseLink以外の外部アプリケーションがデータを変更することはない)ものと想定されます。アプリケーションがデータへの排他的アクセス権限を持たない場合は、表10-3に示すデフォルト値を一部変更する必要があります。
表10-3 EJB3.0 JPAエンティティとキャッシュ構成オプション
チューニング・パラメータ | 説明 | パフォーマンス上の注意点 |
---|---|---|
|
EclipseLinkセッションには、オブジェクト・キャッシュが用意されています。EclipseLink永続性マネージャを使用するEJB3.0 JPAアプリケーションでは、このキャッシュをデフォルトで使用するEclipseLinkセッションが作成されます。セッション・キャッシュと呼ばれるこのキャッシュには、データベースとの間で読み書きされたオブジェクトの情報が格納されます。セッション・キャッシュは、EclipseLinkアプリケーションのパフォーマンスを改善するための重要な要素の1つです。 通常、サーバー・セッションのオブジェクト・キャッシュは、そのセッションから取得されたすべてのクライアント・セッションで共有されます。分離セッションは、共有オブジェクト・キャッシュから分離された固有のセッション・キャッシュを備えています。 アノテーション・タイプ
デフォルト値: |
一般に、キャッシュは有効にしておくことをお薦めします。常にデータベースから読み取られるオブジェクト(ペシミスティック・ロックの対象となるオブジェクトなど)がある場合は、そのエンティティのキャッシュを無効にしてください。また、アクセス頻度の低いエンティティのキャッシュを無効にすることも検討してください。 |
|
EclipseLinkでは、オブジェクト・キャッシュに加えて、問合せキャッシュもサポートされています。
問合せキャッシュの問合せヒントには次のものがあります。
「Understanding Caching」( デフォルト値: 使用しない |
主キー以外のキーで頻繁に実行される問合せのうち、結果セットがあまり変わらないものに使用します。キャッシュ無効化タイムアウトとともに使用すると、必要に応じてリフレッシュできます。 |
|
キャッシュ・サイズは、永続性プロパティ
「About the Persistence Unit」( デフォルト値: タイプ |
使用可能なメモリーの量、使用するクラスのインスタンス数、エンティティのアクセス頻度、および失効したデータの許容度に基づいたキャッシュの必要量を基準に、キャッシュ・サイズを設定します。 アクセス頻度の高いインスタンスが多いエンティティや、失効したデータが大した問題にはならないエンティティについては、サイズの大きなキャッシュを作成することを検討してください。 更新頻度が高く、常に最新のデータが必要とされるエンティティや、アクセス頻度の低いエンティティには、小さなキャッシュ・サイズを使用するか、キャッシュをまったく使用しないことを検討してください。 |
|
Oracleでは、表10-4に示すロック・ポリシー( ロックは、JPAの 「Descriptors and Locking」( デフォルト値: |
同時に更新可能なエンティティには、ユーザーが他のユーザーの変更を上書きできないようなロック・ポリシーを使用することを検討してください。読取り専用エンティティのパフォーマンスを最適化するには、エンティティを |
|
デフォルトでは、どのタイプの問合せも、まずデータベースを検索してからキャッシュと同期を取ります。問合せにリフレッシュが設定されている場合を除き、キャッシュされたオブジェクトはデータベースからリフレッシュされずに返されます。特定の問合せを、インメモリー・キャッシュ、データベース、その両方のうち、いずれに対して実行するかを指定できます。 すでにキャッシュにあるオブジェクトがデータベースで検索されるのを防いでパフォーマンスを向上させるには、検索の際に必要なオブジェクトをまずキャッシュから取得し、オブジェクトがキャッシュに存在しない場合にのみデータ・ソース内を検索するよう構成します。主キーに基づいて単一オブジェクトを検索する問合せについては、問合せヒント デフォルト値: |
通常はデータがキャッシュにあり、リフレッシュ処理をそれほど必要としない場合に、主キー問合せのパフォーマンスを高速化するには、まず主キー問合せでキャッシュをチェックすることをお薦めします( これにより、まずデータベースからオブジェクトを取得した後、すでにキャッシュにあるオブジェクトを検索し、キャッシュされた値(問合せにリフレッシュが設定されている場合を除き、データベース・アクセスによって更新されていない)を返すというデフォルト動作を回避できます。 |
|
EclipseLinkを使用するJPAアプリケーションには、特定のデータベース・トランザクションの分離レベルを単独で設定するチューニング・パラメータはありません。 一般的なEJB3.0 JPAアプリケーションでは、データベース・トランザクションの分離レベルが適用されるタイミング、および特定のデータベース・トランザクションを分離できる程度には、次のような様々な要素が影響を与えます。
「Isolated Cache」( |
|
|
デフォルトでは、EclipseLinkはデータ・ソースから読み取ったオブジェクトをキャッシュします。このオブジェクトに対する後続の問合せではキャッシュへのアクセスが行われるため、データ・ソースへのアクセスが減るとともに、オブジェクトとそのリレーションシップを再構築するコストも発生せず、パフォーマンスが向上します。問合せでデータ・ソースにアクセスする場合でも、返されたレコードに対応するオブジェクトがキャッシュに存在すれば、EclipseLinkはキャッシュされたオブジェクトを使用します。このデフォルトのキャッシュ・ポリシーは、失効したデータがアプリケーション内に生じる原因となります。 リフレッシュは、エンティティ・レベル( 詳細は、キャッシュのリフレッシュについてを参照してください。 「Understanding Caching」( デフォルト値: |
エンティティ・レベルでのキャッシュのリフレッシュはできるかぎり避け、かわりに次の構成を検討してください。
|
キャッシュでのデータのリフレッシュに関して、考慮すべきシナリオがいくつかあります。これらのシナリオはいずれも、パフォーマンスに影響を与えます。
キャッシュされたデータではなく、最新のデータが常に必要な場合は、分離キャッシュ(Shared=False
)を使用することを検討してください。これに当てはまるのは、アプリケーション内の特定のデータが頻繁に変更されるため、競合が検出されたときにのみデータをリフレッシュするのではなく、常にデータをリフレッシュすることが望ましいような場合です。
失効したデータは使用したくないが、失効したデータを取得することになっても大した問題ではないという場合は、解決策としてキャッシュ失効ポリシーを使用することをお薦めします。この場合は、ロック・エラー発生時に失効したオブジェクトを自動的にリフレッシュする、オプティミスティック・ロックも使用してください。オプティミスティック・ロックを使用する場合は、エンティティの@Cache
属性であるalwaysRefresh
およびrefreshOnlyIfNewer
をさらに有効にすると、データベースにアクセスする問合せで、返された失効オブジェクトをリフレッシュできるとともに、無効なオブジェクトが変更されていない場合はリフレッシュしないようにできます。また、リフレッシュされたデータが必要であることがわかっている場合に、特定の問合せ操作に対してリフレッシュを有効にしたり、クライアントから取得したデータをリフレッシュするオプション(リフレッシュ問合せをコールするもの)を提供したりすることもできます。
データが失効していても問題ない場合は、オプティミスティック・ロックを使用してください。そうすると、ロック・エラーの際にキャッシュ内の失効したオブジェクトが自動的にリフレッシュされます。
表10-4に示すロック・モードを、EclipseLinkのキャッシュ使用方法および問合せリフレッシュのオプションとともに使用すると、JPAを使用するEJBエンティティのデータ一貫性が保証されます。どの組合せも機能とパフォーマンスの両面に影響を与えますが、これらのオプションの設定は、たとえパフォーマンスのコストが発生したとしても、データを最新で一貫した状態に保つための機能上の要件を優先して決めるのが一般的です。
詳細は、「Descriptors and Locking」(http://www.eclipse.org/eclipselink/documentation/2.5/concepts/descriptors002.htm#CHEEEIEA
)を参照してください。
表10-4 ロック・モード・ポリシー
ロック・オプション | 説明 | パフォーマンス上の注意点 |
---|---|---|
|
ユーザーが別のユーザーの変更内容を上書きできます。これはデフォルトのロック・モードです。エンティティが同時に更新されることがない場合や、read-committedセマンティクスによる同じ行の同時読取りおよび更新で十分な場合は、このモードを使用します。 デフォルト値: |
通常はロックなしの方が高速ですが、データ一貫性のニーズには対応できない場合があります。 |
|
すべてのユーザーがデータへの読取りアクセス権限を持ちます。ユーザーが変更を加えようとした場合、そのユーザーがデータを読み取った後にデータが変更されていないか、アプリケーションによってチェックされます。 「Using Optimistic Locking」( |
同じ行に対する同時更新を頻繁には実行しないと予想される場合、オプティミスティック・ロックを使用すれば、最適なパフォーマンスを得ながら、データの一貫性も保証することができます。 |
|
更新目的でデータにアクセスした最初のユーザーによって、更新処理が完了するまでデータがロックされます。 |
同じ行に対して頻繁に同時更新を実行することが予想される場合、同時アクセスの例外および再試行が多数発生するオプティミスティック・ロックより、ペシミスティック・ロックの方が高速になることがあります。 エンティティ・レベルでペシミスティック・ロックを使用する場合は、最適なパフォーマンスを得るために、分離キャッシュ( |
|
EJB3.0 JPAエンティティを
|
エンティティを |
EclipseLinkでは、オブジェクト表現とデータ・ソース固有の表現との間でデータのトランスフォーメーションを実行できます。このトランスフォーメーションをマッピングと呼びます。マッピングは、EclipseLinkプロジェクトの中核をなしています。
マッピングはそれぞれ、ドメイン・オブジェクトの単一データ・メンバーに対応しています。マッピングによって、オブジェクト・データ・メンバーをそのデータ・ソース表現と関連付け、オブジェクトとデータ・ソースの間の双方向変換を実行する手段を定義します。
マッピングの詳細は、「Mapping and Descriptors」(http://www.eclipse.org/eclipselink/documentation/2.5/solutions/performance002.htm#sthref153
)を参照してください。
EclipseLinkでは、@Partitioned
アノテーションを使用してデータのパーティション化を構成できます。パーティション化すると、アプリケーションはクラスタ・データベースなどの複数のデータベース間で情報を増減できます。
@Partitioned
およびその他のパーティション・ポリシー・アノテーションの使用方法の詳細は、「Partitioning Annotations」(http://www.eclipse.org/eclipselink/documentation/2.5/jpa/extensions/annotations_ref.htm#CACHIHIB
)を参照してください。
推奨されている変更を行った後、デプロイメントに固有の変更をさらに追加できます。高度なチューニングの推奨事項は、ご使用の環境に適しているかどうか慎重に検討してください。
Oracle Toplinkは、Oracle Coherenceと統合できます。この統合は、Oracle TopLink Grid機能によって実現されます。TopLink Gridを使用したEclipseLink JPAとの統合には、いくつかの種類があります。
次に例を示します。
EclipseLinkのデフォルトL2キャッシュをCoherenceに置き換えます。こうすることで、クラスタ・ノード全体をカバーする非常に大きなL2キャッシュがサポートされます。EclipseLinkのデフォルトL2キャッシュは、Java EEでホストされたマルチスレッド・アプリケーションが単一のJVMで稼働する場合のパフォーマンスを高めます。これをクラスタ全体で使用する場合は、特殊なキャッシュ調整機能を構成する必要があります。
データベースではなく、Coherenceのデータ・グリッド内で問合せを実行するよう、エンティティを構成します。こうすると、クラスタ化されたアプリケーション・デプロイメントを、データベースがボトルネックとなるような操作を越えて拡張できます。
EclipseLink JPAをCoherenceキャッシュとともに使用する方法の詳細は、『Oracle Coherenceの統合』のグリッド・キャッシュの構成に関する項を参照してください。
Oracle ToplinkのOracle Coherenceとの統合の詳細は、『Oracle Coherenceの統合』のOracle CoherenceでのToplink Gridの統合に関する項を参照してください。
EclipseLinkの次の機能は、JPAアプリケーションのパフォーマンス分析に役立ちます。
パフォーマンス・モニタリング・フォームの詳細は、「Performance Monitoring」(http://www.eclipse.org/eclipselink/documentation/2.5/concepts/monitoring003.htm#BABJABIH
)を参照してください。このツールは、マルチスレッド化されたサーバー環境の情報をプロファイルおよびモニターすることを目的としています。
パフォーマンスのプロファイルの詳細は、「Task 1: Measure EclipseLink Performance with the EclipseLink Profiler」(http://www.eclipse.org/eclipselink/documentation/2.5/solutions/performance002.htm#CHDIAFJI
)を参照してください。このツールは、シングルスレッドの限定的なユースケースでの使用を想定しています。
パフォーマンスの問題のデバッグおよびテストを行う場合、EclipseLinkから生成されたSQLを確認できます。SQLを確認するには、ロギング用のEclipseLink JPA拡張機能を使用して、ロギング・レベルをFINE
に上げます。
最適なパフォーマンスを得るために、プロファイリングまたはデバッグが終了したら、必ずロギング・レベルをデフォルト・レベルに戻してください。