データベース分野のトップ会議VLDB2015の参加報告 ・VLDBの会議概要 ・Michael Stonebraker教授のチューリング賞受賞記念講演等の紹介 ・論文紹介 2015/12/12に開催されたSIGMOD日本支部主催の講演会における講演資料です。

1. 国際会議参加報告
41st International Conference on Very Large Data Bases
VLDB 2015
東京大学生産技術研究所
特任研究員 早水悠登
2015/12/12 1
2015/12/12 @ 東京大学生産技術研究所
第24回先端的データベースとWeb技術動向講演会 (ACM SIGMOD 日本支部第61回支部大会) 講演資料

2. Agenda
• 講演前半：概要紹介・基調講演等
– VDLBの概要紹介・2015年度開催概要
– チューリング賞受賞記念講演
– VLDB 40周年記念パネル
– 10-year Best Paper Award
– Keynotes
• 講演後半：研究動向紹介
– 投稿論文の傾向
– システム系論文の動向
– ベストペーパー賞
– ベストペーパー次点
– 注目の論文
2015/12/12 2

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

4. 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

5. 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 ☺

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

7. ACMでも同様の動き?
2015/12/12 7
By courtesy of ACMトップ会議の論文を Proceedings of ACM という
ジャーナル論文として編纂・出版することを検討

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

9. 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
• 開催国効果で米国が倍増
• 日本は減少傾向

10. 論文採択数
2015/12/12 10
Research papers
151 accepted
21%of 710 submissions
Industrial papers
20 accepted
29%of 68 submissions
Demo papers
40 accepted
27%of 148 submissions
+ 21 rollovers from VLDB 2014

11. 年間の投稿数の推移
• やはり年度〆切直前が一番多い
2015/12/12 11
By courtesy of Volker Markl

12. 国別の投稿/採録数
2015/12/12 12
By courtesy of Volker Markl
日本からは5件が採録

13. Videos & Slides Online
• http://www.vldb.org/2015/videos.html
– Opening remark
– Keynotes
– Panels
– Award lectures
• かつての会議で見れなかった大抵の映像/スライド
が見れます
• この参加報告の意義とは...!?
– 感じ取ったメッセージや技術的背景など、自分なり
に解釈した中身を伝えられるよう努めます
2015/12/12 13

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

15. “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

16. 2015/12/12 16By courtesy of MIT
近代的なデータベースシステムの礎を築いた

17. VLDB2015 は Stonebraker三昧
• チューリング賞受賞記念講演
• VLDB 40周年記念パネル
• VLDB 10-year Best Paper Award 受賞講演
2015/12/12 17

18. チューリング賞受賞記念講演
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

19. 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

20. The Land Sharks are on the Squawk Box
(How Riding a Bicycle across America and
Building Postgres Have a Lot in Common)
• 2つの回想録
– Postgresプロジェクト(Illustra創業)
– Stonebraker夫妻のアメリカ横断自転車旅行
• Stonebrakerの 語り が面白い
– 是非YouTubeで視聴しましょう :)
2015/12/12 20

21. The Land Sharks are on the Squawk Box
(How Riding a Bicycle across America and
Building Postgres Have a Lot in Common)
• 2つの回想録
– Postgresプロジェクト(Illustra創業)
– Stonebraker夫妻のアメリカ横断自転車旅行
• Stonebrakerの 語り が面白い
– 是非YouTubeで視聴しましょう :)
2015/12/12 21

22. 山あり谷あり
2015/12/12 22
By courtesy of Michael Stonebraker

23. Postgresプロジェクト始動 (‘84-86)
• Ingresプロジェクトが一段落
– System-Rと並ぶ最初期の関係データベース実装
– Relational Technology, Inc. を起業し商用化(1980)
• 後継としてPostgresをBerkeleyで立ち上げ
• 意気揚々と新たなアイディアを温める
– Abstract Data Types
– 新たな ルールシステム
– 追記型アーキテクチャ
2015/12/12 23

24. 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)

