vldb2015 会議報告

国際会議参加報告 41st International Conference on Very Large Data Bases

VLDB 2015

東京大学生産技術研究所特任研究員　早水悠登

2015/12/12 1 2015/12/12 @ 東京大学生産技術研究所第24回先端的データベースとWeb技術動向講演会 (ACM SIGMOD 日本支部第61回支部大会) 講演資料

Agenda •  講演前半：概要紹介・基調講演等–  VDLBの概要紹介・2015年度開催概要– チューリング賞受賞記念講演–  VLDB 40周年記念パネル–  10-year Best Paper Award–  Keynotes

•  講演後半：研究動向紹介– 投稿論文の傾向– システム系論文の動向– ベストペーパー賞– ベストペーパー次点 – 注目の論文

2015/12/12 2

講演前半 •  VDLBの概要紹介・2015年度開催概要•  チューリング賞受賞記念講演•  VLDB 40周年記念パネル•  10-year Best Paper Award•  Keynotes

2015/12/12 3

International Conference on Very Large Data Bases

•  データベース分野のトップ会議– VLDB, SIGMOD, ICDE が所謂トップ3– NPO法人 VLDB Endowment Inc. が運営

• 他2つは学会が主体となって運営

•  1975年に第1回開催 (同年 SIGMOD第1回)– VLDB 2015 はちょうど40周年

2015/12/12 4

VLDBの特徴

•  論文を毎月投稿可能（2009年～）–  6月15日まで採録決定 → その年のVLDBで発表– 例年3月分が投稿数ピーク

2015/12/12 5

12/20 例：2016年1月分

1/1 17:00PST 投稿受付

査読

改訂期間（投稿につき1回のみ）

約1.5ヶ月最大3ヶ月

再査読

改訂提出の翌月15日

4.8% (2015)

accept ☺ 84.6% of revised papers (2015)

accept ☺

VLDBの特徴

•  The Proceedings of VLDB Endowment (PVLDB) でジャーナル論文として出版– 更に拡張して VLDB Journal にも投稿可能

2015/12/12 6

ACMでも同様の動き?

2015/12/12 7

By courtesy of ACM トップ会議の論文を Proceedings of ACM というジャーナル論文として編纂・出版することを検討

2015/12/12 8

VLDB 2015 •  Kohala Coast, Hawaii •  2015/8/31 ～ 9/4– 1日目: ワークショップ– 2～4日目: 本会議– 5日目: ワークショップ

Honolulu

VLDB 2015 参加者数 2013 2014 2015

米国 204 ↑232 ↑↑434 中国 (2014開催) 30 ↑↑↑217 ↓↓↓56 ドイツ 92 ↓↓57 ↓52 カナダ 17 ↑20 ↑30 韓国 27 ↓26 ↑27 日本 43 ↓25 ↓21 スイス 27 ↓22 ↓18 英国 15 ↓13 ↑18 フランス 35 ↓↓19 ↓17 シンガポール 13 ↑22 ↓15 香港 13 ↑↑46 ↓13 オーストラリア 2 ↓1 ↑12 インド 6 ↑7 ↑11 スウェーデン 4 ↓2 ↑9

2013 2014 2015 イスラエル 7 7 7 カタール 8 ↑9 ↓7 イタリア (2013開催) 80 ↓↓↓9 ↓6 サウジアラビア 6 ↓3 ↑6 ブラジル 2 ↑3 ↑4 ノルウェイ - - 4 フィンランド - - 1 ギニア - - 1 ハンガリー - - 1 アイルランド - - 1 ポーランド - - 1 台湾 2 ↑4 ↓1 タイ - - 1 チュニジア - - 1

2015/12/12 9

•  開催国効果で米国が倍増•  日本は減少傾向

論文採択数

2015/12/12 10

Research papers

151 accepted

21% of 710 submissions

Industrial papers

20 accepted


Demo papers

40 accepted


+ 21 rollovers from VLDB 2014

年間の投稿数の推移

•  やはり年度〆切直前が一番多い 2015/12/12 11

By courtesy of Volker Markl

国別の投稿/採録数

2015/12/12 12 By courtesy of Volker Markl

日本からは5件が採録

Videos & Slides Online •  http://www.vldb.org/2015/videos.html–  Opening remark–  Keynotes–  Panels–  Award lectures

•  かつての会議で見れなかった大抵の映像/スライドが見れます

•  この参加報告の意義とは...!?– 感じ取ったメッセージや技術的背景など、自分なりに解釈した中身を伝えられるよう努めます

2015/12/12 13


2015/12/12 14

“Congrats Mike!” •  Michael Stonebraker のチューリング賞受賞お祝いムード一色

•  4人目のデータベース分野受賞者– Charles Bachman (1973)

•  ナビゲーショナルデータベース “The Programmer As Navigator”

– Edgar F. Codd (1981)•  リレーショナルデータベース

“Codd’s biggest overall achievement was to make database management into a science. ” (Chris Date)

–  Jim Gray (1998)•  トランザクション処理

2015/12/12 15

2015/12/12 16 By courtesy of MIT

近代的なデータベースシステムの礎を築いた

VLDB2015 は Stonebraker三昧 •  チューリング賞受賞記念講演

•  VLDB 40周年記念パネル

•  VLDB 10-year Best Paper Award 受賞講演

2015/12/12 17

チューリング賞受賞記念講演

The Land Sharks are on the Squawk Box (How Riding a Bicycle across America and Building Postgres Have a Lot in Common)

Michael Stonebraker

2015/12/12 18

The Land Sharks are on the Squawk Box

(How Riding a Bicycle across America and Building Postgres Have a Lot in Common)

•  Land Sharks – 地上げ屋– ここでは”親しみを込めて”投資家のこと

•  Squawk Box– ポリコム的なもの

2015/12/12 19



•  2つの回想録– Postgresプロジェクト(Illustra創業)– Stonebraker夫妻のアメリカ横断自転車旅行

