Recommended
More Related Content
Similar to ICDE 2014参加報告資料
Similar to ICDE 2014参加報告資料 (20)
ICDE 2014参加報告資料
- 2. 自己紹介 白川真澄（Masumi Shirakawa） 大阪大学 大学院情報科学研究科 西尾研究室 特任助教 Webマイニング（Wikipedia, Twitter），知識ベースの自動構築 現在は知識ベースや機械学習手法を利用した応用の研究がメイン データベースコア技術とかはあんまりよく知らない（すみません） 2011年4～9月 Microsoft Research Asiaインターン 2013年3月 博士号取得 2013年4月～ 逆選挙管理委員会メンバー ねこ，温泉，ぐうたら 2
- 3. 目次 前半 • ICDE 2014を俯瞰してみる • ビッグデータ時代の新発想：もうデータは蓄えない [Keynote] Running with Scissors: Fast Queries on Just-in-Time Databases • 見えない相手と協調作業：センサネットワーク上のデータ集約 [10 Year Most Influential Paper] Approximate Aggregation Techniques for Sensor Databases 後半 • メインメモリデータベースがハードウェアトランザクショナルメモリを使ったら… [Best Paper] Exploiting Hardware Transactional Memory in Main-Memory Databases • 過去の結果を再利用：ビューを用いた大規模グラフからのパターン発見 [Best Paper Runner-up]Answering Graph Pattern Queries Using Views • アルゴリズムでゴリゴリ解決：大量のベクトルから類似ペアを厳密に見つけたい [気になる論文]L2AP: Fast Cosine Similarity Search With Prefix L-2 Norm Bounds 途中で会場の雰囲気などもお伝えします 3
- 4. 目次 前半 • ICDE 2014を俯瞰してみる • ビッグデータ時代の新発想：もうデータは蓄えない [Keynote] Running with Scissors: Fast Queries on Just-in-Time Databases • 見えない相手と協調作業：センサネットワーク上のデータ集約 [10 Year Most Influential Paper] Approximate Aggregation Techniques for Sensor Databases 後半 • メインメモリデータベースがハードウェアトランザクショナルメモリを使ったら… [Best Paper] Exploiting Hardware Transactional Memory in Main-Memory Databases • 過去の結果を再利用：ビューを用いた大規模グラフからのパターン発見 [Best Paper Runner-up]Answering Graph Pattern Queries Using Views • アルゴリズムでゴリゴリ解決：大量のベクトルから類似ペアを厳密に見つけたい [気になる論文]L2AP: Fast Cosine Similarity Search With Prefix L-2 Norm Bounds 途中で会場の雰囲気などもお伝えします 4
- 5. 30th IEEE International Conference on Data Engineering (ICDE 2014) • データベース系のトップカンファレンスの一つと言われている （データ工学なのでSIGMODやVLDBよりもちょっと幅広い？） • 本会議：4月1～3日（ワークショップは3月31日） • 開催地：イリノイ州シカゴ（アメリカのこのへん） • 会場：Holiday Inn Chicago Mart Plaza 5
- 7. ICDE 2014のスポンサー Platinum Silver Bronze Nokia発，すごい地図サービス カタールのすごい研究所 DB, NLP, IR, Web, HCIなど幅広い パデュー大学 7 ノースウェスタン大学 すごい会社 すごい会社
- 8. ICDE 2014の投稿数など 投稿数 • Research paper: 446件 • Industrial paper: 33件 • Demo paper: 65件 査読 • 16のトピック＆area chairs • 1つの論文に査読者3人 • 査読者総数 • Research paper: 158人 • Industrial paper: 20人 • Demo paper: 13人 採択数，採択率 • Research paper: 89件（20.0%） • Industrial paper: 10件（30.3%） うちショート3件 • Demo paper: 28件（43.1%） キーノート：2件 チュートリアル：6件 ワークショップ：7件 パネルディスカッション：2件 8
- 9. キーノート：2件 Running with Scissors: Fast Queries on Just-in-Time Databases Anastasia Ailamaki Ecole Polytechnique Federale de Lausanne (EPFL) Transforming Big Data into Smart Data: Deriving Value via Harnessing Volume, Variety and Velocity Using Semantics and Semantic Web Amit Sheth Kno.e.sis, Wright State University 9 こちらはあとで 詳しく紹介
- 10. チュートリアル：6件 Tutorial 1: Linked Data Query Processing Tutorial 2: Data Stream Warehousing Tutorial 3: Data Quality: The other Face of Big Data Tutorial 4: Just-in-time Compilation for SQL Query Processing Tutorial 5: Managing Uncertainty in Spatial and Spatio-temporal Data Tutorial 6: Distributed Execution of Continuous Queries 10 チュートリアルはDBコア技術に偏っている
- 11. ワークショップ：7件 • 5th International Workshop on Graph Data Management: Techniques and Applications (GDM 2014) • 10th International Workshop on Information Integration on the Web (IIWeb 2014) • BDCA 2014: Workshop on Big Data Customer Analytics • Long Term Preservation for Big Scientific Data (LOPS) • 6th International Workshop on Cloud Data Management (CloudDB 2014) • 5th International Workshop on Data Engineering meets the Semantic Web (DESWeb 2014) • 9th International Workshop on Self-Managing Database System (SMDB 2014) 11 ワークショップはDBコア技術だけでなく， Webやグラフなど，多様である
- 12. パネルディスカッション：2件 Panel 1 Main-Memory Database Systems Panel Moderators: Alfons Kemper (Technische Universität München), Thomas Neumann (Technische Universität München) Panelists: Daniel Abadi (Yale University), Anastasia Ailamaki (EPFL), Paul Larson (Microsoft Research), Guy Lohman (IBM Research Almaden), Stefan Manegold (Centrum Wiskunde & Informatica), Eric Sedlar (Oracle Labs) Panel 2: Automated Mobility: How Environment Awareness Technologies will “Drive” the Intelligent Transportation of the Future Panel Moderators: Xin Chen (HERE) Panelists: Vlad Zhukov (HERE), Ouri Wolfson (Dept. of CS, UIC), Wende Zhang (Sr. Researcher, GM), Hai Lin (Dept. of EE, Notre Dame University) 12
- 17. 17 論文マップ Hardware, Transaction, OLTP, Main-memory 論文中の全単語をTFIDFでベクトル化 類似度の高い論文ペアにエッジ追加
- 18. 18 論文マップ Query processing, Query optimization 論文中の全単語をTFIDFでベクトル化 類似度の高い論文ペアにエッジ追加
- 22. 22 論文マップ Data cleaning, Data quality 論文中の全単語をTFIDFでベクトル化 類似度の高い論文ペアにエッジ追加
- 23. 23 論文マップ Spatiotemporal, Microblog, Social media, Web 論文中の全単語をTFIDFでベクトル化 類似度の高い論文ペアにエッジ追加
- 27. ビッグデータとは？ by Prof. Dan Ariely 27at CIKM 2013
- 28. ビッグデータとは？ by Prof. Dan Ariely ビッグデータとは10代のセックスのようなものだ。 皆がそれについて話し、 誰も本当はそのやり方について知らず、 皆が他の人は全員それをやっているものだと思い、 だから皆が自分もそれをやっていると主張する。 28at CIKM 2013
- 31. 目次 前半 • ICDE 2014を俯瞰してみる • ビッグデータ時代の新発想：もうデータは蓄えない [Keynote] Running with Scissors: Fast Queries on Just-in-Time Databases • 見えない相手と協調作業：センサネットワーク上のデータ集約 [10 Year Most Influential Paper] Approximate Aggregation Techniques for Sensor Databases 後半 • メインメモリデータベースがハードウェアトランザクショナルメモリを使ったら… [Best Paper] Exploiting Hardware Transactional Memory in Main-Memory Databases • 過去の結果を再利用：ビューを用いた大規模グラフからのパターン発見 [Best Paper Runner-up]Answering Graph Pattern Queries Using Views • アルゴリズムでゴリゴリ解決：大量のベクトルから類似ペアを厳密に見つけたい [気になる論文]L2AP: Fast Cosine Similarity Search With Prefix L-2 Norm Bounds 途中で会場の雰囲気などもお伝えします 31
- 32. Running with Scissors: Fast Queries on Just-in-Time Databases Anastasia Ailamaki Ecole Polytechnique Federale de Lausanne (EPFL) ICDE 2014 Keynote I appreciate Professor Anastasia Ailamaki for giving me a deck of slides. 間に合わせの～ 32
- 34. どのデータがアクセスされる？ [VLDB12][IISWC12] アクセスされるデータは局所的 80％のCloudera customer jobsが1～8％のデータにアクセス 90％のFacebook jobsが10％未満のデータを読み込み しかも新しいデータばかり 80％のデータの再利用が3時間以内 85％のアクセスは1日以内に新しく発生したデータが対象 34 [VLDB12] Chen et al., Interactive Query Processing in Big Data Systems: A Cross-Industry Study of MapReduce Workloads, VLDB 2012. [IISWC12] Abad et al., A Storage-Centric Analysis of MapReduce Workloads: File Popularity, Temporal Locality and Arrival Patterns, IISWC 2012. やっぱ全部蓄える必要なくね？
- 37. ナウいやり方 [ICDE05] アプリケーションごとにDBMSを用意 当然汎用性は失われ，各処理もアプリごとに実装したりする必要がでてくる 37 キーノート資料より [ICDE05]Stonebraker et al., "One Size Fits All": An Idea Whose Time Has Come and Gone, ICDE 2005. ※ナウい 「新しい」を意味する死語。 転じて、古いこと。
- 38. そこでRunning with Scissorsだ！ 「走りながら（クエリ処理しながら）」不要なデータを切り落とす 1. 処理の流れを無駄なく！ → アプリの要求を理解し，それに合わせてDBを最適化 2. 処理の流れをアジャイルに！ 38 キーノート資料より
- 41. NoDB: In-situ queries on raw data [CIDR11][SIGMOD12] そう、もはやデータベースじゃない。 といっても一応はJust-in-timeな（＝間に合わせの）データベースを作ることになる クエリ処理しながらキャッシュしたりインデクシングしたりする → 徐々に高速化 41[CIDR11] Idreos et al., Here are my Data Files. Here are my Queries. Where are my Results?, CIDR 2011. [SIGMOD12] Alagiannis et al., NoDB: Efficient Query Execution on Raw Data Files, SIGMOD 2012. キーノート資料より
- 48. 行／列ハイブリッド [SIGMOD14] 行指向・列指向とかも，もはやクエリから学習させてやればよい 23クエリ目でハイブリッド発動！クエリパターンに合わせて最適化！ 48 [SIGMOD14] Alagiannis et al., H2O: A Hands-free Adaptive Store, SIGMOD 2014 (to appear). キーノート資料より 新レイアウト 構築コスト
- 50. 他のJust-in-TimeなDBたち DBToaster: custom embedded query engines [VLDB12] HyPer: efficiency through data centric code generation [VLDB11] Database cracking: data driven indexing [CIDR07] MonetDB: data vaults [SSDBM12] Hadapt: invisible loading [EDBT13] 50 [VLDB12] Ahmad et al., DBToaster: Higher-order Delta Processing for Dynamic, Frequently Fresh Views, VLDB 2012. [VLDB11] Neumann et al., Efficiently Compiling Efficient Query Plans for Modern Hardware, VLDB 2011. [CIDR07] Idreos et al., Database Cracking, CIDR 2007. [SSDBM12] Ivanova et al., Data Vaults: A Symbiosis between Database Technology and Scientific File Repositories, SSDBM 2012. [EDBT13] Abouzied et al., Invisible Loading: Access-Driven Data Transfer from Raw Files into Database Systems, EDBT 2013.
- 51. Running with Scissors 「走りながら（クエリ処理しながら）」不要なデータを切り落とす 1. 処理の流れを無駄なく！ → アプリの要求を理解し，それに合わせてDBを最適化 2. 処理の流れをアジャイルに！ → ワークをスライスしてローカリティをフォロー（！？） ※ここから先は雑になります 51 キーノート資料より
- 54. CloudSuiteベンチマーク [ASPLOS12] クラウドでのワークロードはストールに苦しんでいる 54 キーノート資料より [ASPLOS12] Ferdman et al., Clearing the Clouds: A Study of Emerging Scale-out Workloads on Modern Hardware, ASPLOS 2012.
- 55. OLTPベンチマーク [EDBT13][DaMoN13] メモリストールが依然としてドミナントである 55 キーノート資料より [EDBT13] Tözün et al., From A to E: Analyzing TPC’s OLTP Benchmarks: The obsolete, the ubiquitous, the unexplored, EDBT 2013. [DaMoN13] Tözün et al., OLTP in Wonderland: Where do cache misses come from in major OLTP components?, DaMoN 2013.
- 56. Overlap across transactions [EPFL14] インストラクション（命令）はオーバーラップ（似た順序のもの）が多い ということは，命令は複数のトランザクションで共有できそう！？ 56 キーノート資料より [EPFL14] Tözün et al., ADDICT: Advanced Instruction Chasing for Transactions, EPFL technical report, 2014.
- 57. L1キャッシュの自己組織化 [MICRO12] 似たような命令がきたらトランザクションの命令を別のコアにコピー 命令のキャッシュミスをできる限り防ぐ！すなわちメモリストールをできる限り減らす！ 57 キーノート資料より [MICRO12] Atta et al., SLICC: Self-Assembly of Instruction Cache Collectives for OLTP Workloads, MICRO 2012.
- 58. Fine-grain instruction overlap [VLDB15] L1キャッシュ間で命令を使いまわすことでスループットが劇的に改善 58 キーノート資料より [VLDB15] 情報がまだ出ていない！
- 60. まとめ：今後研究が必要な技術 （キーノート資料そのままです） Declarative tools (e.g., list comprehensions) Dynamic code generation Stream processing Synopses 60
- 61. Transforming Big Data into Smart Data: Deriving Value via Harnessing Volume, Variety and Velocity Using Semantics and Semantic Web Amit Sheth Kno.e.sis, Wright State University ICDE 2014 Keynote 今回の報告では紹介しません 61
- 63. 目次 前半 • ICDE 2014を俯瞰してみる • ビッグデータ時代の新発想：もうデータは蓄えない [Keynote] Running with Scissors: Fast Queries on Just-in-Time Databases • 見えない相手と協調作業：センサネットワーク上のデータ集約 [10 Year Most Influential Paper] Approximate Aggregation Techniques for Sensor Databases 後半 • メインメモリデータベースがハードウェアトランザクショナルメモリを使ったら… [Best Paper] Exploiting Hardware Transactional Memory in Main-Memory Databases • 過去の結果を再利用：ビューを用いた大規模グラフからのパターン発見 [Best Paper Runner-up]Answering Graph Pattern Queries Using Views • アルゴリズムでゴリゴリ解決：大量のベクトルから類似ペアを厳密に見つけたい [気になる論文]L2AP: Fast Cosine Similarity Search With Prefix L-2 Norm Bounds 途中で会場の雰囲気などもお伝えします 63
- 64. Approximate Aggregation Techniques for Sensor Databases Jeffrey Considine, Feifei Li, George Kollios, John W. Byers Computer Science Dept., Boston University ICDE 2014 10 Year Most Influential Paper (Originally presented at ICDE 2004) 64
- 65. 10 Year Most Influential Paper Awardsとは？ ICDEで10年以上前に発表された論文の中から，その後にデータ 工学の分野でものすごい影響を与えた論文に授与される賞である ICDE 2005から始まった ICDE Influential Paper Awardsのページ http://tab.computer.org/tcde/icde_inf_paper.html 65
- 66. この論文が10 Year Most Influential Paper Awardsに選ばれた理由 The paper describes novel methods to handle duplicate-sensitive aggregates over distributed datasets. It carefully extends the duplicate-insensitive Flajolet-Martin method, adapting it to require little computation and communication efforts, and make it robust to link losses. This work has been highly impactful in the area of sensor networks, and has been shown to be applicable to any setting with multiple data sources that may suffer network failures, such as distributed data centers of today. つまり… センサネットワークだけでなく，複数データソースがあって互いのコミュニケーション が難しいようなあらゆるケース（昨今の分散データセンタとか）に適用できるから 66
- 67. センサネットワーク 無線小型端末（センサ）のみで構成されるネットワーク 各センサは自分の担当区域をセンシング シンクは各センサがセンシングしたデータを収集 通信範囲内のセンサとのみ通信可能（＝センサ間にリンクあり） センサやリンクは壊れやすい センサはリソースが少ない（メモリ，バッテリー，通信コスト） 67 シンク センサ 分散環境の中でもかなり制約がシビア
- 68. センサデータベース センサネットワーク全体を「分散データベース」とみなす ただしデータはシンクに集められる 各センサはデータを一時的に持つのみ シンクがクエリを投げてデータを収集する COUNT/SUM/AVG, MIN/MAX システムにて有効性は実証済み TAG (Berkeley/MIT), Cougar (Cornell) 68
- 69. センサデータベースの例 各センサは1つの値を持っている シンクはある時点において ワンショットクエリを投げる （MAX, AVGなど） 定期的にクエリを投げるよう 拡張可能 （e.g. 最高気温の監視とか） 69 A E B D C K F G H J I 6 3 2 7 6 9 4 1 10 12 シンク
- 71. MAXの例（ロスあり） パスを冗長化（＝データを複製）するとロバストになる Jが死んだりJK間が途切れても，別経路でシンクに12が届く MAX（とかMIN）は簡単 シンクまでのパスが1つでも通ればよい 複製したデータが悪さすることはない 71 A E B D C K F G H J I 6 3 2 7 6 9 4 1 10 12 6 2 6 7 6 12 9 9 12 MAX=12 12 12
- 74. AVGの例（ロスあり，TAG++[OSDI02] ) パスを冗長化し，そのときにデータは値と重みを分ける 和とデータ数を集めて，最後にデータ数で割れば…大丈夫？ ロスしたら6にならなくなるっぽい でもナイーブ手法よりちょっとはマシか？ 74 A E B D C K F G H J I 6 3 2 7 6 9 4 1 10 12 6,1 2,1 6,1 15,3 9,2 16,1.5 9,1 6,0.5 10,2 20,3.5 AVG=60/10=6 6,0.5 [OSDI02] Madden et al., TAG: A Tiny AGgregation Service for Ad- Hoc Sensor Networks, OSDI 2002.
- 75. AVGの例（ロスあり，LIST） 全データをリスト化して送る これなら多少ロスしてもAVGの厳密解が分かる というかもはや全データが分かる 通信量とか大きくなるし， 各センサのスペースも圧迫される 厳密解が欲しければ妥協しろ！ しかしこれでも厳密解が得られないケースが… 75 A E B D C K F G H J I 6 3 2 7 6 9 4 1 10 12 B,6 A,2 H,6 A,2 G,7 H,6 B,6 D,3 F,12 I,10 C,9 F,12 C,9 E,1 C,9 E,1 F,12 J,4 AVG=60/10=6 F,12
- 76. 本研究の目的とアプローチ センサネットワークの環境ではAVGなどの厳密解を求めるのは 難しすぎるので，近似解でいい感じの方法を模索する 主にCOUNT/SUM/AVG（複製が悪さする系の集約）を対象とする 通信エラー（リンクロス）に強いアルゴリズムを！ スケッチと呼ばれる確率的な手法を取り入れる Sketch [Flajolet85] : 記憶スペースがO(log N), 処理時間がO(1) ちなみにカウントで厳密解欲しければ記憶スペースO(N)は必要 76[Flajolet85] Flajolet et al., Probabilistic Counting Algorithms for Data Base Applications, Journal of Computer and System Sciences, 1985.
- 77. COUNT Sketch (1/3) ① N個のボールがそれぞれ一段 ずつ階段を下っていく ② ボールは各段で「はじける」または 「次の段に進む」，その確率ともに50％ ③ ボールがはじけたら，その段に色がつく 77
- 78. COUNT Sketch (2/3) ① N個のボールがそれぞれ一段 ずつ階段を下っていく ② ボールは各段で「はじける」または 「次の段に進む」，その確率ともに50％ ③ ボールがはじけたら，その段に色がつく 78 さて今、階段はこんな感じに色が付いている。 ボールはいくつあったのでしょうか？ 例えば，あるボールがここで はじける確率は32分の1
- 79. COUNT Sketch (3/3) 集約後のビットの立ち方からもとのボールの数Nを推定できる さらに1ゾーン，0/1混合ゾーン，0ゾーンに分ける ことで効率よくNを推定できる！なぜなら… （証明は前述の[Flajolet85]参照） 必要なのは「初めて0がでてきた場所」で， これをRとするとNは以下の式で近似できる m回試行すればさらに推定値が安定する！ （ただしφ ≒0.775351） 79 0 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 1 1 0 1 0 0 0 ・ ・ ・ ボール1 ボール2 集約後 1ゾーン 混合 ゾーン 0ゾーン 1 0 0 0 0 0 0 0ボール3 この場合R=3なので Nの推定値は10.3ぐらい
- 80. SUM Sketch 1つのボールにつき，値の回数分ビットを立てる 数が大きいときは回数分ビットを立てる処理が面倒くさい でもどうせ大半のボールは1ゾーンではじける 安全にとれる1ゾーンの分だけ値（推定値）を減らし，無条件で1ゾーンのビットを立てる そうするとどんな値でも定数時間で処理できるようになる！ 80 1 1 0 1 0 0 0 0ボール 1つのボールで複数のビットが立つ 1 1 1 0 1 0 0 0 1ゾーン 混合 ゾーン 0ゾーン 1 1 ・・・・・・ボール このへんは何回やっても 全部1になる 𝑆 = log2 𝑣 − 2 log2 log 𝑒 𝑣 値vに対し，安全ビット数Sは （詳細は本論文参照）
- 82. Sketchのセンサデータベースへの適用 シンクからクエリを（フラッディングなどにより）投げる このとき各センサはシンクからのホップ数や親ノードを覚えておく 各センサがSketchでビット列生成 末端ノードから順にビット列を送る 自分のと子ノードからのビット列をORで集約 子からデータを受け取る or タイマなどで データ送信のタイミングを制御 最後にシンクで集約したビット列から 値を推定 82 A E B D C K F G H J I 6 3 2 7 6 9 4 1 10 12 1 1 1 1 1 0 1 0
- 87. 「複製データが悪さしない」とは？ 同じデータからSketchされたビット列はどれだけ集約しても 同じビット列にしかならない！ 87 1 1 0 1 0 0 0 0 1 1 0 1 0 0 0 0 1 1 1 1 0 0 0 0 1 1 0 0 0 0 0 0 1 0 1 0 0 0 0 0 1 1 1 1 0 0 0 0 A B C シンク
- 88. 「複製データが悪さしない」とは？ 同じデータからSketchされたビット列はどれだけ集約しても 同じビット列にしかならない！ 88 1 1 0 1 0 0 0 0 1 1 0 1 0 0 0 0 1 1 0 0 0 0 0 0 1 0 1 0 0 0 0 0 1 1 1 1 0 0 0 0 A B C シンク 右のリンクが切れたら
- 89. 「複製データが悪さしない」とは？ 同じデータからSketchされたビット列はどれだけ集約しても 同じビット列にしかならない！ 89 1 1 0 1 0 0 0 0 1 1 1 1 0 0 0 0 1 1 0 0 0 0 0 0 1 0 1 0 0 0 0 0 1 1 1 1 0 0 0 0 A B C シンク 左のリンクが 切れたら
- 90. 「複製データが悪さしない」とは？ 同じデータからSketchされたビット列はどれだけ集約しても 同じビット列にしかならない！ 90 1 1 0 1 0 0 0 0 1 1 0 1 0 0 0 0 1 1 1 1 0 0 0 0 1 1 0 0 0 0 0 0 1 0 1 0 0 0 0 0 1 1 1 1 0 0 0 0 A B C シンク 両方のリンクが使えたら シンクで集約される ビット列に影響なし！
- 91. この研究を引用している論文の例 センサネットワーク上でのデータ集約に関する論文 “Considine et al. [6] independently proposed using duplicate-insensitive sketches for robust aggregation in sensor networks and demonstrated the advantages of a broadcast-based multi- path routing topology over previous tree-based approaches. However, they primarily focused on energy-efficient computation of the Sum aggregate, and did not address the other contributions listed above.” (Nath et al., Synopsis Diffusion for Robust Aggregation in Sensor Networks, SenSys 2004.) → 電力消費以外の問題（コネクティビティの変化への迅速な対応とか）を解決していない Distributedな集約プロトコルに関する論文（こちらはセンサネットワークだけではない） “(probabilistic counting) This protocol is based on ideas from [11] for counting distinct elements of a database and in [12] was adapted to produce a protocol for averaging. The outcome is random, with variance that becomes arbitrarily small as the number of nodes grows. However, for moderate numbers of nodes, say tens of thousands, high variance makes the protocol impractical.” (Moallemi et al., Consensus Propagation, IEEE TOIT, 2006.) → 確率的な手法として紹介，ノード数が少ないと誤差が大きくなり実用的でない 91 他の論文ではこき下ろされているようである
- 95. 目次 前半 • ICDE 2014を俯瞰してみる • ビッグデータ時代の新発想：もうデータは蓄えない [Keynote] Running with Scissors: Fast Queries on Just-in-Time Databases • 見えない相手と協調作業：センサネットワーク上のデータ集約 [10 Year Most Influential Paper] Approximate Aggregation Techniques for Sensor Databases 後半 • メインメモリデータベースがハードウェアトランザクショナルメモリを使ったら… [Best Paper] Exploiting Hardware Transactional Memory in Main-Memory Databases • 過去の結果を再利用：ビューを用いた大規模グラフからのパターン発見 [Best Paper Runner-up]Answering Graph Pattern Queries Using Views • アルゴリズムでゴリゴリ解決：大量のベクトルから類似ペアを厳密に見つけたい [気になる論文]L2AP: Fast Cosine Similarity Search With Prefix L-2 Norm Bounds 途中で会場の雰囲気などもお伝えします 95
- 96. Exploiting Hardware Transactional Memory in Main-Memory Databases Viktor Leis, Alfons Kemper, Thomas Neumann Technische Universität München ICDE 2014 Best Paper 96 ※ここから先の引用文献は 論文を参照してください
- 97. Main-memory Database (MMDB) インメモリデータベースともいう メモリ上で動くデータベース HDDとかSSDとかと比べると爆速 だってメモリだもの 主なメインメモリデータベースシステム H-Store/VoltDB [Stonebraker, IEEE Data Eng. Bull., 2013] HyPer [Kemper, ICDE11] SAP HANA [Färber, SIGMOD Record, 2011] IBM solidDB [Lindström, IEEE Data Eng. Bull. 2013] Microsoft Hekaton [Larson, IEEE Data Eng. Bull. 2013] 他にもたくさんある 97Wikipediaより
- 101. ロックはMMDBには不向き ▶ Fine-grained locking （小さい領域を細かくロック） 正しく制御するのが難しい 制御をミスるとデッドロックが発生する ▶ Coarse-grained locking （広い領域を大ざっぱにロック） 制御は簡単 だけど並列性がかなり失われる どっちにしてもメモリ中心の処理ではロックのオーバヘッドが大きい 場合によってはボトルネックになる[Harizopoulos, SIGMOD08][Muhe, CIDR13] 101
- 104. HTMをMMDBに使うときの問題点 (1/2) ただHTMを使えばオッケーというわけではない 1. データベースのトランザクションはdurabilityとか気にしないと いけなくて，TMはそういうの対象にしていない データベースなので，メモリにデータを保持し続ける必要がある 2. 現時点のHTM（Haswell）ではL1キャッシュの32KB内に トランザクションがアクセスするデータを収めないといけない 104 HTM使えるのはここだけ
- 105. HTMをMMDBに使うときの問題点 (2/2) ただHTMを使えばオッケーというわけではない 3. ハードウェア的事情による予期せぬ事態に備えないといけない キャッシュのデータ格納構造やハードウェア割り込みなどによって衝突が発生 4. 何度やってもおなじ衝突が発生するような「病的」なケースに 対して，処理を前に進める対策が必要 Associativity collisionは一度起こったらそのままだと抜け出せない 105
- 106. 本研究の概要 （実はあんまり自分ではよく分かってないのですが…） メインメモリデータベースシステムでHTMを有効に利用するための 諸々を工夫した，というのがこの研究の中身らしい あんまりアカデミックな感じがしない…DBコア技術の研究ってこんなもんなのでしょうか 工夫した諸々 • TMをbuilding blockとして使い，データベーストランザクションを細かく分ける • まずはトランザクショナルメモリを使ってロックなしで処理させる • コンフリクトしたらもうちょっと慎重な方法でやり直す • タイムスタンプ使ってコンフリクトを賢く検知する • データレイアウトやアクセスパターンをいろいろ工夫する 106
- 107. 本研究の概要 （実はあんまり自分ではよく分かってないのですが…） メインメモリデータベースシステムでHTMを有効に利用するための 諸々を工夫した，というのがこの研究の中身らしい あんまりアカデミックな感じがしない…DBコア技術の研究ってこんなもんなのでしょうか 工夫した諸々 • TMをbuilding blockとして使い，データベーストランザクションを細かく分ける • まずはトランザクショナルメモリを使ってロックなしで処理させる • コンフリクトしたらもうちょっと慎重な方法でやり直す • タイムスタンプ使ってコンフリクトを賢く検知する • データレイアウトやアクセスパターンをいろいろ工夫する 107 コンフリクトしにくい工夫 病的なケースからの脱出とか コンフリクトしにくい工夫
- 108. 本研究のコントリビューション 明示的にユーザが何かをしなくても，メインメモリデータベースを マルチコア環境で効率的に使えるようにした HyPer [Kemper, ICDE11]は，データベースをどのように分割（partitioning）するかを ユーザが手動でいい感じに決めないとうまく並列処理できない H-Store [Stonebraker, IEEE Data Eng. Bull., 2013]は自動的に分割する仕組みとして Schism [Curino, VLDB10]を備えているが，ワークロードが時間的に均質でない場合に 良い分割がうまく得られないと報告されている[Larson, VLDB11] 108
- 109. 本研究のコントリビューション 明示的にユーザが何かをしなくても，メインメモリデータベースを マルチコア環境で効率的に使えるようにした HyPer [Kemper, ICDE11]は，データベースをどのように分割（partitioning）するかを ユーザが手動でいい感じに決めないとうまく並列処理できない H-Store [Stonebraker, IEEE Data Eng. Bull., 2013]は自動的に分割する仕組みとして Schism [Curino, VLDB10]を備えているが，ワークロードが時間的に均質でない場合に 良い分割がうまく得られないと報告されている[Larson, VLDB11] さらに… そもそも複数の分割されたデータベースにアクセスするようなトランザクションでは， データベースを分割するアプローチは効果が減少する なぜなら，複数のデータベースにアクセスするからといってコンフリクトが絶対に起こる わけではなく，これが並列処理の性能を貶めているからだ だから理想的な分割をしたときよりも提案手法のほうが速くなることもある 109
- 116. 提案手法 データベーストランザクションを細かいHTMトランザクションに分ける 32KBより十分に小さくする 1タプルへのアクセス→1HTMトランザクション Timestamp Ordering (TSO)で コンフリクトを検知 レガシーなやり方[Carey, PhD thesis, 1983] だがMMDBでは有効 Safe Timestampの導入 これ以前のトランザクションは全部コミット or アボートしたことを表すタイムスタンプ 雑なやり方だが，これ一つで安全を保証できる 116
- 117. コンフリクト検知 からの 処理やり直し コンフリクトしたら処理を戻さないといけないのは世間では常識 1. HTM conflict （青矢印） L2 or L3キャッシュにコピーしておいた元の 内容をまたL１キャッシュにもってくるだけ やり直しのときはラッチ（大事な処理のとこを 一瞬だけロックするやつ）を使う 2. Timestamp conflict （赤矢印） いつものログ使うロールバック＆ロック獲得＆ 直列処理で確実に処理を終わらせる 117
- 118. 実装の例 1タプルへのアクセス→1HTMトランザクションに “Larger statements like non-unique index lookups should be split into multiple HTM transactions, e.g., one for each accessed tuple” (p7より) 118
- 120. 評価（TPC-Cベンチマーク） partitioned…手動でデータベースの分割を行う 一番速い！けどなんかズルい！ HTM…提案手法 速い！ optimistic…Timestamp Orderingのみ（HTMではなくラッチを使う） 遅い！ serial…並列化せず まあ、うん。 2PL…2相ロック 超遅ぇ！だせぇ！ 120
- 122. 評価（TCP-C, 32コアでのシミュレーション） コア数増えれば増えるほどHTM最強説が濃厚に partitionedは複数パーティションにアクセスするトランザクションがボトルネックに 122
- 125. 目次 前半 • ICDE 2014を俯瞰してみる • ビッグデータ時代の新発想：もうデータは蓄えない [Keynote] Running with Scissors: Fast Queries on Just-in-Time Databases • 見えない相手と協調作業：センサネットワーク上のデータ集約 [10 Year Most Influential Paper] Approximate Aggregation Techniques for Sensor Databases 後半 • メインメモリデータベースがハードウェアトランザクショナルメモリを使ったら… [Best Paper] Exploiting Hardware Transactional Memory in Main-Memory Databases • 過去の結果を再利用：ビューを用いた大規模グラフからのパターン発見 [Best Paper Runner-up]Answering Graph Pattern Queries Using Views • アルゴリズムでゴリゴリ解決：大量のベクトルから類似ペアを厳密に見つけたい [気になる論文]L2AP: Fast Cosine Similarity Search With Prefix L-2 Norm Bounds 途中で会場の雰囲気などもお伝えします 125
- 126. Answering Graph Pattern Queries Using Views Wenfei Fan1,2, Xin Wang3, Yinghui Wu4 1 University of Edinburgh 2 RCBD and SKLSDE Lab, Beihang University 3 Southwest Jiaotong University 4 UC Santa Barbara ICDE 2014 Best Paper Runner-up 126
- 127. Answering Queries Using Views 「元のデータに対するクエリ」と同じ結果が得られる 「ビューに対するクエリ」を探す問題 127 元のデータ （リレーショナルデータ, XML, グラフなど） ビュー ここから探すのは大変だけど こっちから同じ結果を取得 できればそれでいいよね
- 128. Answering Queries Using Viewsな研究 Relational Data [Halevy, VLDBJ01][Lenzerini, PODS02] XML Queries [Miklau, PODS02][Neven, ICDT03][Park, ICDE Workshop, 2005] Semistructured data and RDF [Zhuge, ICDE98][Le, WWW11] この研究はグラフパターンマッチング問題にViewを使った 最初の研究である “This work is a first step toward understanding graph pattern matching using views, from theory to practical methods.” （論文より） 128
- 129. グラフパターンマッチング 例：パターンQsにマッチするプロジェクトチームを作りたい Gから探すのは大変そう，計算量はO(|Qs|2 + |Qs||G| + |G|2)[Fan, VLDB10][Henzinger, FOCS95] ビューV1, V2をマージしたらなんか答えがでてきそう！Gにアクセスしなくてよさそう！ 129
- 130. 研究課題 ビューだけでクエリに答えるためには，以下の問題を解決する 必要がある ① ビューだけでちゃんと答えを出せるか否かが分かるか？ ② 答えがでるとして，どうやって効率的に解を探すか？ ③ どのビューを使うべきか？ 本研究ではこれらの問題を解決する！ 130
- 131. グラフ G=(V, E, L) V: ノード v1=“Bob”, v2=“Dan”, v3=“Jean”, ... E: エッジ（有向） (v1, v2), (v1, v3), ... L: ラベル関数 L(v1)={“PM”}, L(v2)={“PRG”}, ... 131
- 132. パターンクエリ Qs=(Vp, Ep, fv) Vp: ノード u1, u2, u3, ... Ep: エッジ（有向） (u1, u2), (u1, u3), ... fv: ラベル関数（複数指定不可） fv(u1)=“PM”, fv(u2)=“DBA”, ... 132
- 133. ついでに…Boundedパターンクエリ Qb=(Vp, Ep, fv, fe) Vp: ノード Ep: エッジ（有向） fv: ラベル関数（複数指定不可） fv(u1)=“PM”, fv(u2)=“DBA”, ... fe: ホップ数関数 fe(u1, u2)=2, ... 間接的に繋がっていてもよい 133 2 1 1 2 * * QsじゃなくてQb feが増えた
- 135. グラフパターンマッチング via シミュレーション 𝑄𝑠 ⊴ 𝑠𝑖𝑚 𝐺: グラフGがパターンクエリQsにシミュレーションでマッチ 以下のようなSが存在するときシミュレーションでマッチする ノードマッチ： Qsの各ノードu∈Vpについて，(u, v)∈Sを満たすGのノードv∈Vが存在 エッジマッチ： 各ノードマッチペア(u, v)∈Sについて，fv(u)∈L(v)であり，さらに各パターンクエリの エッジ(u, u’)∈Epについて，グラフのエッジ(v, v’)∈Eが存在（もちろん(u’, v’)∈S） S0をユニークな最大のSとする（𝑄𝑠 ⊴ 𝑠𝑖𝑚 𝐺ならS0は必ず1つだけ存在 [Henzinger, FOCS95]） SeをS0のeに対するエッジマッチの集合とする クエリQsへのシミュレーション結果をQs(G)={(e, Se)| e∈Ep}とする 135 ちょっと何言ってるか分からない
- 145. ③ どのビューを使うべきか？ こちらもインクリメンタルなやり方で簡単にできる Minimal法 [ビュー追加フェーズ] ビューを順に走査し，Qsに必要なエッジの情報を持っていたらそのビューを追加 ビューが追加されるごとにQsに必要なエッジが少なくなっていき， すべてのエッジの情報がビューでまかなえるようになったらストップ ビューを全部チェックしてQsに必要なエッジが全部そろわなかったら失敗 （グラフから直接探さないといけない） [ビュー削除フェーズ] 追加したビューを順に走査し，そのビューを抜いてもQsに必要なエッジが まだそろっていたら，そのビューはなくてもいいということなので削除 より効率的にエッジを被覆するビューを選択していくMinimum法もある 145
- 149. 評価用データ Amazon*1 同時購入グラフ，548Kノード，1.78Mエッジ，属性：タイトル，グループ，ランクなど ビュー：12頻出パターン生成[Leskovec, PAKDD06]，1パターンで5Kのノードとエッジをカバー Citation*2 論文引用グラフ，1.4Mノード，3Mエッジ，属性：タイトル，著者，年，開催地など ビュー：独自に12のビューを作成，全体の12％をカバー YouTube*3 推薦グラフ，1.6Mノード，4.5エッジ，属性：カテゴリ，年齢，レートなど ビュー：独自に12ビューを生成，1ビューで700ノードとエッジをカバー 149 *1 Amazon dataset. http://snap.stanford.edu/data/index.html. *2 Citation. http://www.arnetminer.org/citation/. *3 Youtube dataset. http://netsg.cs.sfu.ca/youtubedata/.
- 150. 評価結果 クエリの (ノード数, エッジ数) を変えて評価 Match: ビューを使わない手法[Fan, VLDB10][Henzinger, FOCS95] どのデータでも処理時間を半分以下に抑えられている Minimal法よりMinimum法のほうがちょっと速い 150
- 154. 目次 前半 • ICDE 2014を俯瞰してみる • ビッグデータ時代の新発想：もうデータは蓄えない [Keynote] Running with Scissors: Fast Queries on Just-in-Time Databases • 見えない相手と協調作業：センサネットワーク上のデータ集約 [10 Year Most Influential Paper] Approximate Aggregation Techniques for Sensor Databases 後半 • メインメモリデータベースがハードウェアトランザクショナルメモリを使ったら… [Best Paper] Exploiting Hardware Transactional Memory in Main-Memory Databases • 過去の結果を再利用：ビューを用いた大規模グラフからのパターン発見 [Best Paper Runner-up]Answering Graph Pattern Queries Using Views • アルゴリズムでゴリゴリ解決：大量のベクトルから類似ペアを厳密に見つけたい [気になる論文]L2AP: Fast Cosine Similarity Search With Prefix L-2 Norm Bounds 途中で会場の雰囲気などもお伝えします 154
- 155. L2AP: Fast Cosine Similarity Search With Prefix L-2 Norm Bounds David C. Anastasiu, George Karypis University of Minnesota ICDE 2014 155
- 156. All-Pairs Similarity Search 閾値θ 以上のベクトルの組をすべて見つける問題 Self-Similarity Joinともいう おもに高次元でスパースなベクトルを対象とする 156 c1 c2 c3 ck v1 0.1 0 0.2 … 0 v2 0.2 0 0.1 … 0 v3 0 0.1 0 … 0.3 … vn 0.3 0.1 0 … 0 {v1 , v2 }, {v2 , vn }, … ＞θ
- 157. よくあるアプローチ 転置インデックスを使うことで非零成分に高速にアクセス ベクトルが正規化されていれば，コサイン類似度は非零成分同士の積で表される 157 c1 c2 c3 ck v1 0.1 0 0.2 … 0 v2 0.2 0 0.1 … 0 v3 0 0.1 0 … 0.3 … vn 0.3 0.1 0 … 0 c1 → {v1 , 0.1},{v2 , 0.2},…,{vn , 0.3} c2 → {v3 , 0.1},…,{vn , 0.1} c3 → {v1 , 0.2},{v2 , 0.1},… … 転置インデックス というかそれ以外にやり方あんの？
- 158. もっと賢いアプローチ 明らかに閾値を越えなさそうな組は全部計算する前に捨てる Prefix filtering [Chaudhuri, ICDE06] ベクトルの前半部分（prefix）のみの情報を利用，Intersectionの有無で判断 AllPairs [Bayardo, WWW07] （詳細は後述） Prefix, suffix, 非零成分の数（size）を利用 動的に転置インデックスを作成 上記のような厳密手法だけでなく，近似手法もある Locality Sensitive Hashing (LSH) [Gionis, VLDB99], BayesLSH [Satuluri, VLDB12] 他にもたくさんあるが詳しくは論文のRelated Work参照 158
- 159. AllPairsの概要 [Bayardo, WWW07] 1行（ベクトル）ずつ，以下の処理を行う（実際は2, 3, 1の順） 1. 動的インデックス作成 1列ずつ処理し，「この列で初めてヒットしたら最大でこの類似度まで到達できる」 という最大類似度が閾値を上回る列以降のみ，インデックスを作る 2. 候補選択 1列ずつ逆から処理し，すでに作成したインデックスを用いて類似度を推定する ベクトルのサイズや推定した類似度が閾値未満なら候補から外す 3. 候補厳選 候補に残ったベクトルの組について，正確な類似度を算出する 159
- 160. AllPairsの動作の雰囲気 160 c1 c2 c3 ck v1 0.1 0 0.2 … 0 v2 0.2 0 0.1 … 0 v3 0 0.1 0 … 0.3 … vn 0.3 0.1 0 … 0
- 161. AllPairsの動作の雰囲気 161 c1 c2 c3 ck v1 0.1 0 0.2 … 0 v2 0.2 0 0.1 … 0 v3 0 0.1 0 … 0.3 … vn 0.3 0.1 0 … 0 左から順に走査し，各非零成分において，ここでヒットした ときの類似度の最大値が閾値を越える場合のみインデックスを保存 （なのではじめのほうはインデックスは作られない）
- 162. AllPairsの動作の雰囲気 162 c1 c2 c3 ck v1 0.1 0 0.2 … 0 v2 0.2 0 0.1 … 0 v3 0 0.1 0 … 0.3 … vn 0.3 0.1 0 … 0 今度は右から順に走査し，各非零成分において，すでに作成したイン デックスと一致するものがあれば，徐々にドットプロダクトを足していく
- 163. AllPairsの動作の雰囲気 163 c1 c2 c3 ck v1 0.1 0 0.2 … 0 v2 0.2 0 0.1 … 0 v3 0 0.1 0 … 0.3 … vn 0.3 0.1 0 … 0 インデックス作成していない部分から最後までちゃんと計算する
- 164. AllPairsの動作の雰囲気 164 c1 c2 c3 ck v1 0.1 0 0.2 … 0 v2 0.2 0 0.1 … 0 v3 0 0.1 0 … 0.3 … vn 0.3 0.1 0 … 0 以降，繰り返し（ただし徐々にインデックスされるベクトルが増えていく）
- 165. 準備：記号の意味など x (or y ) …ベクトル |x | …ベクトルのサイズ（非零成分の数） x ’ …ベクトルのprefix（前半部分） x ’’ …ベクトルのsuffix（後半部分） rwi or rwx …行列の i 行目の最大値 or ベクトル x の最大値 cwj …行列の j 列目の最大値 165
- 168. AllPairsアルゴリズム(1/2) 168 b1 : この列で初めてヒットした場合の x との類似度の最大値 これが閾値 t を下回る場合，もはや閾値を越えることはない＝インデックス不要 インデックス フィルタリング
- 173. AllPairsの拡張(1/2) 3つのフィルタリングの閾値 b, sz, rs をきつくする これらの閾値を併用して使うと効果的 APT [Awekar, WI-IAT09] sz2 ← (t/rwx)2 rs2 ← 1 2 𝑥𝑗+1 ′ 2 + 1 2 MMJoin [Lee, DEXA10] b2 ← 1 2 𝑥𝑗+1 ′ 2 + 1 2 sz3 ← t/(rwx * rwy) 173 不等式の性質を利用 単位ベクトルなので 𝑗=1 𝑚 𝑦𝑗 ≥ 𝑘 → 𝑦 ≥ 𝑘2
- 177. L2APのアルゴリズム(1/2) 177
- 178. L2APのアルゴリズム(1/2) 178 コーシー＝シュワルツの不等式から得た新たな閾値b3 を導入 そしてもはやb2 はいらない（確実に b2 ≧b3 なので） インデックスフィルタ リングの閾値算出
- 180. L2APのアルゴリズム(2/2) 180
- 182. L2APのアルゴリズム(2/2) 182 rs は新しく2種類提案 rs3 はrs1 を改善したシンプルなやつ rs4 はコーシー＝シュワルツ使ったやつ（こっちのほうが強力）
- 183. 評価用データセット n: ベクトル数 m: 次元数 nnz: 非零成分数（サイズ数） mrl: 平均行サイズ数 mcl: 平均列サイズ数 183 公開されている データセットも多い