25. 新たなルールシステム
• 整合性制約やトリガ = ルール
– 発火の契機 (挿入、更新のイベントなど)
– 発火条件
– 処理 (deleteのカスケード、挿入・更新・削除の拒否
など)
• 旧来のIF-THENルールシステム
– 結果にルール適用の順序依存性
– 順序のない relation (タプル集合) と相性が悪い
• アイディア：Update ALWAYS コマンド
2015/12/12 25
Update
ALWAYS
(set
salary
=
E.salary)
where
E.name
=
“Sam”
and
name
=
“Bill”

26. 追記型アーキテクチャ
従前のクラッシュリカバリ
• 2つのデータストア
• データ更新とログ書き込みの
慎重な同期が必要
• ログのコードが複雑化
2015/12/12 26
Postgres Approach
• データの上書きを一切しない
• “タイムトラベル”
Images by courtesy of Michael Stonebraker

27. 立ち込める暗雲...
2015/12/12 27
By courtesy of Michael Stonebraker

28. 厳しい現実 (’86-’87)
• Lispに手を出して大火傷
– 大量のコードがゴミに
• ADTsはまずまず成功
– Ex) ウォール街では1ヶ月 = 30日間
運送業では1日 = 1営業日
• 追記型はチューニングに難あり
• Update ALWAYSは失敗
– 結局従来のルールシステムに
2015/12/12 28

29. 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)
By courtesy of Michael Stonebraker

30. 2015/12/12 30
• 顧客とADTプロバイダの板挟み
– 顧客は大企業の作ったADTを欲しがる
– 大企業は多数の顧客への販売チャネルを欲し
がる
• “down round”
– “a fate worse than death”
厳しい現実 (’94-’95)
By courtesy of Michael Stonebraker

31. 2015/12/12 31
• インターネット市場の勃興による
思いがけない幸運
• “The database for cyberspace” として売
り出し注目を集める
– ADTによる拡張性がWeb上の多様なデータと
フィット
セレンディピティ(’95)
By courtesy of Michael Stonebraker

32. 2015/12/12 32
厳しい現実(’95)
• インターネット企業との契約競争
– TPC-B （トランザクション処理）による競争
– 得意な画像や地理データ処理で戦えない
By courtesy of Michael Stonebraker

33. 2015/12/12 33
• 大企業によるIllustra買収
– ADTを巡る板挟みの解消
– トランザクション処理問題の解消
セレンディピティ(’96)
By courtesy of Michael Stonebraker

34. そして現在
• Informixの一部としてIllustraの機能は現存
• ADTは数多くの関係データベース実装に
波及
• オープンソース版Postgresの派生と発展
– Netezza, Greenplum, PerAccel など多くのス
タートアップ企業の起点
2015/12/12 34

35. 困難に立ち向かうアルゴリズム
2015/12/12 35
Images by courtesy of Michael Stonebraker

36. 困難に立ち向かうアルゴリズム
2015/12/12 36
Images by courtesy of Michael Stonebraker

37. 困難に立ち向かうアルゴリズム
2015/12/12 37

38. キャリアを振り返って
• Make It Happen (PhD) – 5年間
• Make It Happen (tenure) – 5年間
• Make It Happen (アメリカ横断旅行) – 2ヶ
月
• “正気の人間がこんなことをやりたがるだ
ろうか？”
2015/12/12 38

39. 2015/12/12 39
Images by courtesy of Michael Stonebraker

40. Stonebraker からのメッセージ
良いアイディアを得て、困難に挑もう
• アイディアを得るには
– とにかくユーザに話を聞く
– 優秀な人に囲まれた環境に身をおく
• セレンディピティ（思いがけない幸運）
– 多くの場合無視できないほど重要
– 不運もまた然り
2015/12/12 40

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

42. 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

43. 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)

44. 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)

45. 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

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

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

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

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

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

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

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

53. 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 による社会的な注目度
• 高性能なハードウェアが非常に安価に手に入る

54. 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)

55. Oracleを勝たせたセレンディピティ
• IngresはOracleよりも優れていたが...
• IBMによるDB2の発表 (1984)
– 世の中の流れは一気にSQLに
• SQLの波に乗ってトップに経ったOracle
– America’s Cup strategy
2015/12/12 55
(M. Stonebraker)
Or Anti-Serendipity

