不揮発性メモリ(PMEM)を利用したストレージエンジンの話 #mysql_jp #myna会 #yahoo #mysql #pmem #不揮発性メモリ

540 Views

July 12, 21

スライド概要

2021/07/09の日本MySQLユーザ会(MyNA会)-下位レイヤー勉強会での発表資料です。
不揮発性メモリ(PMEM)を利用したMySQLストレージエンジン開発の話をしました。

profile-image

エンジニア・デザイナー向けのヤフー公式アカウント。イベント/登壇情報/ブログ記事など、ヤフーの技術・デザインに関わる情報を発信します。

シェア

埋め込む »CMSなどでJSが使えない場合

関連スライド

各ページのテキスト
1.

情報区分 ※スライドマスターで編集してください MySQL ユーザ会 (下位レイヤー勉強会)︓ 不揮発性メモリ(PMEM)を利⽤したストレージエンジンの話 〜Leo Projectのご紹介〜 2021/07/09 ヤフー株式会社 松浦 聖平 Copyright ©2021 (C) Yahoo 2020 Yahoo Japan Japan Corporation Corporation. All rights Allreserved. Rights Reserved.

2.

⾃⼰紹介 • ⽒名︓松浦 聖平 • 現職︓ヤフー株式会社 • 好きなもの︓ (2019-現在) 不揮発性メモリを活⽤したRDBMSの研究開発 • お⾁、お取り寄せ、動物(特に⽝)、aibo、⽔泳 • 苦⼿なもの︓ 爬⾍類、陸上、暑さ • 職歴︓ ⽇系総合電機メーカー (2009-2016) • aiboの飼い主でもあります。 OLTP⽤ RDBMSの研究開発 (2009-2012)︓ • • 同時実⾏性制御 OLAP⽤ RDBMSの研究開発 (2012-2016)︓ • • SQL解析系・最適化 • Federation • ゼロダウンタイムDisaster Recovery ⽶国系 統計解析⽤SWベンダー (2016-2019) • • APAC地域での各種分析システム(AML/ALM/LTV等)のDB/ストレージ設計 ※aiboは、ソニー株式会社の商標です。 ©2021 Yahoo Japan Corporation All rights reserved. 2

3.

Agenda 1. Projectの背景・前提 2. 「Leo」のご紹介 3. まとめ・今後の取り組み ©2021 Yahoo Japan Corporation All rights reserved. 3

4.

1. Projectの背景・前提 ©2021 Yahoo Japan Corporation All rights reserved. 4

5.

背景︓サービス・ワークロード拡⼤によるRDB PFの強化 サービス、データ処理ワークロードは、拡⼤を続けています︕ この拡⼤にともない、社内で提供するRDB PFの強化が求められています。 サービスアプリケーション RDB PF データ分析 PF強化のためのR&D活動を展開 データ集計 分 析 処 理 拡 ⼤ サ ー ビ ス 拡 ⼤ ©2021 Yahoo Japan Corporation All rights reserved. レポート作成 AI/ML 5

6.

前提︓不揮発性メモリ(PMEM)について 電源喪失後もデータが永続するByte-addressableなメモリ 特徴 ①データの永続性(Non-volatile) ②DRAMとSSDの中間的性質 (性能、容量、耐久性) 出典:[1] J, Arulraj, et al. “Letʼs Talk About Storage & Recovery Methods for Non-Volatile Memory Database Systems”. SIGMODʼ 2015. PMEM 製品例 Intel® Optane™DC Persistent Memory DC Persistent Memory (DCPMM) • DDR-T インターフェース (Byte Addressable) • 容量: 128GB, 256GB, 512GB/DIMM Slot ※Intel® and Intel® Optane™ are trademarks of Intel Corpora3on or its subsidiaries. ©2021 Yahoo Japan Corporation All rights reserved. 6

7.