•  Stonebrakerの“語り”が面白い– 是非YouTubeで視聴しましょう :)

2015/12/12 20



•  2つの回想録– Postgresプロジェクト(Illustra創業)– Stonebraker夫妻のアメリカ横断自転車旅行

•  Stonebrakerの“語り”が面白い– 是非YouTubeで視聴しましょう :)

2015/12/12 21

山あり谷あり

2015/12/12 22

By courtesy of Michael Stonebraker

Postgresプロジェクト始動 (‘84-86)

•  Ingresプロジェクトが一段落–  System-Rと並ぶ最初期の関係データベース実装– Relational Technology, Inc. を起業し商用化(1980)

•  後継としてPostgresをBerkeleyで立ち上げ•  意気揚々と新たなアイディアを温める– Abstract Data Types– 新たなルールシステム– 追記型アーキテクチャ

2015/12/12 23

Abstract Data Types (ADTs) •  Ingresでは業務データ処理に集中– 敵はIMSやCODASYL– 扱うデータ型は数値、文字列だけ

•  新たなデータ型・演算子・関数をユーザ定義可能に– 例: GISデータ処理

•  矩形・ポリゴンオブジェクト•  重複判定(Overlaps)演算子など

2015/12/12 24

Select name where xmin < 17 and xmax > 14 and ymin < 16 and ymax > 0

Select name where Overlaps(location, MakeBox(14, 0, 17, 16)

新たなルールシステム •  整合性制約やトリガ = ルール– 発火の契機 (挿入、更新のイベントなど)– 発火条件– 処理 (deleteのカスケード、挿入・更新・削除の拒否など)

•  旧来のIF-THENルールシステム– 結果にルール適用の順序依存性– 順序のない relation (タプル集合) と相性が悪い

•  アイディア：Update ALWAYS コマンド

2015/12/12 25

Update ALWAYS (set salary = E.salary) where E.name = “Sam” and name = “Bill”

追記型アーキテクチャ

従前のクラッシュリカバリ •  2つのデータストア•  データ更新とログ書き込みの慎重な同期が必要

•  ログのコードが複雑化

2015/12/12 26

Postgres Approach •  データの上書きを一切しない•  “タイムトラベル”

Images by courtesy of Michael Stonebraker

立ち込める暗雲...

2015/12/12 27


厳しい現実 (’86-’87) •  Lispに手を出して大火傷– 大量のコードがゴミに

•  ADTsはまずまず成功– Ex) ウォール街では1ヶ月 = 30日間　運送業では1日 = 1営業日

•  追記型はチューニングに難あり•  Update ALWAYSは失敗– 結局従来のルールシステムに

2015/12/12 28

2015/12/12 29

•  “Large companies don’t innovate”– 技術移転にはスタートアップがベスト– Postgresの価値を市場に問う

•  Illustraを創業– 優秀なメンバーが集まる

“Mom”, “Short One”, “EMP1”, “Quiet One”, “Triple Rock”, “Tall Shark”, “Voice of Experience”, “Uptone”, “Smooth”

– 資金調達を済ませ最初の顧客を獲得

Postgresの商用化 (’91-’94)


2015/12/12 30

•  顧客とADTプロバイダの板挟み– 顧客は大企業の作ったADTを欲しがる– 大企業は多数の顧客への販売チャネルを欲しがる

•  “down round”– “a fate worse than death”

厳しい現実 (’94-’95)


2015/12/12 31

•  インターネット市場の勃興による思いがけない幸運

•  “The database for cyberspace” として売り出し注目を集める– ADTによる拡張性がWeb上の多様なデータとフィット

セレンディピティ(’95)


2015/12/12 32

厳しい現実(’95)

•  インターネット企業との契約競争– TPC-B （トランザクション処理）による競争– 得意な画像や地理データ処理で戦えない


2015/12/12 33

•  大企業によるIllustra買収– ADTを巡る板挟みの解消– トランザクション処理問題の解消

セレンディピティ(’96)


そして現在 •  Informixの一部としてIllustraの機能は現存•  ADTは数多くの関係データベース実装に波及

•  オープンソース版Postgresの派生と発展– Netezza, Greenplum, PerAccel など多くのスタートアップ企業の起点

2015/12/12 34

困難に立ち向かうアルゴリズム

2015/12/12 35 Images by courtesy of Michael Stonebraker


2015/12/12 37

キャリアを振り返って •  Make It Happen (PhD) – 5年間•  Make It Happen (tenure) – 5年間•  Make It Happen (アメリカ横断旅行) – 2ヶ月

•  “正気の人間がこんなことをやりたがるだろうか？”

2015/12/12 38

Stonebraker からのメッセージ良いアイディアを得て、困難に挑もう

•  アイディアを得るには– とにかくユーザに話を聞く– 優秀な人に囲まれた環境に身をおく

•  セレンディピティ（思いがけない幸運）– 多くの場合無視できないほど重要– 不運もまた然り

2015/12/12 40


2015/12/12 41

40周年記念パネル VLDBとデータベース業界の40年を語る

パネリスト•  Don Chamberlin, retired IBM Fellow

–  データベース業界の40年前を振り返る•  Phil Bernstein, Microsoft Research

–  VLDBの40年前を振り返る•  Michael Brodie, MIT, retired Chief Scientist Verizon IT

–  VLDBの歩み•  Alfons Kemper, Technical University Munich

–  40年間の流行り廃り•  Michael Stonebraker, MIT and serial entrepreneur

•  データベース業界のセレンディピティと苦言

2015/12/12 42

40年前 (1975) •  何もなかった–  PC, インターネット, Apple, Google, Oracle, Eコマース, ...

•  何もかも高かった– メインフレーム数千万円– メモリ 1千万円/MB, ディスク 3万円/MB

•  データベース業界– 産業的にはすでに一定の評価