56. 80年代のOracle
• Salesman lies regularly”
• “Ellison confused present tense and future
tense”
• “No QA”
• Oracle(とマイクロソフト)が粗末なシステム
ソフトウェアの元凶
– 誰もearly releaseを使いたがらない
– 客はベンダーを嫌う
– 最悪なカスタマーサポート
2015/12/12 56

57. VLDB/DB分野研究者への苦言
• 実世界のユースケースを必須にすべき
– ほどんどの論文が least publishable unit (LPU)
– 興味がある人が世界に3人しかいない
• 専門に特化した小さい会議に分割すべき
– 皆が12時間のフライトで集まる状況は良くない
2015/12/12 57
(M. Stonebraker)

58. VLDB/DB分野研究者への苦言
• “ACM publication system is completely
broken”
• 採用時のレジュメに求める文献数が多すぎ
– 准教授は3本以下、テニュアは7本以下すべき
– 10年単位の仕事に集中することが大事
(Ingres は10年掛かった)
• 今の“論文の下痢”状態は止めないとダメ
2015/12/12 58
(M. Stonebraker)

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

60. 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の土台となった

61. 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の最大の貢献は、システム全体としての
実用的な設計を示したこと

62. Hybrid Storage Architecture
• 書き込みに弱いという問題を克服
2015/12/12 62
Image by courtesy of D. Abadi and M. Stonebraker

63. 圧縮
• 行指向にはないデータの局所性を活用
• 「不必要なカラムを読まない」以上のI/Oフットプリント削減
2015/12/12 63
Image by courtesy of D. Abadi and M. Stonebraker

64. 圧縮したままクエリ処理
2015/12/12 64
Image by courtesy of D. Abadi and M. Stonebraker

65. Late Materialization
• カラム指向のオーバヘッドであるタプル再構成のオーバ
ヘッドを大幅に削減
• I/Oフットプリント削減による主記憶DB適用領域の拡大
2015/12/12 65
Image by courtesy of D. Abadi and M. Stonebraker

66. M. Stonebraker said ...
2015/12/12 66
データウェアハウス市場を行指向からカラム指向
に完全にひっくり返したことがこの論文の重要性
Image by courtesy of D. Abadi and M. Stonebraker

67. Coming World Is “Data Science”
• Stupid Analytics (Business Intelligence) か
らSmart Analytics へ (Data Science)
• 技術的には配列データの線形代数演算
→ SciDB
2015/12/12 67

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

69. 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 Island
Todd 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 という構成

70. 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 Island
Todd 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 70
Day 1
Day 2
共通テーマで Industry + Academic という構成

71. 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 Island
Todd 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 71
Day 1
Day 2
テーマ：ハードウェアとソフトウェアの関係
共通テーマで Industry + Academic という構成

72. 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
Anastasia Ailamaki (Prof. at EPFL)

73. 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

74. Engineering Database Hardware and
Software Together
• 内容はExadataの宣伝
– 話半分に聞くくらいが丁度
• ポイント
– Oracle = データベースのソフトウェアの会社
• データベースマシンを作っている
– ソフトウェア（サービス）のためにハード
ウェアを作って売る時代に
2015/12/12 74
Juan Loaiza (SVP of Systems Technology at Oracle)

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

76. データベースマシン
• 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]

77. ブームの終焉
“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
アーキテクチャ的
試行錯誤の時代

78. 並列データベース技術の成熟と
データベースマシンの再興 (’85-)
• 多くの並列データベース(マシン)の研究
– GAMMA, GRACE, Bubba, ...
• 本格的な並列データベースの商業化
– Teradata, Tandem, Informix, ...
2015/12/12 78
• 単なる specialized hardware から
アーキテクチャの形が見え始めた時代
• 技術要素的にはコモディティの水平展開が
徐々に主流に

79. コモディティ化の台頭
• Googleに象徴される cheap and fast
– x86 PCを並べた初期サーバ
– MapReduce
2015/12/12 79
(- 2000年代初頭)

80. 非コモディティな動き
• 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

