Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

Thesis introduction "RECIPE : Converting Concurrent DRAM Indexes to Persistent-Memory Indexes. "

86 visualizaciones

Publicado el

下記の論文紹介です。Thesis introduction:
Se Kwon Lee, Jayashree Mohan, Sanidhya Kashyap, Taesoo Kim, and Vijay Chidambaram. 2019. Recipe: converting concurrent DRAM indexes to persistent-memory indexes. In Proceedings of the 27th ACM Symposium on Operating Systems Principles (SOSP ’19). Association for Computing Machinery, New York, NY, USA, 462–477. DOI:https://doi.org/10.1145/3341301.3359635

Publicado en: Software
  • Sé el primero en comentar

  • Sé el primero en recomendar esto

Thesis introduction "RECIPE : Converting Concurrent DRAM Indexes to Persistent-Memory Indexes. "

  1. 1. Se Kwon Lee et al, “RECIPE: Converting Concurrent DRAM Indexes to Persistent-Memory Indexes” SOSP 2019 データベースコア輪読会、第2回、2020/04/21 東京⼤学⼤学院情報理⼯学研究科 吉岡弘隆 hyoshiok@tkl.iis.u-tokyo.ac.jp @hyoshiok 1
  2. 2. 概要 • DRAM IndexをPersistent-Memory (PM 不揮発性メモリ) Index に変換することを提案している • DRAM IndexをPM Indexの変換する時の条件を⽰し、事例とし て次のデータ構造をPMを利⽤したものに変換した。B+ tree、 Trie、radix tree、Hash • 変換は30⾏から200⾏で⼩規模。Intel DC Persistent Memory で評価した。その結果、最⼤で5.2倍の性能向上を確認した。 2
  3. 3. はじめに • Introduction • Background • Motivation • The RECIPE Approach • Testing Crash recovery of PM • Case Studies • Evaluation • Discussion • Related Work • conclusion 3
  4. 4. Introduction • Persistent Memory (PM、不揮発性メモリ) • Intel DC Persistent Memory, 2019 April • 様々な研究がされている • FAST & FAIR, Level Hashing, CCeH, NV-Tree, wB+Tree, WOART, FPTree • PM向けのindexの設計は複雑である。(バグの温床) • RECIPE; DRAM indexが正しければ、RECIPEアプローチで正しく変換 したものも正しい。 • 例えば、以前に挿⼊したキーの値が失われていないならば、検索はそれを返す。 • consistencyはcrash recovery と関連性が深い • DRAM indexをPM indexに変換するのはPM indexをゼロから作るより 複雑ではない。障害回復⽤の新規のアルゴリズムが必要となるわけで はない。 4
  5. 5. RECIPEによるPM Index構築の利点 • DRAM indexを変更するので複雑ではない • もとのDRAM indexが⾼性能ならば、その性能をそのまま受け 継ぐ • 5つのDRAM indexをPM indexに変換してみた 5 DRAM index Data structure RECIPE condition lines lines core lines modified CLHT Hash Table #1 12.6K 2.8K 30(1%) HOT Trie #1 36K 2K 38(2%) BwTree B+Tree #2 13K 5.2K 85(1.6%) ART Radix Tree #3 4.5K 1.5K 52(3.4%) Masstree B+Tree & Trie #3 25K 2.2K 200(9%)
  6. 6. Background • DRAM Indexの基本操作 • insert(key, value) • update(key, value) • lookup(key) • range_query(key1, key2) • delete(key) • Structural Modification Operation (SMO) • データそのものの変更ではなくて、索引の作成、更新など • 性能 • 正しさ 6
  7. 7. Concurrency, Isolation • ⼀貫性をたもつためにblocking(ロックなど)、non blocking の⽅式がある。 • PM • DRAMとstorageの中間の性質を持つ • intel x86の場合8 byteの単位で書く、 “mfence”は格納の順番を保証する • x86にはキャッシュフラッシュ⽤に”clflush”, “clwb”, “clflushopt”命令がある • Crash Consistent PM Index • PM indexはDRAMより⼤容量化できる。レイテンシーもDRAM程度 • DRAMはクラッシュ(電源断、カーネルクラッシュなど)からのリカ バリが必要。PMは不必要ないしは軽量。多くのPM index が提案され ている。 • 電源断からの復帰。フラッシュをしておく 7
  8. 8. 補⾜資料、clflush vs clflushopt 8 Intel 64 and IA-32 Architectures Optimization Reference Manual, Chapter 8, Order Number: 248966-042b September 2019
  9. 9. Motivation & The RECIPE Approach • 既存のPM Indexとの⽐較 • FAST & FAIR • PM B+Tree • 設計と実装にバグを発⾒した • 性能も低かった • CCEH • PM Hash table • 2つのバグを発⾒した • PM Indexの設計は難しい。 • principled design (原理原則に基づいた設計) • テスト 9
  10. 10. The RECIPE Approach • 障害⼀貫性を持った原理原則に基づいた設計 • もしDRAM indexの設計が正しいのならば、それを変換したPM index も正しい。 • 条件1 • アトミックな格納で更新する • PMへの変更。キャッシュ・フラッシュ、メモリフェンス命令を挿⼊ • すべてのダーティーデータはPMにフラッシュされる • 条件2 • writerはinconsistencyを修正する(writerがinconsistencyを発⾒した場 合) • reader/writerともにnon-blockingの場合 10
  11. 11. The RECIPE Approach • 条件3 • writerはinconsistencyを修正しない • readerがnon-blockingでwriterがblockingの場合 • PMへの変更。writerがinconsistencyを発⾒できる機構を導⼊する。 inconsistencyを修正する補助機能(helper mechanism)を導⼊する 11
  12. 12. PM Indexのクラッシュリカバリテスト • クラシュリカバリテストは下記をテストする • ⼀貫性のある状態に復元しているか • 永続性のあるデータを消失していないか • どの段階でクラッシュさせるか • テスト空間が膨⼤になるので⼯夫が必要 • 少数のアトミックな格納に注⽬ • 各アトミックな格納後にクラッシュさせてテストする • 他のPMテストツールはランダムにクラッシュさせている • ⼀貫性のテスト • 負荷をかける • PMリカバリ • 結果確認 12
  13. 13. 事例研究 DRAM index reader writer Non-SMO SMO CLHT Non-Blocking Blocking #1 #1 HOT Non-Blocking Blocking #1 #1 BwTree Non-Blocking Non-Blocking #1 #2 ART Non-Blocking Blocking #1 #3 Masstree Non-Blocking Blocking #1 #3 13 Table 2. Categorizing conversion actions
  14. 14. Trie: Height Optimized Trie (HOT) • 空間効率性に優れた trie • Non-SMO • copy-on-write • 挿⼊削除はアトミック。親のポインタを交換することによって原⼦性 を確保 • SMO • prefixビットがミスマッチした時のツールがある • PMへの変更法 • #1、アトミックなポインタの交換。store命令とフラッシュ命令で正し さが保証される • P-HOT、38⾏変更 14
  15. 15. Hash Table: Cache-Line Hash Table CLHT • キャッシュフレンドリーなハッシュテーブル。各バケットは 64 bytes。non-blocking readerのためアトミックは key-value を 持つ • Non-SMO • SMO • PMへの変更 • HOT同様に、挿⼊、削除、リハッシュは単⼀のアトミック store • 30⾏変更(全体2.8K) 15
  16. 16. B+ TREE: BwTree • B+Treeの拡張 • Non-SMO • SMO • PMへの変更 • キャッシュへのフラッシュとメモリフェンス • 85⾏変更(全体5.2K) 16
  17. 17. Radix Tree: Adaptive Radix Tree (ART) • Radix Treeの実装 • Non-SMO • SMO • PMへの変更 • Condition #1 • 52⾏変更(全体1.5K) 17
  18. 18. Hybrid Index: Masstree • キャッシュフレンドリーなTrieとB+treeの拡張 • Non-SMO • SMO • PMへの変更 • Condition #3 • 200⾏変更(全体2.2K) 18
  19. 19. 評価 • 実験環境 • Intel Optane DC Persistent Memory Module (DCPMM), 768GB • DRAM 375GB • 2 socket, 96 core machine (CPU型番は不明) • 32MB Last Level Cache (LLC) • Linux Kernel 4.17, Fedora • Filesystem, ext4 DAX, App Direct mode • NUMA node で single socketに pin して計測 • フラッシュは clwb を利⽤ • libvmmaloc library, PMDKを利⽤ • perfを利⽤してハードウェアイベントを計測 • workload は YCSB (Yahoo! Cloud Serving Benchmark) 19
  20. 20. Ordered Index 20
  21. 21. 21
  22. 22. 22
  23. 23. 関連研究 • 過去5年間、15件のPM indexが提案されている • 3件、open source • FAST & FAIR, CCEH, Level Hashing • RECIPEは principled approach (他はad hoc) • testing • ランダムないしは虱潰し型のテスト • RECIPEは効率的で強⼒。 23
  24. 24. おわりに • https://github.com/utsaslab/RECIPE • 通常のデータ構造をPM対応にするメソッドについて⾔及し、 実際に変更をして、その効果を⽰した。 • 本研究に従って、既存のB+Treeの実装やKVS実装に⼿を⼊れ てみたくなった。 • 他者の研究についてもオープンソースの場合、深堀りできる。 ベンチマークを取るだけでなく、バグの発⾒などもするので貢 献度は⾼いと思った。先⾏研究が丸裸になるイメージだ。 24

×