前提︓PMEMのプログラミングモデル 1. File Access (Block Access、既存アプリの改修︓不要、性能︓悪) SNIA PMEM Programming Model 出典:[2] A.Rudoff. “Persistent Memory Programming.” https://www.usenix.org/system/files/login/articles/login̲summer17̲07̲rudoff.pdf • mkfs.xfs /dev/pmem • • • • • mount (-o dax) /dev/pmem /mnt fd=open(“/mnt/aaa”,mode); write(fd,ʼstrʼ,3); fsync(fd); close(fd); InnoDBをPMEM上で 動かせばこの形態 2. Memory Access (Byte Access、既存アプリの改修︓要、性能︓中) mmap Bypass Buffer Cache • • • • • • • • • mkfs.xfs /dev/pmem mount –o dax /dev/pmem /mnt fd=open(“/mnt/aaa”,mode); addr=mmap(fd,xxx); memcpy(addr,ʼstrʼ); //memcpy with byte access clflush(); sfence(); munmap(addr); close(fd); FS-DAX 3. Raw Device Access (独⾃領域管理要、既存アプリの改修︓要、性能︓⾼) • • • • • • • fd=open(“/dev/pmem”,mode); addr=mmap(fd,xxx); //Linux only supports this. memcpy(addr,ʼstrʼ); clflush(); sfence(); munmap(addr); close(fd); ©2021 Yahoo Japan Corporation All rights reserved. DEV-DAX 7

8.

前提︓File AccessではPMEMの性能を引き出せない n Write スループット@10 Threads (i.e. 1GB Write/thread) 理論上のスループット上限値 Ø Intel® Xeon® Gold 6230R x 2, 192GB DRAM, 12 x 128GB DCPMM (1.85GB/sec x 12= 22.2GB/sec) File Access n Average Write スループット: 5GB/sec Memory Access n 大きな乖離 Average Write スループット: 15GB/sec ※Intel®, Intel® Xeon®, Vtune™ are trademarks of Intel Corpora3on or its subsidiaries. ※ Vtune™ Profileを用いてPMEMの利用帯域、各Call Stack でのCPU消費時間を計測 ©2021 Yahoo Japan Corporation All rights reserved. 8

9.

2. 「Leo」のご紹介 ©2021 Yahoo Japan Corporation All rights reserved. 9

10.

PMEM-NativeなMySQLストレージエンジン「Leo」 PMEM上にデータファイル(Heap)とログファイルを配置するDBアーキテクチャを実装。 トランザクション、行レベル排他をサポート Leoの概要・特徴 PMEM上のデータファイル/ログファイルをPMDKを⽤いて操作 DRAM mysqld Buffer/Work Area Leo Storage Engine PMEM Insert Delete mmap with Select Update libpmem Commit Rollback Lock Info. ①データファイルの 動的拡張 Data File(Table/Index) Transaction Log Files 第1世代 ③トランザクションログファイルの オンライン切り替え ※MySQL is a registered trademark of Oracle and/or its affiliates. Status Info. ②ログ出力の並列性を高め る為にP-WALを利用 第2世代 ©2021 Yahoo Japan Corporation All rights reserved. 10

11.

Leoの動作紹介︓可視性制御 n Preventing uncommitted transaction seen by another transaction Update tuples in TX A, and check that the updated tuples are not visible to another transaction TX B until the TX A commits. TX A TX B TX A TX B Updated Tuple Not Visible to Another TX! 1 Tuple Update in Table T1 TX Not Yet Committed Read the Table T1 COMMIT Read the Table T1 Updated Tuple Now Visible to Another TX After the Commit! TX Now Committed ©2021 Yahoo Japan Corporation All rights reserved. 11

12.

Leoの動作紹介︓⾏レベル排他 n Leoʼs Lock Granularity: Tuple-level Update 2 different tuples from 2 transactions, and check that they donʼt block each other. TX A Update a tuple (c1=bbbb) in T1 TX B Update a tuple (c1=cccc) in T1 They donʼt block each other , and can commit TX independently COMMIT TX B TX A COMMIT Not Blocking the other! Changes not visible to another TX before the commit! Changes now visible to each other after the commit! ©2021 Yahoo Japan Corporation All rights reserved. 12

13.

