SQLの代替ではありません

OLTPとOLAPのユースケース

OLTPとOLAPのユースケースにおけるEbeanの適合性、手動でSQLを提供する場合

Ebean ORMクエリは、典型的なOLTPクエリのユースケースに適していますが、ORMが不得意とするSQLで記述できるクエリ、特にレポート作成とOLAPの分野では多数存在します。再帰SQLクエリも現在は十分にサポートされていません。

Ebean ORMクエリはOLTPに重点を置いています。適切な場合はSQLを使用することを忘れないでください。

Ebeanは、OLTPユースケースにORMクエリを使用することに重点を置いています。ORMクエリ言語を拡張するのではなく、RawSqlSqlQuery、そして今後期待されるJOOQとの統合を通じて、SQLとの良好な統合を実現することを計画しています。

オブジェクトグラフの構築

ORMクエリをオブジェクトグラフの構築と考えることは有用です。つまり、ORMクエリを作成する際には、オブジェクトグラフのどの部分をロードし、どのようなフィルタ/述語を適用する必要があるかを定義します。

ロード

Ebeanでは、select()fetch()がオブジェクトグラフのどの部分をロードするかを制御します。select()はオブジェクトグラフのルートレベル用で、fetch()はオブジェクトグラフの葉用です。より高度なケースでは、FetchConfigを使用して、グラフのどの部分をeager/lazyにロードするか、そしてグラフのその部分をデータベース、L2キャッシュ、またはL3キャッシュ/ドキュメントストアからロードするかを制御できます。

オブジェクトグラフの一部は、L2キャッシュまたはL3/ドキュメントストアからロードできます

ロード - クエリチューニング

ORMクエリを最適なパフォーマンスにチューニングするには、次の点に留意する必要があります。

  • ロードするプロパティ(特定のユースケースに必要なものだけをロードする)
  • オブジェクトグラフのどの部分をEagerまたはLazyにロードするか
  • オブジェクトグラフのどの部分をデータベース、L2キャッシュ、またはL3ドキュメントストアからロードするか
  • クエリをまったく実行せず、L2クエリキャッシュを使用する
  • クエリをまったく実行せず、L3ドキュメントストアを使用する

ロード - 自動チューニング

Ebeanの自動チューニング機能は、アプリケーションによってオブジェクトグラフのどの部分が使用されているかをプロファイリングし、ORMクエリの「何をロードするか」の部分を自動的にチューニングする機能を備えています。つまり、自動チューニングは、データベースからの必要なデータのみをフェッチし(クエリのネットワークとデータベースのコストを削減)、遅延ロードを最小限に抑えるために、ORMクエリのselect()fetch()の部分がどうあるべきかを提案できます。

Ebeanは「何をロードするか」を自動的に調整できます

述語

where()句は、クエリの述語を定義する場所です。これは事実上「アプリケーションロジック」であり、「チューニング」などの目的では変更されません。

述語 - 型安全性

Ebeanの型安全クエリ拡張は、型安全な方法でクエリ述語を構築するように設計されています。そのため、`select()`および`fetch()`句(主に自動チューニングによって定義されることが想定されています)を介して「何をフェッチするか」に型安全性を提供することに重点を置いていません。

自動結合

Ebeanのクエリ言語は、クエリで結合を明示的に指定するのではなく、「何をロードするか」と「述語」を定義するように設計されています。Ebeanは、クエリのロードと述語の両方の側面をサポートするために必要な結合を決定します。SQL結合の一部は、ロードと述語の両方で共有できますが、一部は共有できません。外部結合は、特定のオブジェクトパスに「継承」されます。Ebeanは、ロードと述語の両方に関係する関係/パスのカーディナリティとオプション性に基づいて、追加する結合と結合タイプを決定します。

このアプローチの欠点は、「セルフ結合」を使用する述語を現在簡単に指定できないことですが、この問題は対処される予定であり、Ebeanが結合を自動的に決定するという点には非常に大きな利点があります。

デカルト積の回避

EbeanはSQLデカルト積を生成しません。ORMクエリがどれほど複雑または大きくなっても、EbeanはSQLデカルト積を生成せず、代わりにクエリを複数のSQLクエリに分割します。

FirstRows MaxRows

FirstRowsMaxRowsは、常にORMクエリで機能します。つまり、firstRows/maxRowsはリレーショナル行(オブジェクトではなく)で機能し、EbeanはfirstRows/maxRowsが意図したとおりに機能するように、必要に応じてORMクエリを複数のSQLクエリに自動的に分割します。

任意の複雑なグラフ

ORMクエリのオブジェクトグラフがどれほど複雑またはネストされていても、Ebeanは非常に効率的な方法でそれを構築できます。具体的には、単一のSQLクエリには、最大で1つのOneToManyまたはManyToMany関係の「パス」を含めることができます(SQLデカルト積を生成せずに、これは実際に避けたいことです)。Ebeanは、ORMクエリを複数のSQLクエリに分割し、各SQLクエリはフェッチに単一のOneToMany/ManyToMany関係を持ちます(各SQLクエリは、デカルト積にならない限り、可能な限りeager/大きくなります)。

Ebeanはすべてのフェッチパスを処理し、どのパスにOneToManyまたはManyToMany関係が含まれているかを判断します。クエリの「分割」は、FetchConfigを使用して手動で制御できますが、これが行われていないか、必要なすべてのリレーションシップをカバーしていない場合、Ebeanはこれらの「多重関係を含むパス」に基づいてクエリを自動的に分割します。


用語

ロードコンテキスト

「ロードコンテキスト」は、非常に重要なジョブを持つEbeanの内部機能です。セカンダリクエリの実行をサポートし、以下を提供します。

  • バッチ遅延ロード
  • クエリ結合(Eagerセカンダリクエリ)
  • 元のクエリから任意/すべてのセカンダリクエリへの主要なクエリ状態の伝播。

本質的に、ロードコンテキストは複雑なグラフのバッチロードのメカニズムを提供します。

オリジンクエリ

「オリジンクエリ」とは、オブジェクトグラフの構築時に実行される元のSQLクエリを指すEbean用語です。さらに、SQLの「セカンダリクエリ」を実行して、「オリジンクエリ」に関連付けることができます。

サマリロギング

サマリロギングには、origin属性があり、これはオリジンとセカンダリクエリをリンクするために使用できるキーです。

txn[1012] FindBean type[Order] origin[B0dP9E.DWeHD4.5WUnB] ...

セカンダリクエリ

「セカンダリクエリ」とは、以前に実行された「オリジンクエリ」に関連するSQLクエリを指すEbean用語です。これらのセカンダリクエリは、遅延ロードが原因で、または単一のORMクエリが手動または自動で複数のSQLクエリに分割される(デカルト積を回避し、firstRows/maxRowsをサポートするため)ために実行される可能性があります。

サマリロギング

サマリロギングでは、mode属性とorigin属性を使用して、どのSQLクエリが「セカンダリクエリ」であり、どのオリジンに関連しているかを識別できます。このロギングは、たとえば、過剰な遅延ロード(N + 1)を識別するために使用できます。

  • mode : 遅延ロードクエリの場合は+lazy、クエリ結合/eagerロードの場合は+query
  • origin : このキーは、セカンダリクエリをオリジンにリンクします
txn[1012] FindBean type[Order] origin[B0dP9E.DWeHD4.5WUnB] ...
...
txn[1016] FindMany mode[+lazy] type[Customer] origin[B0dP9E.DWeHD4.5WUnB]  ...
...
txn[1017] FindMany mode[+lazy] type[Address] origin[B0dP9E.DWeHD4.5WUnB]  ...