アプリケーションに応じたAOP による高速化が可能な

永続システム数理・計算科学専攻　千葉研究室

青木 康博指導教官 : 千葉 滋

2

永続オブジェクト・システム リファレンスを辿る際に自動的に SQL 発行

データベースを意識する必要がない O/R 間のインピーダンス・ミスマッチを解消

アプリケーションの開発効率を高める

class Paper { String title Author author; …}

class Author { String name; Location location; ….}

< paper table >12 GlunJ

Josh 3098

・・・

・・

・

id title authr_id

9899 Tobe

Aoki

・・・

・・

・

id name

< author table >

自動的なデータ取得

永続クラス

データベース

Paper p = …;Author a = p.author

SELECT id FROM author t0 WHERE t0.id = 98

EJB2など

3

高速化の必要性 リファレンスを辿る毎に SQL を発行してい

ては 効率が悪すぎる データベースからの効率よいデータ取得が必要

まとめてデータを取得すれば SQL 発行を最適化出来る

E.g.) Author オブジェクトのみを一括して取得したい

<RDB>

papersauthrs

過剰な DB アクセス

void showPaperList(List papers) { Iterator it = papers.iterator(); while(it.hasNext()) { Paper p = (Paper)it.next(); Author a = p.getAuthor(); / * p.title と a.name を表示 */}

Author を取

得

4

高速化のためのカスタマイズ例 効率よくデータを取得したい

今後利用されるデータを先読みし、まとめて取得したい 処理内容に応じて先読みするデータをカスタマイズ

void showPaperList(List papers) { Iterator it = papers.iterator(); while(it.hasNext()) { Paper p = (Paper)it.next(); show(p);}}

<RDB>

papersauthrs

過剰な DB アクセス

Author を取

得

List papers

p0

p1

p2

Paper

Paper

Paper

void getGenres(List papers) { while(…) { Paper p = (Paper)it.next(); Genre g = p.getGenre(); ….}}

過剰な DB アクセス

g0

g1

g2

Genre

Genre

Genre

a0

a1

a2

Author

Author

AuthorAuthor ではなくGenre を取得

5

void getGenres(List papers) { while(…) { Paper p = (Paper)it.next(); Genre g = p.getGenre(); ….}}

従来のオブジェクト指向による クラスごとのカスタマイズ 効率のよいデータ取得が実現出来ない

過剰な DB アクセスをなくそうとすると、不必要なデータを大量に取得してしまう

void showPaprList(List papers) { Iterator it = papers.iterator(); while(it.hasNext()) { Paper p = (Paper)it.next(); show(p);}}

<RDB>

papersauthrs

class Paper { String title; …} 過剰な DB

アクセス

@FETCH Author author;

Genre を取得Author は不要

@FETCH Genre genre;Genre genre;

Author を取得Genre は不要

6

提案 : AspectualStore の開発 アスペクト指向による高速化を支援する永続システム

アプリケーションの文脈に応じたクラス横断的なカスタマイズ リファレンスの辿られ方に応じて最適化の指示を変更できる

最適化の指示をアスペクトとして分離 徐々に最適化の指示を追加できる

prc List papers

showPaperList(List) { …

}

getGenres(List) { …

}

Proceeding

p0

Paper

ownr

p0

Paper

Author

gnr

Genre

最適化の指示

p0

p1

p2

7

永続システム : AspectualStore アスペクト指向による高速化を

支援 コード量 : 18,000 行程度 外部企業が現在デモアプリを A

spectualStore 上で開発中

より大規模な実験を行う予定

<デモアプリ >

8

アスペクト記述

class PrefetchDefine { @before(“{Persistable p = $1; Loader l = $1.getBody().getLoader(); l.addFetch(“author”); l.load(); }”) Pointcut p1 = Pcd.call(“showPaperList(..)”);

@before(“{ Persistable p = $1; Loader l = $1.getBody().getLoader(); l.addFetch(“author”); l.load(); }”) Pointcut p2 = Pcd.call(“getGenres(..)”);}

showPaperList() に対する最適化 ・ Author オブジェクトを先読み

getGenres() に対する最適化 ・ Genres オブジェクトを先読み

メソッド処理ごとのデータ取得の指示

9

void showPaprList(List papers) { Iterator it = papers.iterator(); while(it.hasNext()) { Paper p = (Paper)it.next(); show(p); …}}

先読みすべきデータを動的に決定するアスペクトも可能

どのようにリファレンスが辿られるかを検出 リファレンスの辿られ方がわかりにくい場合 最適化の指示をまとめて記述したい場合

Paper p0

LocationAuthor a

namePaper p1

Paper p2・・・

papers1st iteration : リファレンスの辿り方を収集 2nd iteration : papers 先読みの指示を出す

それ以降の DB アクセスは発生しない！

title

title

Author a

name

Author a

name

・・・title

10

アスペクト記述 : GluonJ @Glue 　 public class PrefetchDefine { /* Context の定義 */ @Refine static class ContextDefine extends Context { Set loadedFields = new HashSet(); int depth = 0; }

/* DB アクセスを引起したパスの格納 */ @Before(“{ // フィールド名を格納 }") Pointcut pc = Pcd.call("...PersistentEntity#load*(…)");

/* prefetch 定義 */ @Refine static class IteratorDefine extends PersistentIterator { public Object next(Context cxt) { if(context.hasLoadedFields()) // context の内容を先読み super.next(cxt); }}

Context クラスに DB アクセス履歴を格納するためのフィールドを定義

papers に付加された Context にshowPaperList() 内で DB アクセスを引き起こしたフィールドのパスを追加

Iterator.next() を拡張して、本来の処理の前に先読み処理を追加

11

アスペクトによる最適化の支援 既存の永続システム + AOP だけでは不十分

最適化の指示に煩雑な記述が必要 リファレンスの辿られ方を管理する必要がある

アスペクト内からアプリケーションの文脈を利用出来ない

AspectualStore が提供する主な機能 最適化を行ための API

永続オブジェクト ( コレクション ) への最適化の指示 アプリケーションの文脈を格納するための機構

アスペクトからアプリケーションの文脈を利用可能 Tomcat からのロードタイム・ウィービング

アスペクトのウィーブ / アンウィーブの手間を削減

12

著者 X’

著者 P’

著者 Q’

最適化を指示する API 永続オブジェクトに直感的に指示が出せる API

直接 SQL を記述するのは煩雑すぎる 外部キーの名前と値が必要 記述すべき SQL はリファレンスの辿られ方によって異なる

paper テーブル

author テーブル

PK name

PK title

< データベース >

Paper P

List papers

prc

“FROM Paper FETCH p.title LEFT JOIN FETCH p.author.. WHERE t0.prc_id = 98”

<Hibernate によるデータ取得の記述 > author.nameと title を取得

Paper Q

Paper XProceeding

prc_id9898

98

jrl

Journal

gen

Genre

name

name

name

13

最適化を指示する API

journal テーブル

Paper P

List papersprc

journl

Paper Q

Paper X

発行する SQL はリファレンスの辿られ方によって異なる

PK

18 paper テーブル

PK prc_id123456

jrl_id5

55

18

18

18

Proceeding

Journal

“FROM Paper FETCH p.title LEFT JOIN FETCH p.author.. WHERE t0.prc_id = 5”

“FROM Paper FETCH p.title LEFT JOIN FETCH p.author.. WHERE t0.jrl_id = 18”

proceeding テーブル

PK

5

著者 X’

著者 P’

著者 Q’

author.nameと title を取得

<Proceeding から取得された場合 >

<Journal から取得された場合 >

14

最適化を指示する API 永続オブジェクトに直感的に指示が出せる API

直接 SQL を記述するのは煩雑すぎる 外部キーの名前と値が必要 発行する SQL はリファレンスの辿られ方によって異なる

paper テーブル

author テーブル

PK name

PK title

< データベース >

Paper P

List papersloader.addFetch(“title”);loader.addFetch(“author.name”);loader.load();

<AspectualStore>

著者 X’

著者 P’

著者 Q’

author.nameと title を取得

Paper Q

Paper X

・データベースに関する作業を意識する必要がない

・外部キーの名前や値 ・どのようにリファレンスを辿ってきたかを AspectualStore が内部で管理 ( 後述 )

15

アプリケーションの文脈を格納 文脈を格納するための機構

アスペクトからアプリケーションの文脈を利用したい メソッド内でどのようなリファレンスが辿られるか SQL を発行するためには、親オブジェクトが必要

既存の永続システム + AOP では不十分 時間的に素なデータ・アクセスの取得は困難

refine や cflow を駆使した煩雑な記述が必要 永続オブジェクトは何度も再利用される

単純に親への参照を持たせるだけでは不十分

Paper p0 Author a Location

title name

Paper p1・・

・

List papersProceedng prc

Journal j

[’05 Awais ら ]

16

アプリケーションの文脈を利用可能

Paper< モデル >

•entity•context

Context•親コンテキストへの参照•親コレクションへの参照

PersistentEntity•values•state

< キャッシュ >

< 文脈情報 >

論文 X 著者 A 論文 Q

論文 X’

論文 P

author papers

Set

キャッシュContxt Contxt

共有個別 個別

親 : 学会 親 : 著者 A

title=“aop”year=1999

永続オブジェクトに Context オブジェクトを付加 Context クラスを拡張 => アプリケーション文脈を管

理 Context 　 : リファレンス毎に新たに生成 キャッシュ : 何度も再利用されるE.g.) 論文 X => 学会 W から参照 論文 X’=> 著者 A から参照

学会 W

17

ロードタイム・ウィービング ウィーブ / アンウィーブにかかる手間を削減

AspectualStore への拡張を JAR ファイルに反映させる必要なし

Tomcat 用のクラスローダを実装

Common CL

Catalina CL Shared CL

WebApp CLASClassLoader

< アプリケーション起動時 > 永続クラスへのバイトコード変換 ・ 永続化処理の追加 ( リファレンスが参照された 際の SQL 発行 ) ・ Context クラスの追加< クラスのロードタイム時 > アスペクト記述の反映

18

AspectualStore による最適化の得失 アプリケーションの挙動を変える最適化はできない

誤った最適化指示は無視される JDBC で直接指示する程の最適化は出来ない例 ) 主キーは必ず取得

Proceeding prc = …;List papers = prc.getPaprs();for( Paper p : papers) { if(p.getGenre().equals(“AOP”) { // show Paper details. }}

prc

Proceeding

paper テーブル

PK genre123456

AOP

AOPPaper p1

Paper p4

papers

AOP

AOP

Paper p3

Paper p6

AOP

AOP

Expression exp = ExpFactory.eq(“genre”, “AOP”);loader.add(exp);

19

時間・ DB アクセス・メモリ量の比較実験

既存の永続システム オブジェクト指向によるク

ラス毎の最適化 AspectualStore

アスペクト指向による文脈に応じた最適化

SQL 直書き JDBC を直接利用してほし

いデータを指示

Paper

Author Location

Genre

Bibliography

year

Journalnamevol

Proceedingnameintro

titleabstractcontent name

nameage

countrytown

journals

papers papers

genre

author

location

proceedngs

papersサーバ： P4 Xeon 3.06G, 2GB,PostgreSQL 7.4.2DB サーバ： Linux 2.6.7アプリケーションサーバ： Mac OSXTomacat 5.5, Java 1.5LAN 1000 BaseTX

文献検索システム

20

実験結果

既存の永続システムに比べて大幅な速度向上を確認 DB 通信回数 / 取得データ数の削減 オブジェクト生成数は同等

実行時間(秒 )

DB 通信(回 )

オブジェクト生成 ( 個 )

取得データ数 ( 個 )

既存永続システム

AspectualStore

SQL 直書き

3.48

2.46

2.16

43

8

6

381

381

181

2528(1522)

759(289)

471(287)

予備的な実験においては…

30% 向上

38% 向上

括弧内は主キー と外部キーを除いた値

21

関連研究１： O/R mapper

SQL 直書きとリファレンス参照の併用

リファレンス参照は従来同様、非効率 高速な参照が必要なときは SQL を直接書く

AspectualStore では SQL ではなく高速化のヒントを記述 最適化コードが元のプログラムに混在

String query = “FROM Proceeding p LEFT JOIN FETCH p.papers LEFT JOIN FETCH p.papers.author WHERE …”;// ルート・オブジェクトの取得Proceeding p = s.createQuery(query).load;List<Papers> papers = p.getPapers();showPaperList(papers);

利用されそうなオブジェクトを

ルート・オブジェクトに含める

•Hibernate•Cayenne•Torque …

22

関連研究２：自動的な最適化 アスペクト記述が必要ない

Context-cotrolled prefetch 　 [Philip at al. ‘99] データベースのアクセス・パターンを基に最適化

AUTOFETCH [Ali et al. ‘06] プロファイリングによる最適化

PrefetchGuide [Wook-Shin et al. ‘03] 実行時のアクセス・ログによる動的な最適化

AspectualStore 手動できめ細かな最適化

メソッド処理などのオブジェクト以外の文脈も利用可能 性能テストをしながら徐々に最適化が可能

23

まとめ AOP を利用して高速化が可能な永続システム :

AspectualStore の開発( コード量： 約 18,000 行 )

アプリケーション文脈に応じた最適化が可能 クラス横断的な処理を AOP でモジュール化

クラス毎の最適化指示だけでは不十分

AOP による最適化を容易に実現する構造を用意 永続オブジェクトへ指示を出すための API アプリケーションの文脈を格納するための機構 ロードタイム・ウィービング