81. 非コモディティな動き
• Google
– POWER8採用 (‘14)
• Amazon
– プロプライエタリなソフトウェアの塊
– IntelがAWS用にカスタマイズしたCPU出荷(’14)
– 独自のDBMS開発
• DynamoDB, RedShift, Aurora
2015/12/12 81
ハードウェアを買う時代
→ cheap & fast なコモディティが強い
サービスを買う(クラウド)時代
→ サービスのI/FさえあればOK
内側の技術はなりふり構わず

82. Oracleのデータベースマシン
• In-Memory Database
– Row/Columnの dual format
– OLTPとOLAPを同時に扱える
アーキテクチャ
• SQL in Silicon
– カラムストアの圧縮解凍, 辞書検
索, 述語評価等専用のアクセラ
レータを搭載 (SPARC M7)
2015/12/12 82
Images by courtesy of Oracle

83. ハードウェア中心から
ソフトウェア中心の時代へ
2015/12/12 83
Hardware
• かつてはハードウェアが
技術の進歩を牽引
• ソフトウェアはハードを
使うために付加するもの
Software
Hardware
Hardware
HardwaHardware
SW-HWの界面は
“点”から”面”へ

84. 前半終了
2015/12/12 84
会場の様子

85. 後半：研究動向紹介
• 投稿論文の傾向
• システム系論文の動向
• 論文紹介
– 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
次点
注目

86. 投稿論文の傾向
2015/12/12 86
By courtesy of Volker Markl

87. 投稿論文の傾向 (cont.)
2015/12/12 87
Day 1
Day 2
Day 2
“Graph” sessions
“作り出した問題を解いている
研究がほとんど”
“問題自体の面白さがない”
やや不健全さを感じる多さ

88. 領域ごとの割合
2015/12/12 88
By courtesy of Volker Markl
Text, Semi-structured data,
and Data Types
Database Engines
Applications
Novel DB
Architectures
Information
Integration
Experiments
and Analysis

89. 主要な領域
2015/12/12 89
By courtesy of Volker Markl

90. 主に参加していたセッション
• データベースコア、システム系セッション
– 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

91. システム系論文の動向
• Industryセッションが極めて活況
– 大体が満席 or 立ち見
• Researchはガラガラの場合もちらほら
– Peter Bailis のように注目度の高い人の時だけ
超満員なことも
2015/12/12 91

92. システム系論文の動向
• ビッグデータ(分析系)、特にリアルタイム分析が流行
– マーケットの過熱が牽引?
– インメモリデータベース、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

93. 論文紹介
• 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

94. 論文紹介
• 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 94

95. 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
• 初心者でも簡単に関係データベースの複雑なクエリを構築
できるよう、自然言語のインターフェースを提案
• データベースの使い勝手を向上させ、新たな研究や製品の起
点となることが期待される
推薦理由

96. データベースのインターフェース
• SQL
– 専門知識なしに使いこなすのは難しい
• 既存のnon-SQLなインターフェース
– キーワード：集計など複雑な問合せができない
– 定型フォーム：予め想定した種類の問合せしかできない
– Visual query builder：クエリ構築にスキーマの知識が必要
• 自然言語の文章による問合せインターフェース
(NLIDB: Natural Language Interfaces to Databases)
– 専門知識なしに複雑な問合せができる潜在的可能性がある
– 本質的に曖昧であることが実用性の大きな障壁
– 問合せが正しくDBクエリに変換されているかの確認が困難
2015/12/12 96

97. 自然言語の曖昧さ / 正しさの確認の困難さ
• Query2の“VLDB”は conference なのか、
journal なのか、その両方なのか
• Query1が”5”という結果を返したとき、その
正しさをどう確認するか
2015/12/12 97
By courtesy of F. Li et.al.
単純化したMS Academic Searchのスキーマ

98. 既存の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

99. 提案手法: NaLIR
(Natural Language Interfaces to Relational Databases)
• ユーザとの対話による曖昧性解消と正し
さの確認
– 語句の意味の曖昧性 ⇨ 候補をユーザに提示、
選択させる
– 問合せをDBクエリとしてどう解釈しうるかの
候補をユーザに提示 ⇨ 正しい解釈のクエリを
選択させる
2015/12/12 99

