| Oracle® Fusion Middlewareパフォーマンスおよびチューニング・ガイド 11g リリース1 (11.1.1) B61006-10 |
|
 前 |
 次 |
この章では、EclipseLinkに対して使用可能なパフォーマンス・チューニング機能について説明します。EclipseLinkは、Oracle TopLinkとともに使用するオープンソースの永続性フレームワークです。この章の内容は次のとおりです。
|
注意: これらの分野におけるパフォーマンス・チューニングの詳細は、次のドキュメントを参照してください。
|
Oracle TopLinkには、オープンソースのEclipseLinkがJava Persistence API (JPA)実装として含まれています。Oracle TopLinkは、Oracle Application Serverへの高度な統合によってEclipseLinkを拡張します。
Java Persistence APIは、Java EEアプリケーションおよびJava SEアプリケーションの永続性に関する仕様です。JPAでは、永続クラスをエンティティと呼びます。エンティティとは、データベースにマップされ、アノテーションまたは永続性XML、あるいはその両方を使用してJPA経由で使用するよう構成されたPlain Old Java Object (POJO)クラスです。この章では、EJB3.0およびJava EE環境に則したJPAのチューニングに焦点を当てます。
この章の内容は、読者がEclipseLinkの基本的な機能を熟知しているものと想定して書かれています。チューニングを始める前に、次の概論に目を通すことを検討してください。
『EclipseLink JPA User's Guide』(http://wiki.eclipse.org/EclipseLink/UserGuide/JPA)
「Considering JPA Entity Architecture」(http://wiki.eclipse.org/EclipseLink/UserGuide/JPA/Introduction/Architecture)
「Introduction to EclipseLink Queries」(http://wiki.eclipse.org/EclipseLink/UserGuide/JPA/Basic_JPA_Development/Querying)
「Introduction to Cache」(http://wiki.eclipse.org/EclipseLink/UserGuide/JPA/Basic_JPA_Development/Caching)
「Introduction to Mapping and Configuration」(http://wiki.eclipse.org/EclipseLink/UserGuide/JPA/Basic_JPA_Development/Mapping)
Oracle TopLinkの詳細は、OTNのTopLinkページ(http://www.oracle.com/technology/products/ias/toplink/index.html)を参照してください。[Oracle TopLinkリリース11gで、旧Toplink APIは非推奨となりました。詳細は、TopLinkのリリース・ノート(http://www.oracle.com/technology/products/ias/toplink/doc/11110/relnotes/toplink-relnotes.html#CHDGAEDJ)を参照してください。]
|
注意: この章は、Java EE環境に則したJPAのパフォーマンス・チューニングにおけるクイック・スタート・ガイドの役割を果します。この章では、パフォーマンス・チューニングに関する一般的な考慮事項と関連のドキュメント・リソースを示しますが、チューニングが必要な分野をすべて網羅してはいません。 |
チューニングに関する次の推奨事項は、ほとんどのデプロイメントに適用できます。これらのうち、いずれの構成を実装する場合でも、その前に各自のユースケース・シナリオを検討してください。
この項では、効率的なSQL文およびSQL問合せの使用について説明します。表9-1と表9-2に、SQL文およびSQL問合せに関連したチューニング・パラメータとパフォーマンス上の推奨事項を示します。
表9-1 EJB/JPAでの効率的なSQL文およびSQL問合せの使用
| チューニング・パラメータ | 説明 | パフォーマンス上の注意点 |
|---|---|---|
|
パラメータ使用のSQLのバインディング |
パラメータ使用のSQLおよびプリコンパイル文のキャッシュを使用すると、コール頻度の高い問合せのSQLがデータベースのSQLエンジンによって解析およびプリコンパイルされる回数が減少し、パフォーマンスが向上します。EclipseLinkでは、パラメータ使用のSQLがデフォルトで有効になります。ただし、データベースやJDBCドライバの中には、このオプションをサポートしないものもあります。Oracle Application ServerにバンドルされているOracle JDBCドライバは、このオプションをサポートしていませんので注意してください。これを構成するには、persistence.xmlの永続性プロパティeclipselink.jdbc.bind-parametersを使用します。 関連項目: 「Caching」( デフォルト値: PERSISTENCE_UNIT_DEFAULT(デフォルトでtrue) |
選択したデータベースやJDBCドライバが前述のオプションをサポートしている場合は、パラメータ使用のSQLのバインディングを有効のままにしてください。 |
|
JDBC文キャッシュ |
文キャッシュは、カーソル作成の繰返しと文の解析および作成の繰返しがパフォーマンスに与える影響を軽減するために使用します。文キャッシュによって、データベースを使用するアプリケーションのパフォーマンスが向上します。 注意: Java EEアプリケーションには、データ・ソースの文キャッシュを使用します(EJB3.0/JPAのEclipseLink文キャッシュは使用しません。例: Oracle Weblogicデータ・ソースでこのオプションを設定するには、構成オプション 『Oracle Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの構成と管理』の文キャッシュによるパフォーマンスの向上に関する項も参照してください。 デフォルト値: Oracle Weblogic Serverデータ・ソースのデフォルトの文キャッシュ・サイズは、1接続当たり文10個です。 |
ご使用のJDBCドライバがこのオプションをサポートしている場合は、文キャッシュを必ず有効にしてください。Oracle JDBCドライバは、このオプションをサポートしています。 |
|
フェッチ・サイズ |
JDBCフェッチ・サイズは、JDBCドライバにとって、追加の行が必要な場合にデータベースからフェッチする行数のヒントとなります。 多数のオブジェクトを返す大規模な問合せに対しては、問合せで使用される行フェッチ・サイズを構成すると、選択条件を満たすのに必要なデータベース・ヒット数が少なくて済み、パフォーマンスが向上します。 ほとんどのJDBCドライバは、デフォルトのフェッチ・サイズとして10を使用します。1000個のオブジェクトを読み取る場合、フェッチ・サイズを256に増やすと、問合せ結果のフェッチに要する時間が大幅に短縮されます。 注意: デフォルト値の場合、JDBCドライバのデフォルト値が使用されます。Oracle JDBCドライバでは、通常10行です。 これを構成するには、問合せヒント デフォルト値: 0 |
最適なフェッチ・サイズが常に明白であるとはかぎりません。通常は、予想される総結果サイズの半分または4分の1がフェッチ・サイズとして最適です。結果セットのサイズが不確かな場合に、誤ってフェッチ・サイズの設定を大きく、または小さくしすぎると、パフォーマンスが低下する可能性がありますので、注意してください。 |
|
バッチ書込み |
バッチ書込みでは、 これを構成するには、persistence.xmlの永続性プロパティ デフォルト値: Off |
永続性ユニットに対して有効にします。 |
|
変更追跡 |
これは、EclipseLinkによるエンティティ変更の検出方法をチューニングするための最適化機能です。 デフォルト値: ウィービングを使用する場合はAttributeLevel (Java EEのデフォルト)、それ以外の場合はDeferredです。 |
最適なパフォーマンスを得るには、デフォルトのAttributeLevelのままにします。 |
|
ウィービング |
persistence.xmlのプロパティ デフォルト値: On |
最適なパフォーマンスを得るには、Onのままにします。 |
|
読取り専用 |
EJB3.0 JPAエンティティを読取り専用に設定すると、そのエンティティは変更できなくなり、EclipseLinkが作業ユニットのパフォーマンスを最適化できるようになります。 問合せヒントeclipselink.read-onlyを使用して設定します。
デフォルト値: False |
最適なパフォーマンスを得るために、結果オブジェクトが変更されない問合せには読取り専用を使用します。 |
|
firstResultとmaxRows |
これらは、大規模な問合せのページングに使用するJPA問合せプロパティです。通常、これらのプロパティは、多数の行を返す問合せの結果セット全体が必要ではない場合に使用できます。たとえば、ユーザーが特定の結果を求めて結果セットを(一度に1ページずつ)スキャンし、レコードが見つかってしまえば残りのデータは破棄するような場合です。 |
大きな結果セットが得られるが、オブジェクトのサブセットのみが必要になるような問合せに対して使用します。 |
|
順序番号の事前割当て |
順序番号の事前割当てを行うと、一連のIDをデータベースに対して同時に問い合せることができ、挿入のたびにデータベースにアクセスしてIDを取得する必要がなくなります。 デフォルト値: 50 |
常に順序番号の事前割当てを使用すると、挿入のパフォーマンスが最適化されます。最適なパフォーマンスを得るには、事前割当てが行えない |
表9-2に、パフォーマンス・チューニング用のエンティティ・リレーションシップ問合せパラメータを示します。
表9-2 EJB3.0エンティティ・リレーションシップ問合せのパフォーマンス・オプション
| チューニング・パラメータ | 説明 | パフォーマンス上の注意点 |
|---|---|---|
|
バッチ・フェッチ |
eclipselink.batchヒントは、EclipseLinkにバッチ処理情報を提供します。これにより、関連オブジェクトに対する後続の問合せがバッチ内で最適化されるため、オブジェクトを1つずつ取得したり、大規模な1つの結合読取りで取得したりすることを回避できます。 バッチ・フェッチにはJOIN、EXISTSおよびINの3つのタイプがあります。タイプは、問合せヒントeclipselink.batch.typeを使用して設定します。 バッチ処理は、SELECT句にオブジェクトが1つしかない問合せに対してのみ実行できます。これを構成するための問合せヒントはeclipselink.batchです。バッチ・フェッチは、@BatchFetchアノテーションを使用して設定することもできます。 デフォルト値: Off |
必要な表データへの列マッピングを持つ表の問合せに使用します。バッチ・フェッチまたは結合を使用するのは、すべてのデータにアクセスすることがわかっている場合にかぎります。リレーションシップにアクセスする予定がない場合は、インダイレクションを使用してロードを遅らせてください。 バッチ・フェッチは、重複したデータの読取りを回避できるため、結合より効率的です。したがって、バッチ・フェッチがサポートされている問合せのパフォーマンスを最適化するには、結合読取りではなくバッチ・フェッチを使用することを検討してください。 |
|
結合フェッチ |
結合フェッチとは、あるクラスの1回の問合せで、そのクラスと関連オブジェクトのインスタンス作成に必要なデータが返されるようにする、問合せ最適化機能です。 この機能は、データベース・アクセスを減らして問合せのパフォーマンスを改善するために使用します。デフォルトでは、リレーションシップに対して結合読取りは行われません。遅延ロードを使用している場合は、各リレーションシップがアクセス時に別々にフェッチされ、遅延ロードを使用していない場合は、別々のデータベース問合せとしてフェッチされます。 結合の使用は、 結合はJPA仕様の一部ですが、バッチ・フェッチは違います。また、結合の対象となるのは、バッチ・フェッチが行えない問合せです。たとえば、結合は、SELECT句に複数のオブジェクトを含む問合せ、単一の結果を返す問合せ、カーソルおよび最初/最大の結果に対して機能しますが、バッチ・フェッチは機能しません。 関連項目: 「Join Fetch」( デフォルト値: 使用しない |
必要な表データへの列マッピングを持つ表の問合せに使用します。バッチ・フェッチまたは結合を使用するのは、すべてのデータにアクセスすることがわかっている場合にかぎります。リレーションシップにアクセスする予定がない場合は、インダイレクションを使用してロードを遅らせてください。SELECTのパフォーマンスを最適化するために、バッチ・フェッチがサポートされていない場合は結合を使用することをお薦めします。 |
|
遅延ロード |
遅延ロードをOnにしていない場合、EclipseLinkは、永続オブジェクトを取得する際に、それが参照する従属オブジェクトをすべて取得します。リレーションシップ・マッピングによってマップされた属性に対して遅延読取り(インダイレクション、遅延ロード、ジャストインタイム読取りとも呼びます)を構成すると、EclipseLinkは被参照オブジェクトのプレースホルダとしてインダイレクション・オブジェクトを使用します。 その属性にアクセスするまで、従属オブジェクトの読取りはEclipseLinkによって遅延されます。その結果、アプリケーションにとって重要なのは取得されたオブジェクトの内容のみであり、関連オブジェクトの内容は重要でないという場合は特に、パフォーマンスが大幅に向上します。 関連項目: 「Lazy Loading」( デフォルト値: コレクション・マッピングの場合はOn (ToManyマッピング、@OneToMany、@ManyToMany) デフォルト値: 参照の場合はOff (ToOneマッピング、@OneToOne、@ManyToOne) (@OneToOneおよび@ManyToOneに対して遅延ロードをOnに設定するには、ウィービングが必要です。Java EEの場合、ウィービングはデフォルトでOnになっています。) |
すべてのマッピングに対して遅延ロードを使用します。遅延ロードを使用し、バッチ・フェッチまたは結合を使用して被参照オブジェクトを問い合せるほうが、即時ロードより効率的です。 リレーションシップのインスタンス化を問合せで強制できるようにするLoadGroupsとともに最適化されたロードを使用することも検討できます。 |
この項では、EclipseLinkに付属しているデフォルト内部キャッシュのチューニングについて説明します。Oracle Toplink/EclipseLinkは、Oracle Coherenceとも統合できます。Oracle Coherenceを使用したEclipseLinkエンティティ・キャッシュの構成およびチューニングの詳細は、第9.3.1項「Oracle Coherenceとの統合」を参照してください。
EclipseLink永続性マネージャおよびキャッシュとともに使用するEJB3.0/JPAのデフォルト設定は、ロックなし、キャッシュ・リフレッシュなしで、キャッシュの使用方法はDoNotCheckCacheです。(排他的アクセス権限がない場合に)アプリケーションでキャッシュを使用し、失効したデータをキャッシュから読み取らないようにするには、これらの設定に加えて、その他の分離関連の設定を適切に構成する必要があります。表9-3に、キャッシュ構成オプションを示します。
キャッシュ構成の詳細は、「Caching」(http://wiki.eclipse.org/EclipseLink/UserGuide/JPA/Basic_JPA_Development/Caching)を参照してください。
|
注意: デフォルトでは、アプリケーションが使用データへの排他的アクセス権限を持つ(つまり、EclipseLink以外の外部アプリケーションがデータを変更することはない)ものと想定されます。アプリケーションがデータへの排他的アクセス権限を持たない場合は、表9-3に示すデフォルト値を一部変更する必要があります。 |
表9-3 EJB3.0 JPAエンティティとキャッシュ構成オプション
| チューニング・パラメータ | 説明 | パフォーマンス上の注意点 |
|---|---|---|
|
オブジェクト・キャッシュ |
EclipseLinkセッションには、オブジェクト・キャッシュが用意されています。EclipseLink永続性マネージャを使用するEJB3.0 JPAアプリケーションでは、このキャッシュをデフォルトで使用するEclipseLinkセッションが作成されます。セッション・キャッシュと呼ばれるこのキャッシュには、データベースとの間で読み書きされたオブジェクトの情報が格納されます。セッション・キャッシュは、EclipseLinkアプリケーションのパフォーマンスを改善するための重要な要素の1つです。 通常、サーバー・セッションのオブジェクト・キャッシュは、そのセッションから取得されたすべてのクライアント・セッションで共有されます。分離セッションは、共有オブジェクト・キャッシュから分離された固有のセッション・キャッシュを備えています。 アノテーション・タイプ@Cacheableは、エンティティをキャッシュするかどうかを指定します。persistence.xmlのキャッシュ要素の値がENABLE_SELECTIVEまたはDISABLE_SELECTIVEの場合、キャッシュは有効です。Cacheableアノテーションの値は、サブクラスによって継承されます。つまり、Cacheableをサブクラスで指定するとオーバーライドできます。 Cacheable(false)は、プロバイダがエンティティとその状態をキャッシュする必要がないことを意味します。 デフォルト値: 有効(sharedがTrue) |
一般に、キャッシュは有効にしておくことをお薦めします。常にデータベースから読み取られるオブジェクト(ペシミスティック・ロックの対象となるオブジェクトなど)がある場合は、そのエンティティのキャッシュを無効にしてください。また、アクセス頻度の低いエンティティのキャッシュを無効にすることも検討してください。 |
|
問合せ結果セット・キャッシュ |
EclipseLinkでは、オブジェクト・キャッシュに加えて、問合せキャッシュもサポートされています。
問合せキャッシュの問合せヒントには次のものがあります。
関連項目: 「Caching」( デフォルト値: 使用しない |
主キー以外のキーで頻繁に実行される問合せのうち、結果セットがあまり変わらないものに使用します。キャッシュ無効化タイムアウトとともに使用すると、必要に応じてリフレッシュができます。 |
|
キャッシュ・サイズ |
キャッシュ・サイズは、次の永続性プロパティを使用して構成します。 "
関連項目: 「Configuring Persistence Units Using persistence.xml」( デフォルト値: タイプ |
使用可能なメモリーの量、使用するクラスのインスタンス数、エンティティのアクセス頻度、および失効したデータの許容度に基づいたキャッシュの必要量を基準に、キャッシュ・サイズを設定します。 アクセス頻度の高いインスタンスが多いエンティティや、失効したデータが大した問題にはならないエンティティについては、サイズの大きなキャッシュを作成することを検討してください。 更新頻度が高く、常に最新のデータが必要とされるエンティティや、アクセス頻度の低いエンティティには、小さなキャッシュ・サイズを使用するか、キャッシュをまったく使用しないことを検討してください。 |
|
ロック |
Oracleでは、表9-4に示すロック・ポリシー(ロックなし、オプティミスティック、ペシミスティック、読取り専用)をサポートしています。 ロックは、JPAの@Versionアノテーションeclipselink.read-onlyを使用して設定します。 「How to Use EclipseLink Locking」( デフォルト値: ロックなし |
同時に更新可能なエンティティには、ユーザーが他のユーザーの変更を上書きできないようなロック・ポリシーを使用することを検討してください。読取り専用エンティティのパフォーマンスを最適化するには、エンティティを読取り専用として定義するか、読取り専用の問合せヒントを使用することを検討してください。 |
|
キャッシュの使用方法 |
デフォルトでは、どのタイプの問合せも、まずデータベースを検索してからキャッシュと同期を取ります。問合せにリフレッシュが設定されている場合を除き、キャッシュされたオブジェクトはデータベースからリフレッシュされずに返されます。特定の問合せを、メモリー内キャッシュ、データベース、その両方のうち、いずれに対して実行するかを指定できます。 すでにキャッシュにあるオブジェクトがデータベースで検索されるのを防いでパフォーマンスを向上させるには、検索の際に必要なオブジェクトをまずキャッシュから取得し、オブジェクトがキャッシュに存在しない場合にのみデータ・ソース内を検索するよう構成します。主キーに基づいて単一オブジェクトを検索する問合せについては、問合せヒント デフォルト値: |
通常はデータがキャッシュにあり、リフレッシュ処理をそれほど必要としない場合に、主キー問合せのパフォーマンスを高速化するには、まず主キー問合せでキャッシュをチェックすることをお薦めします( これにより、まずデータベースからオブジェクトを取得した後、すでにキャッシュにあるオブジェクトを検索し、キャッシュされた値(問合せにリフレッシュが設定されている場合を除き、データベース・アクセスによって更新されていない)を返すというデフォルト動作を回避できます。 |
|
分離 |
EclipseLinkを使用するJPAアプリケーションには、特定のデータベース・トランザクションの分離レベルを単独で設定するチューニング・パラメータはありません。 一般的なEJB3.0 JPAアプリケーションでは、データベース・トランザクションの分離レベルが適用されるタイミング、および特定のデータベース・トランザクションを分離できる程度には、次のような様々な要素が影響を与えます。
関連項目: 「Shared and Isolated Cache」( |
|
|
キャッシュのリフレッシュ |
デフォルトでは、EclipseLinkはデータ・ソースから読み取ったオブジェクトをキャッシュします。このオブジェクトに対する後続の問合せではキャッシュへのアクセスが行われるため、データ・ソースへのアクセスが減るとともに、オブジェクトとそのリレーションシップを再構築するコストも発生せず、パフォーマンスが向上します。問合せでデータ・ソースにアクセスする場合でも、返されたレコードに対応するオブジェクトがキャッシュに存在すれば、EclipseLinkはキャッシュされたオブジェクトを使用します。このデフォルトのキャッシュ・ポリシーは、失効したデータがアプリケーション内に生じる原因となります。 リフレッシュは、エンティティ・レベル( 詳細は、第9.2.2.1項「キャッシュ・リフレッシュのシナリオ」を参照してください。 関連項目: 「Caching Overview」( デフォルト値: キャッシュのリフレッシュなし |
エンティティ・レベルでのキャッシュのリフレッシュはできるかぎり避け、かわりに次の構成を検討してください。
|
キャッシュでのデータのリフレッシュに関して、考慮すべきシナリオがいくつかあります。これらのシナリオはいずれも、パフォーマンスに影響を与えます。
キャッシュされたデータではなく、最新のデータが常に必要な場合は、分離キャッシュ(Shared=False)を使用することを検討してください。これに当てはまるのは、アプリケーション内の特定のデータが頻繁に変更されるため、競合が検出されたときにのみデータをリフレッシュするのではなく、常にデータをリフレッシュすることが望ましいような場合です。
失効したデータは使用したくないが、失効したデータを取得することになっても大した問題ではないという場合は、解決策としてキャッシュ失効ポリシーを使用することをお薦めします。この場合は、ロック・エラー発生時に失効したオブジェクトを自動的にリフレッシュする、オプティミスティック・ロックも使用してください。オプティミスティック・ロックを使用する場合は、エンティティの@Cache属性であるalwaysRefreshおよびrefreshOnlyIfNewerをさらに有効にすると、データベースにアクセスする問合せで、返された失効オブジェクトをリフレッシュできるとともに、無効なオブジェクトが変更されていない場合はリフレッシュしないようにできます。また、リフレッシュされたデータが必要であることがわかっている場合に、特定の問合せ操作に対してリフレッシュを有効にしたり、クライアントから取得したデータをリフレッシュするオプション(リフレッシュ問合せをコールするもの)を提供したりすることもできます。
データが失効していても問題ない場合は、オプティミスティック・ロックを使用してください。そうすると、ロック・エラーの際にキャッシュ内の失効したオブジェクトが自動的にリフレッシュされます。
表9-4に示すロック・モードを、EclipseLinkのキャッシュ使用方法および問合せリフレッシュのオプションとともに使用すると、JPAを使用するEJBエンティティのデータ一貫性が保証されます。どの組合せも機能とパフォーマンスの両面に影響を与えますが、これらのオプションの設定は、たとえパフォーマンスのコストが発生したとしても、データを最新で一貫した状態に保つための機能上の要件を優先して決めるのが一般的です。
詳細は、「Locking」(http://wiki.eclipse.org/EclipseLink/UserGuide/JPA/Basic_JPA_Development/Mapping/Locking)を参照してください。
表9-4 ロック・モード・ポリシー
| ロック・オプション | 説明 | パフォーマンス上の注意点 |
|---|---|---|
|
ロックなし |
ユーザーが別のユーザーの変更内容を上書きできます。これはデフォルトのロック・モードです。エンティティが同時に更新されることがない場合や、read-committedセマンティクスによる同じ行の同時読取りおよび更新で十分な場合は、このモードを使用します。 デフォルト値: ロックなし |
通常はロックなしのほうが高速ですが、データ一貫性のニーズには対応できない場合があります。 |
|
オプティミスティック |
すべてのユーザーがデータへの読取りアクセス権限を持ちます。ユーザーが変更を加えようとした場合、そのユーザーがデータを読み取った後にデータが変更されていないか、アプリケーションによってチェックされます。 関連項目: 「Optimistic Locking」( |
同じ行に対する同時更新を頻繁には実行しないと予想される場合、オプティミスティック・ロックを使用すれば、最適なパフォーマンスを得ながら、データの一貫性も保証することができます。 |
|
ペシミスティック |
更新目的でデータにアクセスした最初のユーザーによって、更新処理が完了するまでデータがロックされます。 |
同じ行に対して頻繁に同時更新を実行することが予想される場合、同時アクセスの例外および再試行が多数発生するオプティミスティック・ロックより、ペシミスティック・ロックのほうが高速になることがあります。 エンティティ・レベルでペシミスティック・ロックを使用する場合は、最適なパフォーマンスを得るために、分離キャッシュ(Shared=False)を併用することをお薦めします。 |
|
読取り専用 |
EJB3.0 JPAエンティティを読取り専用に設定すると、そのエンティティは変更できなくなり、EclipseLinkが作業ユニットのパフォーマンスを最適化できるようになります。 @ReadOnlyクラス・アノテーションを使用して、エンティティ・レベルで設定します。問合せヒント |
エンティティを読取り専用として定義すると、読取り専用として定義されていないが、挿入、更新または削除を行わないエンティティよりも、パフォーマンスが向上します。これは、EclipseLinkによる作業ユニットのパフォーマンスの最適化が可能になるためです。すべての読取り専用操作に対して、常に読取り専用を使用してください。 |
EclipseLinkでは、オブジェクト表現とデータ・ソース固有の表現との間でデータのトランスフォーメーションを実行できます。このトランスフォーメーションをマッピングと呼びます。マッピングは、EclipseLinkプロジェクトの中核をなしています。
マッピングはそれぞれ、ドメイン・オブジェクトの単一データ・メンバーに対応しています。マッピングによって、オブジェクト・データ・メンバーをそのデータ・ソース表現と関連付け、オブジェクトとデータ・ソースの間の双方向変換を実行する手段を定義します。
マッピングの詳細は、「Configuring Mappings」(http://wiki.eclipse.org/EclipseLink/UserGuide/JPA/Basic_JPA_Development/Mapping)を参照してください。
EclipseLinkでは、@Partitionedアノテーションを使用してデータのパーティション化を構成できます。パーティション化すると、アプリケーションはクラスタ・データベースなどの複数のデータベース間で情報を増減できます。@Partionedおよびその他のパーティション・ポリシー・アノテーションの使用方法の詳細は、「Data Partitioning」(http://wiki.eclipse.org/EclipseLink/UserGuide/JPA/Advanced_JPA_Development/Data_Partitioning)を参照してください。
前の項で推奨されている変更を行った後、デプロイメントに固有の変更をさらに行うことができます。この項の推奨事項は、ご使用の環境に適しているかどうか慎重に検討してください。
Oracle Toplinkは、Oracle Coherenceと統合できます。この統合は、Oracle TopLink Grid機能によって実現されます。TopLink Gridを使用したEclipseLink JPAとの統合には、いくつかの種類があります。
例:
EclipseLinkのデフォルトL2キャッシュをCoherenceに置き換えます。こうすることで、クラスタ・ノード全体をカバーする非常に大きなL2キャッシュがサポートされます。EclipseLinkのデフォルトL2キャッシュは、Java EEでホストされたマルチスレッド・アプリケーションが単一のJVMで稼働する場合のパフォーマンスを高めます。これをクラスタ全体で使用する場合は、特殊なキャッシュ調整機能を構成する必要があります。
データベースではなく、Coherenceのデータ・グリッド内で問合せを実行するよう、エンティティを構成します。こうすると、クラスタ化されたアプリケーション・デプロイメントを、データベースがボトルネックとなるような操作を越えて拡張できます。
EclipseLink JPAとCoherenceキャッシュの併用の詳細は、グリッド上のJPA手法に関する項(http://www.oracle.com/technology/products/ias/toplink/doc/11110/grid/tlgug003.htm)を参照してください。
Oracle ToplinkとOracle Coherenceとの統合の詳細は、Oracle TopLinkとCoherenceグリッドとの統合ガイド(http://www.oracle.com/technology/products/ias/toplink/doc/11110/grid/toc.htm)を参照してください。
この項では、JPAアプリケーションのパフォーマンス分析に役立つEclipseLinkの機能をいくつか示します。
パフォーマンスの監視の詳細は、『EclipseLink User's Guide』の「Performance Monitoring」を参照してください。このツールは、マルチスレッド化されたサーバー環境の情報をプロファイルおよび監視することを目的としています。
パフォーマンスのプロファイリングについては、『EclipseLink User's Guide』の「Measuring EclipseLink Performance with the EclipseLink Profiler」を参照してください。このツールは、シングルスレッドの限定的なユースケースでの使用を想定しています。
パフォーマンスの問題のデバッグおよびテストを行う場合、EclipseLinkから生成されたSQLを確認できます。SQLを確認するには、ロギング用のEclipseLink JPA拡張機能を使用して、ロギング・レベルをFINEに上げます。
最適なパフォーマンスを得るために、プロファイリングまたはデバッグが終了したら、必ずロギング・レベルをデフォルト・レベルに戻してください。