Charles Bachman のチューリング賞(‘73)– 学術的には黎明期

•  (P. Bernstein) “Wasn’t totally respectable, academically”•  Edgar Codd のリレーショナルモデル(’70)•  System R, Ingres

2015/12/12 43

(D. Chamberlin)

System R •  世界初のコストベースクエリ最適化 [P.

Selinger]•  ACID特性の定義 [J. Gray]•  “Granularity of Locks” in VLDB ’75 [J.

Gray]– 後のチューリング賞受賞の礎 –  (P. Bernstein) NOT selected for journal

•  SQLの発明 [D. Chamberlin, Ray Boyce]–  ISO/ANSI標準化 (‘86)

2015/12/12 44

(D. Chamberlin)

VLDB in 1975 •  参加者 75名•  シングルトラック

2015/12/12 45

•  Data Description Models•  Physical Structures and Implementation•  Database Design Tools•  Performance and Restructuring•  Application and Management Issues•  Distributed Databases•  Security and Integrity•  System and Memory Architecture

当時のセッションタイトル

(P. Bernstein)

By courtesy of VLDB Endowment

2015/12/12 46 (M. Brodie) By courtesy of Michael Brodie

Biggest disappointments •  1980年代

–  Nested relational model (NF2)•  1990年代

–  Object-oriented model•  2000年代

–  XML as data model•  2010年代

–  NoSQL / Key Value Store?–  MapReduce?

2015/12/12 53

(A. Kemper)

“よさそうに見える”だけでなく、“実際の問題”に効く研究をしないとダメ

DB研究者にとっては(再び) 面白い時代になってきた•  Big Data による社会的な注目度•  高性能なハードウェアが非常に安価に手に入る

RDBMS市場を作ったセレンディピティ

•  VAX (ミニコンピュータ市場)の登場•  ...そして敵はIBMのアセンブラで書かれていた– VAXに移植できなかったから、IngresやOracleの市場が食われなかった

•  Project Eagleの失敗–  IMS (ナビゲーショナルDB) のフロントエンドとして関係データモデルを使う試み @ IBM

–  “Thankfully IMS screwed up logical data bases badly“

2015/12/12 54

(M. Stonebraker)

Oracleを勝たせたセレンディピティ

•  IngresはOracleよりも優れていたが...•  IBMによるDB2の発表 (1984)– 世の中の流れは一気にSQLに

•  SQLの波に乗ってトップに経ったOracle– America’s Cup strategy

2015/12/12 55

(M. Stonebraker)

Or Anti-Serendipity

80年代のOracle •  “Salesman lies regularly”•  “Ellison confused present tense and future

tense”•  “No QA”

•  Oracle(とマイクロソフト)が粗末なシステムソフトウェアの元凶 – 誰もearly releaseを使いたがらない – 客はベンダーを嫌う – 最悪なカスタマーサポート

2015/12/12 56

VLDB/DB分野研究者への苦言 •  実世界のユースケースを必須にすべき– ほどんどの論文が least publishable unit (LPU)– 興味がある人が世界に3人しかいない

•  専門に特化した小さい会議に分割すべき– 皆が12時間のフライトで集まる状況は良くない

2015/12/12 57

(M. Stonebraker)

VLDB/DB分野研究者への苦言 •  “ACM publication system is completely

broken”

•  採用時のレジュメに求める文献数が多すぎ– 准教授は3本以下、テニュアは7本以下すべき–  10年単位の仕事に集中することが大事

(Ingres は10年掛かった)

•  今の“論文の下痢”状態は止めないとダメ

2015/12/12 58

(M. Stonebraker)


2015/12/12 59

10-year Best Paper Award

2015/12/12 60

C-Store: Looking back and looking forward Mike Stonebraker, Daniel J. Abadi, Adam Batkin, Xuedong Chen, Mitch Cherniack, Miguel Ferreira, Edmond Lau, Amerson Lin, Sam Madden, Elizabeth O’Neil, Pat O’Neil, Alex Rasin, Nga Tran, and Stan Zdonik

受賞理由•  従前のカラム指向データベースが抱えていた多くの問題を解決して、高性能で実用的な設計と実装を示した

•  商業的にも成功を収めたVerticaの土台となった

D. Abadi said ...

•  カラム毎にデータを保存するというアイディア自体は70年代からあった–  SybaseIQ–  MonetDB (CWI)–  PAX (Wisconsin)–  Data morphing (Michigan)–  Clotho (CMU)

•  C-Storeの特徴–  Hybrid Storage–  圧縮–  Late Materialization

2015/12/12 61

C-Storeの最大の貢献は、システム全体としての実用的な設計を示したこと

Hybrid Storage Architecture

•  書き込みに弱いという問題を克服

2015/12/12 62

Image by courtesy of D. Abadi and M. Stonebraker

圧縮

•  行指向にはないデータの局所性を活用•  「不必要なカラムを読まない」以上のI/Oフットプリント削減

2015/12/12 63


圧縮したままクエリ処理

2015/12/12 64


Late Materialization

•  カラム指向のオーバヘッドであるタプル再構成のオーバヘッドを大幅に削減

•  I/Oフットプリント削減による主記憶DB適用領域の拡大 2015/12/12 65


M. Stonebraker said ...

2015/12/12 66

データウェアハウス市場を行指向からカラム指向に完全にひっくり返したことがこの論文の重要性


Coming World Is “Data Science”

•  Stupid Analytics (Business Intelligence) からSmart Analytics へ (Data Science)

•  技術的には配列データの線形代数演算 → SciDB

2015/12/12 67


2015/12/12 68

Keynotes

Engineering Database Hardware and Software Together

Juan Loaiza (SVP of Systems Technology at Oracle)Databases and Hardware: The Beginning and Sequel of a Beautiful Friendship

Anastasia Ailamaki (Prof. at EPFL)