100. NaLIRの枠組み
問合せのデータ表現
• 自然言語のセマンティクス：Parse Tree
– Parse Tree の段階的な変形でクエリの曖昧性を排除
– 各段階で繰り返しユーザに提示することで正しい解釈を選択
• DBのセマンティクス：Query Tree
2015/12/12 100
自然言語のセマンティクス DBのセマンティクス
Image by courtesy of F. Li et.al.

101. 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.

102. Parse Tree ⇨ Query Tree
基本ブロック(単一のSELECTノード)
• 名前ノードから対象リレーション, 選択する属性を生成
• 値ノードからWHERE句の述語を生成
• FK-PKで接続されたリレーションから結合グラフ作りFROM句を生成
• 集約関数の関数ノードがあればGROUP BY句を生成
サブクエリ(ネストしたSELECTノード)
• Inner most な基本ブロックから順に変換
2015/12/12 102
論文でも大雑把な説明のみ

103. 評価実験
• 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.

104. 実験結果
• いずれの難易度においても
– NaLIR > NaLIR (w/o 対話機能) > MAS
• 自然言語、及び対話機能による問合せの容易性向
上を確認
2015/12/12 104
Effectiveness: 正答クエリ数 / クエリ数
by courtesy of F. Li et.al.

105. 問合せ失敗の要因
• 対話機能により
– 単語 ⇨ SQL要素へのマッピング失敗を抑制
• 曖昧性解消
– Reformulation (解釈候補の生成、省略語の挿入) におけ
る失敗の低減
• 提示された Parse Tree をユーザが理解できていることの裏付け
2015/12/12 105
誤答の原因となったコンポーネント
by courtesy of F. Li et.al.

106. まとめ + 所感
• 語句の曖昧性解消・解釈の正しさの確認とい
う自然言語インターフェースの抱える問題
– Parse Tree をベースとした対話により解決
• 専門知識を持たないユーザが容易に複雑な問
合せを行えることを被験者実験により評価
• DBユーザの間口を広げる技術
• 門外漢なので論文な面白さはいまいちピンと
こない
2015/12/12 106

107. 論文紹介
• 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 107

108. 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 上の実装で有効性を示している
• 今後多くの発展的な研究が生まれることが期待される
推薦理由

109. 並列データベースシステムの問題
• ヘテロな環境は無視されてきたが...
– クラウドでは同じ種類のインスタンスでも性能に大きなば
らつき [INFOCOM10][VLDB10][SoCC12]
– 大規模になるほどヘテロ環境は不可避に
• パーティショニング方法により
クエリ処理性能に大きな差
• 良いパーティショニング方法の
決定は容易ではない
– マシンの“速さ” は処理特性依存
– 異なるワークロードの混合
2015/12/12 109
By courtesy of J. Li et.al.

110. Resource Bricolage
• 並列データベースにおけるワークロード
の定式化
• 各ノードへ割り当てるパーティションサイ
ズを線形計画問題へと帰着
– あとはソルバに解かせればOK
2015/12/12 110
Bricolage
あり合わせの道具や材料で物を作ること。転じて、持ち合
わせているもので、現状を切り抜けること。

111. ワークロードの定式化
ワークロード: 連続するステップの系列
ステップの切れ目 = 同期ポイント
2015/12/12 111
定義
Query 1
Step 1
Step 2
・
・
・・
・
・
Query N
サブクエリ1, 2, ..., n
ゴールの方向性
各ステップごとに処理時間がバランス
するようにパーティショニング

112. ワークロードの定式化 (cont.)
ワークロード全体でh個のステップ
クラスタ全体でnノード
2015/12/12 112
定義
前提
ノード Mi 単独でステップ Sj
を実行したときの実行時間
各ノード Mi に割り当てる
パーティションサイズ
ノードMi が割当てられたデータ処理に要する時間は
ステップの実行時間 = 最も遅いノードの実行時間
とりあえず予測できるものとしておく
By courtesy of J. Li et.al.