Leoの実装概要︓Handler/Handlerton MySQL前処理系 Storage MySQL Storage Engine Handler Class API • • • • • セッション管理 構文・意味解析 最適化 実行計画生成 Storage Engine 呼び出し • • open()/close() write_row()/delete_row() • scan_row()/update_row(),etc. PMEM Data File Leo Handler Class API • • open()/close() write_row()/delete_row() • scan_row()/update_row(),etc. テーブル・インデクス操作 Transaction Log Files Handlerton Class • commit()/rollback()/recover(), etc Leo Handlerton Class • • 全体制御・TX制御・ログフラッシュ commit()/rollback()/recover(), etc. init()/shutdown()/prefault()* ※ Prefault: Data File/Transaction Log Filesアクセス時のPage-faultを抑制する仕組み。データアクセス時にPage-faultが発⽣すると性能劣化の原因となるため([3]など参照)、 データアクセス前に専⽤スレッドで、Data File/Transaction Log Filesを先読みして、データアクセス時のPage-fault発⽣を抑制。 ※※[3] J. Choi, et al. “Efficient Memory Mapped I/O for In-Memory File Systems”, USENIX HOTSTORAGE 2017. ©2021 Yahoo Japan Corporation All rights reserved. 13

14.

LeoにおけるPrefaultの効果検証 Prefault機構の有無で、Leoのデータロード時間がどの程度変わるかを性能評価 1. Define a Test Table 3. Load Data 96 Concurrent Data Loading DB/Log Placed on PMEM with XFS FS-DAX • • 2. Generate Data • • csv 96 CSV Files to load in parallel Each CSV contains 1M rec. Leo With/Without Prefault feature PMEM: DB & Log 4. Evaluation • Compare the loading time of Leo with Prefault feature and without the feature ©2021 Yahoo Japan Corporation All rights reserved. 14

15.

LeoにおけるPrefaultの効果検証結果 1. Loading Time 3. Profiles データロード時間が1/7程度に短縮 Loading Time Leo W/O Prefault 1 Leo With Prefault 1/7 *Loading Timeは、Prefaultなしの場合を1とした場合の相対値 Leo With Prefault Leo W/O Prefault 61.55% 0.00% mysqld mysqld [.] mysql_execute_command | ---mysql_execute_command |--61.55%--Sql_cmd_load_table::execute | --60.90%--Sql_cmd_load_table::read_rep_field | |--52.65%--write_record | --52.20%--handler::ha_write_row | |--47.79% in_house_se:write_row | |--22.36%--get_rowid() 98.90% 0.00% mysqld mysqld [.] mysql_execute_command | ---mysql_execute_command |--98.90%--Sql_cmd_load_table::execute | --98.51%--Sql_cmd_load_table::read_rep_field | |--94.78%--write_record | --94.50%--handler::ha_write_row | |--89.74% in_house_se:write_row | |--87.01%--page_fault ※シンボル名は一部anonymizeしています。 2. CPU Utilization Page-fault起因によるCPU消費 LEO CPU Utilization (With Prefault Feature) 100 Leo CPU Utilization(W/O Prefault Feature) 90 90 80 80 70 CPU Utilization(%) 100 CPU Utilization(%) 70 60 50 60 50 40 40 30 30 20 20 LeoによるCPU消費 10 10 0 0 us us sy wa st ©2021 Yahoo Japan Corporation All rights reserved. sy wa st 15

16.

3. まとめ・今後の取り組み ©2021 Yahoo Japan Corporation All rights reserved. 16

17.

まとめ・今後の取り組み まとめ • • • RDB PF強化におけるR&D活動の⼀環として、Leo Projectをご紹介 Leoは、PMEM上にデータファイル・ログファイルを配置。 それらをmmapし、トランザクション処理を実⾏ Leoは、page-fault発⽣を抑制する機構であるprefaultを実装 今後の取り組み • • • • • ⾼信頼化 スケールアウト Tiering (PMEM->NVMe SSD->HDD/SSD) 分析処理・OLAPクエリの⾼速化 その他たくさん︕ ©2021 Yahoo Japan Corporation All rights reserved. 17

18.

©2021 Yahoo Japan Corporation All rights reserved. 18