Big Plateaus of Big Data on the Big IslandTodd Walter (Chief Technologist for Teradata)

Big Data Research: Will Industry Solve all the Problems?Magdalena Balazinska (Assoc. Prof. at the Univ. of Washington)

2015/12/12 69

Day 1

Day 2

共通テーマで Industry + Academic follow-up という構成

Keynotes






2015/12/12 70

Day 1

Day 2

共通テーマで Industry + Academic という構成

Keynotes






2015/12/12 71

Day 1

Day 2

テーマ：ハードウェアとソフトウェアの関係

共通テーマで Industry + Academic という構成

Databases and Hardware: The Beginning and Sequel of a Beautiful Friendship

•  Aspirin or Vitamin?– ハードウェアの進歩 = 頭痛の種

•  pipelining, ILP, SMT, multi-core, heterogeneous H/W, ...• ハードウェアの変化に振り回される

– 頭痛になってから鎮痛剤を飲むような技術を作っていてはダメ

– 今だけでなく将来より強力なシステムを作るための技術こそが重要

2015/12/12 72


Vitamins •  Non-uniform communication (NUMA)– → Adaptive Partitioning [VLDB12, ICDE14]

•  Resource underutilization (Low L1-I cache hit ratio)– → SLICC: L1に命令があるコアにトランザクションを移譲 [MICRO12, ISCA13, VLDB15]

•  one DBMS fits NONE– → Just-In-Time Databases [CIDR11, SIGMOD12,

VLDB14]

•  ハードウェアとのより密な連携が面白い時代に

2015/12/12 73


•  内容はExadataの宣伝– 話半分に聞くくらいが丁度

•  ポイント– Oracle = データベースのソフトウェアの会社

• データベースマシンを作っている – ソフトウェア（サービス）のためにハードウェアを作って売る時代に

2015/12/12 74

Juan Loaiza (SVP of Systems Technology at Oracle)

2015/12/12 75 Image by courtesy of Michael Brodie

データベースマシン

•  70年代後半～80年代初頭に盛り上がり–  “Specialized hardware supporting basic data

base management functions”– 多数の論文や Britton-Lee, CAFS(ICL) 等の商業化

2015/12/12 76

IEEE Special Issue on Database Machine [‘81]

[Hsiao, ’79]

ブームの終焉

“Database Machines, An Idea whose time has Passed?” [Boral- DeWitt, ‘83]

2015/12/12 77

All failed. Why?

•  these don't help much with sort, join, etc.

•  special-purpose hardware is a losing proposition•  prohibitively expensive (no

economy of scale)•  slow to evolve

Lecture Notes @ Berkeley graduate course [Hellerstein- Stonebraker]

We conclude that unless mechanisms for increasing the bandwidth of mass storage devices are found, highly parallel database machine architectures are doomed to extinction.

“Stonebraker’s Warning”The history of DBMS research is littered with innumerable proposals to construct hardware database machines to provide high performance operations. In general these have been proposed by hardware types with a clever solution in searchof a problem on which it might work. Readings in Database Systems (second edition), edited by Michael Stonebraker

アーキテクチャ的試行錯誤の時代

並列データベース技術の成熟とデータベースマシンの再興 (’85-) •  多くの並列データベース(マシン)の研究– GAMMA, GRACE, Bubba, ...

•  本格的な並列データベースの商業化– Teradata, Tandem, Informix, ...

2015/12/12 78

•  単なる specialized hardware からアーキテクチャの形が見え始めた時代

•  技術要素的にはコモディティの水平展開が徐々に主流に

コモディティ化の台頭 •  Googleに象徴される cheap and fast– x86 PCを並べた初期サーバ– MapReduce

2015/12/12 79

(- 2000年代初頭)

非コモディティな動き •  ActiveDisk [Acharya et.al., ‘98]– 各ディスクのプロセッサでDB演算–  I/Oトラフィックの大幅削減による高速化

•  Netezza (’99設立)– 各ディスクにFPGA–  2010にIBMが買収

•  IBM PureData System–  IBMのデータベースマシン–  Netezzaを組込み–  POWER8 CAPI

•  CPUのコヒーレンシバスにFPGAを直結

2015/12/12 80 Images by courtesy of IBM and Netezza

非コモディティな動き •  Google– POWER8採用 (‘14)

•  Amazon– プロプライエタリなソフトウェアの塊–  IntelがAWS用にカスタマイズしたCPU出荷(’14)– 独自のDBMS開発

•  DynamoDB, RedShift, Aurora

2015/12/12 81

ハードウェアを買う時代→ cheap & fast なコモディティが強い

サービスを買う(クラウド)時代→ サービスのI/FさえあればOK　内側の技術はなりふり構わず

Oracleのデータベースマシン •  In-Memory Database– Row/Columnの dual format– OLTPとOLAPを同時に扱えるアーキテクチャ

•  SQL in Silicon– カラムストアの圧縮解凍, 辞書検索, 述語評価等専用のアクセラレータを搭載 (SPARC M7)

2015/12/12 82 Images by courtesy of Oracle

ハードウェア中心からソフトウェア中心の時代へ

2015/12/12 83

Hardware

•  かつてはハードウェアが技術の進歩を牽引

•  ソフトウェアはハードを使うために付加するもの

Software Hardware

Hardware

Hardware Hardware

SW-HWの界面は“点”から”面”へ

前半終了

2015/12/12 84

会場の様子

後半：研究動向紹介 •  投稿論文の傾向•  システム系論文の動向•  論文紹介– Constructing an Interactive Natural Language

Interface for Relational Databases– Resource Bricolage for Parallel Database

Systems– Coordination Avoidance in Database Systems

2015/12/12 85

best paper

best paper 次点

注目

投稿論文の傾向

2015/12/12 86


投稿論文の傾向 (cont.)

2015/12/12 87

Day 1

Day 2 Day 2

“Graph” sessions