113. の形式的な変換
線形計画問題への帰着
2015/12/12 113
制約条件
目的関数
pi: パーティションサイズの割合
→ 合計 1
各ステップの実行時間： 形式上の
変数
各ノードのストレージ上限

114. “解ける”線形計画問題にするために
• 各ステップの実行時間予測が必要
– オプティマイザのコストモデルを使った実行
時間予測 [ICDE12]
– プロファイリングクエリの実行によるコスト
モデルのキャリブレーション [ICDE13]
2015/12/12 114

115. 複数のパーティション関数の扱い
実際の複雑なクエリでは...
2015/12/12 115
単一のパーティション関数が前提
ワークロードを通してパーティション
方法が固定されている場合のみ適用可能
Step 1 Step 2
shuffle
Step 3
shuffle
途中でパーティションの分割方法(パーティション関数)が変わる
By courtesy of J. Li et.al.

116. 複数のパーティション関数の扱い
• ステップの”distribution-compatible”とい
う性質を定義
– distribution-compatibleなステップ同士はパー
ティション関数が共通
– 詳細は論文を参照
• ワークロードをdistribution-compatibleな
ステップのグループに分割
– 各グループに resource bricolage を適用可能
2015/12/12 116

117. 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

118. 評価実験環境
• 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-intensive
CPUコア数を絞る
4台: 1コア
4台: 2コア
NW-intensive
NW帯域を絞る
4台: 10Mb/s
4台: 20Mb/s
I/O-intensive(1)
I/O帯域を絞る
4台: 1HDD
4台: 2HDDs
Mix-2
CPU, I/Oを絞る
Mix-3
CPU, I/O, NWを
絞る
I/O-intensive(2)
I/O帯域を絞る
1, 1, 2, 2, 4, 4, 8, 8
HDDs respectively

119. 評価実験の比較対象
• Bricolage
– 提案手法
• Uniform
– 均等にデータをパーティショニング
• Delete
– 均等にパーティショニングした際に最も遅いノードを
1台除去
• 実行時間が改善する限り除去を繰り返す
– ヘテロ性による極めて悪い場合を避けるヒューリス
ティック
2015/12/12 119
SQL Server PDW 上に実装

120. 評価実験結果
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 ≦ Uniform
Bricolage < Delete と予測
概ね Delete ≦ Uniform
Bricolage が常に最速

121. TPC-H各クエリの実行時間
• TPC-H Q1 ~ Q10
• I/O-intensive (2) の場合
2015/12/12 121
• 各クエリでBricolageによる実行時間の削減
Graphs by courtesy of J. Li et.al.

122. 実行時間予測の精度
• 実行時間予測の精度が Resource
Bricolage の有効性の鍵
• 絶対値では予測値が実測値を
1.2∼1.5倍程上回る傾向
– プロファイリングクエリが単純
なためCPUコストを低く見積る
傾向
• ノード間の相対的な実行時間予
測は大きな誤差なし
2015/12/12 122
(正規化した) 実行時間
CPU-intensive の場合
Graphs by courtesy of J. Li et.al. オプティマイザのコストモデルに基づく
比較的単純な方法で十分有効

123. まとめ + 所感
• ヘテロ環境における並列データベースのパーティショ
ニング手法
– オプティマイザのコストモデルによる実行時間予測
– 実行時間を最小化する線形計画問題に帰着
– SQL Server への実装、TPC-Hを用いた実験で有効性を確認
• 見過ごされていた並列データベースの問題を指摘
– クラウドが本格普及したからこそ特に重要
• 解法の根幹は非常にシンプル
– 基本ケースは単一パーティション関数に限定して単純化
– 複数パーティション関数、非線形な実行時間増加 (今回は
省略) などの実問題を意識した考察
2015/12/12 123

124. 論文紹介
• 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 124

125. 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
注目の論文

126. Coordination is Expensive
• Coordination
– ロック、ラッチ、リモートノードとのメッセージング等
– 並行性制御のための同期的なコミュニケーション ＝ 待ち
時間が発生
• 性能・可用性低下の元凶
– レイテンシの増加
– スケーラビリティの低下
– スループットの低下
– 可用性の低下
2015/12/12 126
並行性制御のために必要なコミュニケーション