“作り出した問題を解いている研究がほとんど”“問題自体の面白さがない”

やや不健全さを感じる多さ

領域ごとの割合

2015/12/12 88 By courtesy of Volker Markl

Text, Semi-structured data, and Data Types

Database Engines

Applications

Novel DBArchitectures

InformationIntegration

Experimentsand Analysis

主要な領域

2015/12/12 89


主に参加していたセッション •  データベースコア、システム系セッション– Big Data Systems Analysis– Caching and Indexing–  [Industrial] Big Data Systems–  [Industrial] Real-time and Interactive Analytics– Novel Hardware Architectures –  Innovative Systems– Query Processing– Transaction Processing

2015/12/12 90

システム系論文の動向 •  Industryセッションが極めて活況– 大体が満席 or 立ち見

•  Researchはガラガラの場合もちらほら– Peter Bailis のように注目度の高い人の時だけ超満員なことも

2015/12/12 91

システム系論文の動向 •  ビッグデータ(分析系)、特にリアルタイム分析が流行

–  マーケットの過熱が牽引?–  インメモリデータベース、OLTPとOLAPの融合などをDBベンダが中心となって競い合っている印象•  JetScope: Reliable and Interactive Analytics at Cloud Scale (Microsoft)•  Towards Scalable Real-time Analytics: An Architecture for Scale-out of OLxP Workloads (SAP)•  Real-Time Analytical Processing with SQL Server (Microsoft)•  Distributed Architecture of Oracle Database In-memory (Oracle)•  In-Memory Performance for Big Data (HP Labs)

•  一時の流行感は落ち着いた Flash / NVM系–  NVRAM-aware Logging in Transaction Systems (Georgia Tech)–  REWIND: Recovery Write-Ahead System for In-Memory Non-Volatile Data-Structures

(University of Edinburgh)–  Persistent B+-Trees in Non-Volatile Main Memory (Chinese Academy of Sciences)

•  インデックスやオプティマイザのように堅実な研究も一定数–  Indexing Highly Dynamic Hierarchical Data (TU München)–  BF-Tree: Approximate Tree Indexing (EPFL)–  Resource Bricolage for Parallel Database Systems (Google)–  Multi-Objective Parametric Query Optimization (EPFL)–  Uncertainty Aware Query Execution Time Prediction (University of Wisconsin-Madison)–  Join Size Estimation Subject to Filter Conditions (Oracle Labs)

2015/12/12 92

論文紹介 •  Best paper:– Constructing an Interactive Natural Language

Interface for Relational Databases Fei Li (University of Michigan), H V Jagadish (University of Michigan)

•  Best paper 次点:– Resource Bricolage for Parallel Database Systems

Jiexing Li (Google Inc), Jeffrey Naughton (University of Wisconsin-Madison), Rimma Nehme (Microsoft Jim Gray Systems Lab)

•  注目の論文:– Coordination Avoidance in Database Systems

Peter Bailis (UC Berkeley), Alan Fekete (University of Sydney), Michael Franklin (UC Berkeley), Ali Ghodsi (UC Berkeley), Joseph Hellerstein (UC Berkeley), Ion Stoica (UC Berkeley)

2015/12/12 93







2015/12/12 94

Constructing an Interactive Natural Language Interface for Relational Databases

Fei Li (University of Michigan)H. V. Jagadish (University of Michigan)

2015/12/12 95

best paper

•  初心者でも簡単に関係データベースの複雑なクエリを構築できるよう、自然言語のインターフェースを提案

•  データベースの使い勝手を向上させ、新たな研究や製品の起点となることが期待される

推薦理由

データベースのインターフェース •  SQL

–  専門知識なしに使いこなすのは難しい

•  既存のnon-SQLなインターフェース–  キーワード：集計など複雑な問合せができない–  定型フォーム：予め想定した種類の問合せしかできない–  Visual query builder：クエリ構築にスキーマの知識が必要

•  自然言語の文章による問合せインターフェース (NLIDB: Natural Language Interfaces to Databases)–  専門知識なしに複雑な問合せができる潜在的可能性がある–  本質的に曖昧であることが実用性の大きな障壁–  問合せが正しくDBクエリに変換されているかの確認が困難

2015/12/12 96

自然言語の曖昧さ / 正しさの確認の困難さ

•  Query2の“VLDB”は conference なのか、journal なのか、その両方なのか

•  Query1が”5”という結果を返したとき、その正しさをどう確認するか

2015/12/12 97

By courtesy of F. Li et.al.

単純化したMS Academic Searchのスキーマ

既存のNLIDBとその問題 •  PRECISE [A. Popescu et.al.,COLING04]– 解釈可能な自然言語のサブセットを定義することで曖昧性を解消

– サブセットに含まれないクエリは拒否されてしまう•  ユーザとの対話による曖昧性解消– 多数の回答をユーザに提示し選択させる [I.

Androutsopoulos et.al., Nat. Lang. Eng. 95] [D. Kupper et.al.,SIGMOD93]•  答えが得られない場合どうクエリを直せばよいか分かり辛い

–  NaLIX: DB的に解釈できないクエリの修正方法をユーザに提案 [Y. Li et.al., SIGMOD05]

•  DB的に解釈できるクエリ＝正しい問いとは限らない

2015/12/12 98

提案手法: NaLIR (Natural Language Interfaces to Relational Databases)

•  ユーザとの対話による曖昧性解消と正しさの確認– 語句の意味の曖昧性 ⇨ 候補をユーザに提示、選択させる

– 問合せをDBクエリとしてどう解釈しうるかの候補をユーザに提示 ⇨ 正しい解釈のクエリを選択させる

2015/12/12 99

NaLIRの枠組み

問合せのデータ表現•  自然言語のセマンティクス：Parse Tree

–  Parse Tree の段階的な変形でクエリの曖昧性を排除–  各段階で繰り返しユーザに提示することで正しい解釈を選択

•  DBのセマンティクス：Query Tree

2015/12/12 100

自然言語のセマンティクス DBのセマンティクス

Image by courtesy of F. Li et.al.

Parse Tree

•  構文解析器から初期ツリーを生成

•  Parse Tree Node Mapper–  Candidate Mapping: 各単語を対応するSQL要素のノードとして対応付け•  SELECT•  演算子 ( = , <=, +, ...)•  関数 ( sum, count, ...)•  名前 ( リレーション, 属性 )•  値 ( 数値, 文字列, ... )•  量化子 ( ALL, ANY, ... )•  論理演算 (AND, OR, NOT)

2015/12/12 101

•  Parse Tree Structure Adjustor–  Parse Tree Reformulation: 複数の解釈の候補生成による曖昧性の解消

–  Implicit Node Insertion: 省略語を補った候補生成による曖昧性の解消

各段階の詳細は論文参照

Image by courtesy of F. Li et.al.

Parse Tree ⇨ Query Tree

基本ブロック(単一のSELECTノード)•  名前ノードから対象リレーション, 選択する属性を生成•  値ノードからWHERE句の述語を生成•  FK-PKで接続されたリレーションから結合グラフ作りFROM句を生成•  集約関数の関数ノードがあればGROUP BY句を生成

サブクエリ(ネストしたSELECTノード)•  Inner most な基本ブロックから順に変換

2015/12/12 102

論文でも大雑把な説明のみ

評価実験 •  MySQLに実装

–  構文解析器にはStanford Natural Language Parser を使用

•  MS Academic Search (MAS) のデータを利用–  実験用クエリ

•  MASの単一ページ表示で達成可能なクエリ196個–  ○ “Database領域のカンファレンス数”–  × “各領域のそれぞれのカンファレンス数” （24ページの表示が必要）

•  easy/normal/hard = (63/68/65個) の3段階の難易度に分類–  被験者 (計14名)

•  第一群：対話機能を除外したNaLIRを使用•  第二群：NaLIRを使用•  第三群：MASを使用

–  クエリを28個のタスクセットに分割してランダムに割当て•  1個のクエリの制限時間は3分•  英語のクエリ記述によるバイアスを避けるため、中国語でクエリを記述し英語で問い合わせさせる

2015/12/12 103

MS Academic Search Dataset by courtesy of F. Li et.al.

実験結果

•  いずれの難易度においても–  NaLIR > NaLIR (w/o 対話機能) > MAS

•  自然言語、及び対話機能による問合せの容易性向上を確認

2015/12/12 104

Effectiveness: 正答クエリ数 / クエリ数

by courtesy of F. Li et.al.

問合せ失敗の要因

•  対話機能により– 単語 ⇨ SQL要素へのマッピング失敗を抑制

•  曖昧性解消–  Reformulation (解釈候補の生成、省略語の挿入) における失敗の低減•  提示された Parse Tree をユーザが理解できていることの裏付け

2015/12/12 105

誤答の原因となったコンポーネント

by courtesy of F. Li et.al.

まとめ + 所感 •  語句の曖昧性解消・解釈の正しさの確認という自然言語インターフェースの抱える問題– Parse Tree をベースとした対話により解決

•  専門知識を持たないユーザが容易に複雑な問合せを行えることを被験者実験により評価

•  DBユーザの間口を広げる技術•  門外漢なので論文な面白さはいまいちピンとこない

2015/12/12 106







2015/12/12 107

Resource Bricolage for Parallel Database Systems

Jiexing Li (Google Inc)Jeffrey Naughton (University of Wisconsin-Madison)Rimma Nehme (Microsoft Jim Gray Systems Lab)

2015/12/12 108

best paper 次点

•  ヘテロなデータベースクラスタにおける資源効率の最適化という実世界の問題を解決している

•  線形計画へ帰着させることによりシンプルかつ実用的な手法を提案し、SQL Server 上の実装で有効性を示している

•  今後多くの発展的な研究が生まれることが期待される

推薦理由

並列データベースシステムの問題 •  ヘテロな環境は無視されてきたが...

–  クラウドでは同じ種類のインスタンスでも性能に大きなばらつき [INFOCOM10][VLDB10][SoCC12]

–  大規模になるほどヘテロ環境は不可避に

•  パーティショニング方法によりクエリ処理性能に大きな差

•  良いパーティショニング方法の決定は容易ではない–  マシンの“速さ” は処理特性依存–  異なるワークロードの混合

2015/12/12 109

By courtesy of J. Li et.al.

Resource Bricolage •  並列データベースにおけるワークロードの定式化

•  各ノードへ割り当てるパーティションサイズを線形計画問題へと帰着– あとはソルバに解かせればOK

2015/12/12 110

Bricolageあり合わせの道具や材料で物を作ること。転じて、持ち合わせているもので、現状を切り抜けること。

ワークロードの定式化ワークロード: 連続するステップの系列ステップの切れ目 = 同期ポイント

2015/12/12 111

定義

Query 1

Step 1

Step 2

・・・・

・・

Query N

サブクエリ1, 2, ..., n

ゴールの方向性各ステップごとに処理時間がバランスするようにパーティショニング

ワークロードの定式化 (cont.) ワークロード全体でh個のステップクラスタ全体でnノード

2015/12/12 112

定義

前提

ノード Mi 単独でステップ Sj を実行したときの実行時間

各ノード Mi に割り当てるパーティションサイズ

ノードMi が割当てられたデータ処理に要する時間は

ステップの実行時間 = 最も遅いノードの実行時間

とりあえず予測できるものとしておく


　　　　　　　　の形式的な変換

線形計画問題への帰着

2015/12/12 113

制約条件

目的関数

pi: パーティションサイズの割合→ 合計 1

各ステップの実行時間：形式上の変数

各ノードのストレージ上限

“解ける”線形計画問題にするために