127. 安全性と性能のトレードオフ
• 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 coordination
Less safety guarantee

128. トレードオフの理論的限界を解明する試み
• この論文の貢献
– Correctnessを損なわずに
coordination を減らせる
理論的限界の解明
– 実際にcoordinationを減ら
すための方法論の提示
– 実装による効果の確認
2015/12/12 128
Performance
= Coordination-free
Less-safety
Serializability
※ いい加減なイメージ
Weaker consistency
多くの提案
Less coordination
Less safety guarantee
Key question
クエリを構成する各オペレーションが
「アプリケーションのcorrectness = 不変条件」
を満たすことを coordination なしで保証できるか

129. 不変条件
2015/12/12 129
SQLにおける制約も不変条件の一種
・主キー制約
・外部キー制約
・ユニーク制約
・ユーザ定義のCHECK制約
Key question
クエリを構成する各オペレーションが
「アプリケーションのcorrectness = 不変条件」
を満たすことを coordination なしで保証できるか
Ex) 銀行口座管理
・引出した分だけ残高が減る
・預金残高がマイナスにならない
不変条件(Invariant)の例
Ex) Webアプリ等のユーザ管理
・ユーザIDが重複しない
・メールアドレスが重複しない

130. 2015/12/12 130
Serializability … オブジェクトのread/write毎に必要
不変条件を満たす十分条件だが必要条件ではない
→ 必要以上に頻繁な coordination
Weaker consisntecy ... (場合によるが多くは) correctnessを一部犠牲に
不変条件を満たす必要条件だが十分条件でない
Key question
クエリを構成する各オペレーションが
アプリケーションの不変条件を満たすことを
coordination なしで保証できるか
必要十分条件？ ⇨ I-confluence

131. I-Confluence
• オペレーションがcoordinationなしで不変条件
(Invariant)を満たせる “性質”
• I-confluence test : I-confluence の成立条件
– Coordinationなしで不変条件を満たせる必要十分条件
• Coordination Avoidance
– I-confluenceを利用してcoordinationを減らす方法論
• 理論的背景は省略
– 興味のある人はarXivのextended versionを参照
– 今回は I-confluence を使ってできることに焦点を当てて紹
介
2015/12/12 131

132. 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.

133. 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.

134. GitHub上のプロジェクト分析結果
2015/12/12 134
⇨ Coordination Avoidanceが適用可能なケースは多い
By courtesy of P. Bailis

135. 実装による
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

136. 評価実験結果
• Coordination-Avoidingのスルー
プットはクライアント数に対しほ
ぼ線形に増加
• Serializableは40K txn/sで頭打ち
2015/12/12 136
8ノード利用時
負荷（クライアント数）変動 リモートトランザクション率変動
• Serializableはリモートトランザク
ション率に対し急激に性能低下
– 最大で90%以上の性能低下
• Coordination-Avoidingは最大で
29%の性能低下
Graphs by courtesy of P. Bailis et.al.

137. 評価実験結果
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.

138. まとめ + 所感
• Coordination-freeかつアプリケーションの不変条件を満たす
必要十分条件を解明
– I-confluence
• I-confluenceに基づくcoordination削減の方法論 Coordination
Avoidance を提案
• TPC-Cに Coordination Avoidanceを適用して有効性を評価
– 大幅なスケーラビリティ向上
– 既存手法に対し25倍以上の性能向上
• Weaker consistency で安全なアプリを書くのは極めて難しい
• Coordination Avoidance は誰もが簡単に使える段階ではない
が、安全かつスケールするデータベースシステム実現に向け
た大きな飛躍
2015/12/12 138

139. おわりに
• トップ会議に参加することの価値
– 論文を読んでいるだけでは分からない技術の
盛り上がり感や会場の熱気を体感できること
– 第一線の研究者と直接議論できること
• VLDB 2015に参加する機会を頂けたことを
ACM SIGMOD日本支部の関係者の皆様に
感謝致します
2015/12/12 139