•  各ステップの実行時間予測が必要– オプティマイザのコストモデルを使った実行時間予測 [ICDE12]

– プロファイリングクエリの実行によるコストモデルのキャリブレーション [ICDE13]

2015/12/12 114

複数のパーティション関数の扱い

実際の複雑なクエリでは...

2015/12/12 115

単一のパーティション関数が前提

ワークロードを通してパーティション方法が固定されている場合のみ適用可能

Step 1 Step 2

shuffle

Step 3

shuffle

途中でパーティションの分割方法(パーティション関数)が変わる


複数のパーティション関数の扱い

•  ステップの”distribution-compatible”という性質を定義– distribution-compatibleなステップ同士はパーティション関数が共通

– 詳細は論文を参照•  ワークロードをdistribution-compatibleなステップのグループに分割– 各グループに resource bricolage を適用可能

2015/12/12 116

Network 1Gbps

評価実験環境 •  9 nodes (physical)

–  2.33GHz Xeon (計16コア), 16GB memory, 8x SAS 10Krpm 147GB HDDs•  1 control node VM + 8 compute node VMs (1 VM/physical node)

–  各VMはデフォルトで半分のCPU(8コア)、メモリ(8GB)、ディスク(4 HDDs)、ネットワーク帯域(1Gbps)を使用

–  VMの資源使用量を調整することで6パターンのヘテロ環境を設定

2015/12/12 117

Physical Node

CPU

Mem

Disk

Compute Node (VM)

16GB

Heterogeneity

評価実験環境 •  9 nodes (physical)

–  2.33GHz Xeon (計16コア), 16GB memory, 8x SAS 10Krpm 147GB HDDs•  1 control node VM + 8 compute node VMs (1 VM/physical node)

–  各VMはデフォルトで半分のCPU(8コア)、メモリ(8GB)、ディスク(4 HDDs)、ネットワーク帯域(1Gbps)を使用

–  VMの資源使用量を調整することで6パターンのヘテロ環境を設定

2015/12/12 118

CPU-intensiveCPUコア数を絞る

4台: 1コア4台: 2コア

NW-intensiveNW帯域を絞る

4台: 10Mb/s4台: 20Mb/s

I/O-intensive(1)I/O帯域を絞る

4台: 1HDD4台: 2HDDs

Mix-2CPU, I/Oを絞る

Mix-3CPU, I/O, NWを

絞る

I/O-intensive(2)I/O帯域を絞る

1, 1, 2, 2, 4, 4, 8, 8HDDs respectively

評価実験の比較対象 •  Bricolage– 提案手法

•  Uniform– 均等にデータをパーティショニング

•  Delete– 均等にパーティショニングした際に最も遅いノードを

1台除去•  実行時間が改善する限り除去を繰り返す

– ヘテロ性による極めて悪い場合を避けるヒューリスティック

2015/12/12 119

SQL Server PDW 上に実装

評価実験結果 TPC-H (200GB) 全22クエリの実行時間合計

2015/12/12 120

0

2000

4000

6000

8000

10000

12000

Uniform Delete Bricolage

0

2000

4000

6000

8000

10000

12000

Uniform Delete Bricolage

秒秒実行時間予測値実行時間実測値

実行時間の予測値・実測値ともにBricolageが最速

すべての場合でDelete ≦ UniformBricolage < Delete と予測

概ね Delete ≦ UniformBricolage が常に最速

TPC-H各クエリの実行時間 •  TPC-H Q1 ~ Q10•  I/O-intensive (2) の場合

2015/12/12 121

•  各クエリでBricolageによる実行時間の削減

Graphs by courtesy of J. Li et.al.

実行時間予測の精度

•  実行時間予測の精度が Resource Bricolage の有効性の鍵

•  絶対値では予測値が実測値を1.2～1.5倍程上回る傾向–  プロファイリングクエリが単純なためCPUコストを低く見積る傾向

•  ノード間の相対的な実行時間予測は大きな誤差なし

2015/12/12 122

(正規化した) 実行時間

CPU-intensive の場合

Graphs by courtesy of J. Li et.al. オプティマイザのコストモデルに基づく比較的単純な方法で十分有効

まとめ + 所感 •  ヘテロ環境における並列データベースのパーティショニング手法–  オプティマイザのコストモデルによる実行時間予測–  実行時間を最小化する線形計画問題に帰着–  SQL Server への実装、TPC-Hを用いた実験で有効性を確認

•  見過ごされていた並列データベースの問題を指摘–  クラウドが本格普及したからこそ特に重要

•  解法の根幹は非常にシンプル–  基本ケースは単一パーティション関数に限定して単純化–  複数パーティション関数、非線形な実行時間増加 (今回は省略) などの実問題を意識した考察

2015/12/12 123







2015/12/12 124

Coordination Avoidance in Database Systems

Peter Bailis (UC Berkeley)Alan Fekete (University of Sydney)Michael Franklin (UC Berkeley)Ali Ghodsi (UC Berkeley)Joseph Hellerstein (UC Berkeley)Ion Stoica (UC Berkeley)

2015/12/12 125

注目の論文

Coordination is Expensive

•  Coordination–  ロック、ラッチ、リモートノードとのメッセージング等–  並行性制御のための同期的なコミュニケーション＝待ち時間が発生

•  性能・可用性低下の元凶–  レイテンシの増加 –  スケーラビリティの低下–  スループットの低下 –  可用性の低下

2015/12/12 126

並行性制御のために必要なコミュニケーション

安全性と性能のトレードオフ •  Strong consistency

–  Ex) Serializability–  強力なcorrectness保証–  頻繁な coordination が必要

•  Weaker consistency–  Ex) Eventual consistency–  より少ない coordination 回数 –  Correctnessが損なわれる可能性

2015/12/12 127

Performance = Coordination-free

Less-safety

Serializability

※ いい加減なイメージ

Weaker consistency

多くの提案Less coordinationLess safety guarantee

トレードオフの理論的限界を解明する試み

•  この論文の貢献– Correctnessを損なわずに

coordination を減らせる理論的限界の解明

– 実際にcoordinationを減らすための方法論の提示

– 実装による効果の確認

2015/12/12 128

Performance = Coordination-free

Less-safety

Serializability

※ いい加減なイメージ

Weaker consistency

多くの提案Less coordinationLess safety guarantee

Key questionクエリを構成する各オペレーションが

「アプリケーションのcorrectness = 不変条件」を満たすことを coordination なしで保証できるか

不変条件

2015/12/12 129

SQLにおける制約も不変条件の一種・主キー制約・外部キー制約・ユニーク制約・ユーザ定義のCHECK制約


「アプリケーションのcorrectness = 不変条件」を満たすことを coordination なしで保証できるか

Ex) 銀行口座管理・引出した分だけ残高が減る・預金残高がマイナスにならない

不変条件(Invariant)の例 Ex) Webアプリ等のユーザ管理・ユーザIDが重複しない・メールアドレスが重複しない

2015/12/12 130

Serializability … オブジェクトのread/write毎に必要　　　　　　　不変条件を満たす十分条件だが必要条件ではない　　　　　　　 → 必要以上に頻繁な coordinationWeaker consisntecy ... (場合によるが多くは) correctnessを一部犠牲に　　　　　　　　　　不変条件を満たす必要条件だが十分条件でない


アプリケーションの不変条件を満たすことを coordination なしで保証できるか

必要十分条件？ ⇨ I-confluence

I-Confluence •  オペレーションがcoordinationなしで不変条件

(Invariant)を満たせる “性質”

•  I-confluence test : I-confluence の成立条件–  Coordinationなしで不変条件を満たせる必要十分条件

•  Coordination Avoidance–  I-confluenceを利用してcoordinationを減らす方法論

•  理論的背景は省略–  興味のある人はarXivのextended versionを参照–  今回は I-confluence を使ってできることに焦点を当てて紹介

2015/12/12 131

Coordination Avoidance •  アプリケーションの不変条件を列挙

–  SQLだと主キー制約、外部キー制約等から抽出可能–  暗黙の制約はプログラマが陽に与える必要あり

•  実行されうるオペレーションの I-confluence を確認–  全て Yes : coordinationなしで実行可能–  一部 No : 何らかの coordination が必要

•  不必要な coordination を行わない並行性制御を選択–  全て I-confluent であっても coordination-free な実装を使わないと意味が無い

–  Ex) 2-phase locking (Serializability) ⇨ RAMP (Weaker MVCC)

2015/12/12 132

関係データベースオペレーションのI-confluenceの一例

By courtesy of P. Bailis et.al.

I-confluenceを用いたTPC-Cの分析

•  TPC-C : 業界標準のOLTPベンチマーク–  スキーマ、トランザクションの定義

•  この論文では更新処理のNew-Orderトランザクションのみを対象–  12個の明確なcorrectnessの定義 ⇨ 不変条件

•  12個中の10個が I-confluent–  I-confluent でない2個はIDが“連番”という強い制約–  制約を“一時的には連番でなくてもよい”まで緩めると全てI-confluent

•  重複のないlogicalなIDを割当て、後から連番のphysical IDにマッピング

2015/12/12 133

By courtesy of P. Bailis et.al.

GitHub上のプロジェクト分析結果

2015/12/12 134 ⇨ Coordination Avoidanceが適用可能なケースは多い

By courtesy of P. Bailis

実装による Coordination Avoidanceの評価

•  プロトタイプ実装(Scala)による比較–  Serializable

•  Decentralized 2-phase locking を使用–  Coordination-Avoiding

•  RAMP (スナップショットのatomicなread / write / ”merge” を保証するMVCC) を使用

•  AWS EC2 cr1.8xlarge–  32コア, 244GB memory–  TPC-Cの 1 warehouse あたり1ノード（最大200ノード使用）

•  New-Order の平均スループットを測定

2015/12/12 135

評価実験結果

•  Coordination-Avoidingのスループットはクライアント数に対しほぼ線形に増加

•  Serializableは40K txn/sで頭打ち

2015/12/12 136

8ノード利用時

負荷（クライアント数）変動リモートトランザクション率変動

•  Serializableはリモートトランザクション率に対し急激に性能低下–  最大で90%以上の性能低下

•  Coordination-Avoidingは最大で29%の性能低下

Graphs by courtesy of P. Bailis et.al.

評価実験結果

2015/12/12 137

1～200ノードのスケーラビリティ評価

全体のスループット各ノードのスループット

•  200サーバまで線形に近いスケーラビリティ–  3つのEC2 region (データセンターの別棟)に跨るためサーバ数が増えるとやや性能低下

•  200サーバで12.7M txn/s–  1ノードあたり >500K txn/s は既発表文献の25倍以上の性能

Graphs by courtesy of P. Bailis et.al.

まとめ + 所感 •  Coordination-freeかつアプリケーションの不変条件を満たす必要十分条件を解明–  I-confluence

•  I-confluenceに基づくcoordination削減の方法論 Coordination Avoidance を提案

•  TPC-Cに Coordination Avoidanceを適用して有効性を評価–  大幅なスケーラビリティ向上–  既存手法に対し25倍以上の性能向上

•  Weaker consistency で安全なアプリを書くのは極めて難しい•  Coordination Avoidance は誰もが簡単に使える段階ではないが、安全かつスケールするデータベースシステム実現に向けた大きな飛躍

2015/12/12 138

おわりに •  トップ会議に参加することの価値– 論文を読んでいるだけでは分からない技術の盛り上がり感や会場の熱気を体感できること

– 第一線の研究者と直接議論できること

•  VLDB 2015に参加する機会を頂けたことをACM SIGMOD日本支部の関係者の皆様に感謝致します

2015/12/12 139