SlideShare a Scribd company logo
1 of 13
Download to read offline
LineairDB Introduction
2021/06/24


NTT ソフトウェアイノベーションセンタ


中園 翔 (@nikezono)
LineairDB 101
▪ NTTが公開したOSS のトランザクションエンジン


▪ インメモリ・単一ノード・組み込み・メニーコア向け


▪ すべての機能が Epoch-based でデザインされている


▪ NWR: Blind Updateに強い高速ConcurrencyControl向け最適化 (NTT + 川島研, 論文投稿中)


▪ Parallel Logging & CPR checkpointing (SIGMOD 2019)


▪ Epoch-based ROWEX Index (VLDB 2020)


▪ サポートしている機能


▪ Strict Serializability (Linearizability + Serializability)


▪ Durability (Logging & Checkpointing)


▪ Range Scan & Phantom Avoidance (WIP)


▪ Key/Value Interface: #Begin, #Get, #Put, #End, #Scan, #Sync


▪ (現状) サポートしていない機能


▪ Distributed Transaction


▪ Query Interface. SQL/JDBC/ODBC/etc…
Result on YCSB-A (Read 50%, Blind update 50%)
CPU four Intel Xeon E7-8870 (total 144 logical cores)
Memory 1TB (no swap-out)
YCSB Table size 100K
YCSB Record size 8-bytes
Epoch size 1000ms
Contention (θ) 0.9 (highly contended)
# of threads to process txns 70
• 以下,参考資料


– LineairDBの改善点


• Concurrency Control編


• Logging編


• Checkpointing編


– Epoch FrameworkのPros/Cons
Modern In-Memory Database Architecture
1. DRAMの大容量化


Index (Tree) も Logging も,すべてがメモリに乗る前提の設計が必要


-> Disk I/Oよりキャッシュを意識したIndexが良い (B+Tree -> ART, Masstree)


-> Dirty Pageが存在しないのでUndo Logが必要ない (No-steal, Force)


-> I/Oよりも メモリ上のConcurrency Control で性能が律速される


1. CPUのメニーコア化


単一スレッドで動くコンポーネントは基本的にボトルネックに


-> マルチスレッドプログラミングの重要性が増す


-> LineairDBの改善点: Logging, Concurrency Control, Concurrent Index


従来のConcurrency ControlはUpdate-heavyなワークロードに弱い.


Version order == Operation orderの従来理論ではLock/Latchが不可避.
Concurrency Control: Updateの性能問題
Write(x)
T1


T2


T3
Write(x)
Write(x)
wait
wait
Read(x)
コア数を上げると、むしろ


スループットが減少する。
既存トランザクション処理手法
LineairDBでは Blind Update を Epochごとに1 versionを残し省略する.
省略することでログ・ロック・インデックス更新などを全て短縮.
LineairDBのCC: with Epoch Framework
CPUコア数
8倍.世界最速.
ト
タ
ル
ス
ル
プ
ト
[million
txns
/
s]
Write(x)
T1


T2


T3
省略可能
Read(x)
Write(x)
Write(x)
マルチスレッドプログラミングに必要な “同期” や “順序決定” の


オーバヘッドを最小にするため,実時間を Epoch に区切る.
LineairDBのトータルデザイン: Epoch Framework


Worker


#1
Worker


#2
Worker


#3
Wall-Clock Time
Worker


#1
Worker


#2
Worker


#3
Epoch 1 Epoch 2
Commit Point
wait
Txn
Txn
Txn
Txn
Txn
Txn
Txn
Txn
Txn
wait
Txn
Txn
Txn
Txn
Txn
Txn
Txn
Txn
Txn
Committed Active
Logging: Centralized vs Distributed Logging


 Centralized Log Bufferを作ると,Latchが厳しい.


 Distributedだと,”ログが永続化された順序(LSN)” が失われる
Worker
#1
Worker


#2
Worker


#3
Centralized Log Buffer
Latch🔒
Centralized Logging Distributed Logging
Worker


#1
Thread
Local Log
Buffer
Worker


#2
Thread
Local Log
Buffer
Worker


#3
Thread
Local Log
Buffer
#1->#2->#3


Commitもリカバリも


この順で
これが分からないと
Commitを返す順序も


#1 || #2 || #3
LineairDBのLogging: with Epoch Framework


 Log Formatに “所属するepoch”を入れておけば,


 Distributed LoggingしてもCommitはまとめて返せる


 
Distributed Logging
Worker


#1
Thread
Local Log
Buffer
Worker


#2
Thread
Local Log
Buffer
Worker


#3
Thread
Local Log
Buffer
#1 || #2 || #3
全WorkerのすべてのTxnsのロ
グが永続化されるまで,
Epochを進行させない
Wenting Zheng, Stephen Tu, Eddie Kohler, and Barbara Liskov. 2014. Fast databases with fast durability and
recovery through multicore parallelism. In Proceedings of the 11th USENIX conference on Operating Systems
Design and Implementation (OSDI'14). USENIX Association, USA, 465–477.
Commit Point
ここまで待てば,


ActiveなTXはおらず,


どの順番でCommitを
返しても問題なし
Disk-basedでよく用いられる“Fuzzy Checkpointing”は使えない.


 In-memory CheckpointingはConcurrency Controlの問題がある.
Checkpointing: Disk-based vs In-Memory
Committe
d
Disk-based Checkpointing In-Memory Checkpointing
Active
Transaction Log File(s)
Active
Active Txns Log は触らずに,


Committed Txns LogをPagesに反映させればOK.
Pages
Pages
TXN
Worker
TXN
Worker
TXN
Worker
x y z
Checkpointer
Checkpointerの処理は実質
ロングトランザクション.


Read Lockがなければ,


Consistent なCheckpoint
LineairDBのCheckpoint: with Epoch Framework


1ページにつき,2つのバッファを用意.(live/stable)


”checkpoint epoch” を定期的に作り,stable imageを作成.
In-Memory Checkpointing
TXN
Worker
TXN
Worker
TXN
Worker
x y z
Checkpointer
例えば:


1. 30秒おきに,Checkpoint
Epoch ceを作る.


2. ce に属するTxnsは,普段の
バッファに加えて “Stable
Image” も更新する.


3. ce が充分古くなったら,こ
れを読み出すだけで(Latch
なしで) Checkpoint完了


x y z
Live Images
Stable Images
Guna Prasaad, Badrish Chandramouli, and Donald
Kossmann. 2020. Concurrent Prefix Recovery: Performing
CPR on a Database. SIGMOD Rec. 49, 1 (March 2020),
16–23. DOI:https://doi.org/10.1145/3422648.3422653
▪ Epoch Frameworkの性質


▪ Epochは一定時間と “e-1に属するTxnsが全て終了” で進行する


▪ -> ある epoch e において,e-2 に属するActive Txns は存在しない


▪ 同一epochトランザクションは,全て同じタイミングでCommitされる


▪ Pros


▪ ルーズに同期することで,マルチスレッド処理で必要な “順序” が得られる


▪ epochは「バッチでタイムスタンプを作っている」と捉えられる


▪ -> Distributed Logging, Checkpointing, Index, CC,全てに有用


▪ Cons


▪ Commitまでの平均レイテンシが伸びる


▪ Long Transactionが入ると Epochの進行が止まる -> 誰もCommitできない!


▪ バッチ処理との相性が極めて悪い.
Epoch Framework Pros/Cons

More Related Content

What's hot

アーキテクチャから理解するPostgreSQLのレプリケーション
アーキテクチャから理解するPostgreSQLのレプリケーションアーキテクチャから理解するPostgreSQLのレプリケーション
アーキテクチャから理解するPostgreSQLのレプリケーションMasahiko Sawada
 
PostgreSQLのリカバリ超入門(もしくはWAL、CHECKPOINT、オンラインバックアップの仕組み)
PostgreSQLのリカバリ超入門(もしくはWAL、CHECKPOINT、オンラインバックアップの仕組み)PostgreSQLのリカバリ超入門(もしくはWAL、CHECKPOINT、オンラインバックアップの仕組み)
PostgreSQLのリカバリ超入門(もしくはWAL、CHECKPOINT、オンラインバックアップの仕組み)Hironobu Suzuki
 
最新機能までを総ざらい!PostgreSQLの注目機能を振り返る(第32回 中国地方DB勉強会 in 岡山 発表資料)
最新機能までを総ざらい!PostgreSQLの注目機能を振り返る(第32回 中国地方DB勉強会 in 岡山 発表資料)最新機能までを総ざらい!PostgreSQLの注目機能を振り返る(第32回 中国地方DB勉強会 in 岡山 発表資料)
最新機能までを総ざらい!PostgreSQLの注目機能を振り返る(第32回 中国地方DB勉強会 in 岡山 発表資料)NTT DATA Technology & Innovation
 
PostgreSQL16新機能紹介 - libpq接続ロード・バランシング(第41回PostgreSQLアンカンファレンス@オンライン 発表資料)
PostgreSQL16新機能紹介 - libpq接続ロード・バランシング(第41回PostgreSQLアンカンファレンス@オンライン 発表資料)PostgreSQL16新機能紹介 - libpq接続ロード・バランシング(第41回PostgreSQLアンカンファレンス@オンライン 発表資料)
PostgreSQL16新機能紹介 - libpq接続ロード・バランシング(第41回PostgreSQLアンカンファレンス@オンライン 発表資料)NTT DATA Technology & Innovation
 
フックを使ったPostgreSQLの拡張機能を作ってみよう!(第33回PostgreSQLアンカンファレンス@オンライン 発表資料)
フックを使ったPostgreSQLの拡張機能を作ってみよう!(第33回PostgreSQLアンカンファレンス@オンライン 発表資料)フックを使ったPostgreSQLの拡張機能を作ってみよう!(第33回PostgreSQLアンカンファレンス@オンライン 発表資料)
フックを使ったPostgreSQLの拡張機能を作ってみよう!(第33回PostgreSQLアンカンファレンス@オンライン 発表資料)NTT DATA Technology & Innovation
 
PostgreSQLの関数属性を知ろう
PostgreSQLの関数属性を知ろうPostgreSQLの関数属性を知ろう
PostgreSQLの関数属性を知ろうkasaharatt
 
トランザクション入門
トランザクション入門 トランザクション入門
トランザクション入門 Kumazaki Hiroki
 
監査要件を有するシステムに対する PostgreSQL 導入の課題と可能性
監査要件を有するシステムに対する PostgreSQL 導入の課題と可能性監査要件を有するシステムに対する PostgreSQL 導入の課題と可能性
監査要件を有するシステムに対する PostgreSQL 導入の課題と可能性Ohyama Masanori
 
並行実行制御の最適化手法
並行実行制御の最適化手法並行実行制御の最適化手法
並行実行制御の最適化手法Sho Nakazono
 
地理分散DBについて
地理分散DBについて地理分散DBについて
地理分散DBについてKumazaki Hiroki
 
PostgreSQLモニタリング機能の現状とこれから(Open Developers Conference 2020 Online 発表資料)
PostgreSQLモニタリング機能の現状とこれから(Open Developers Conference 2020 Online 発表資料)PostgreSQLモニタリング機能の現状とこれから(Open Developers Conference 2020 Online 発表資料)
PostgreSQLモニタリング機能の現状とこれから(Open Developers Conference 2020 Online 発表資料)NTT DATA Technology & Innovation
 
GPUとSSDがPostgreSQLを加速する~クエリ処理スループット10GB/sへの挑戦~ [DB Tech Showcase Tokyo/2017]
GPUとSSDがPostgreSQLを加速する~クエリ処理スループット10GB/sへの挑戦~ [DB Tech Showcase Tokyo/2017]GPUとSSDがPostgreSQLを加速する~クエリ処理スループット10GB/sへの挑戦~ [DB Tech Showcase Tokyo/2017]
GPUとSSDがPostgreSQLを加速する~クエリ処理スループット10GB/sへの挑戦~ [DB Tech Showcase Tokyo/2017]Kohei KaiGai
 
PostgreSQL開発コミュニティに参加しよう!(PostgreSQL Conference Japan 2021 発表資料)
PostgreSQL開発コミュニティに参加しよう!(PostgreSQL Conference Japan 2021 発表資料)PostgreSQL開発コミュニティに参加しよう!(PostgreSQL Conference Japan 2021 発表資料)
PostgreSQL開発コミュニティに参加しよう!(PostgreSQL Conference Japan 2021 発表資料)NTT DATA Technology & Innovation
 
Scalar DB: Universal Transaction Manager
Scalar DB: Universal Transaction ManagerScalar DB: Universal Transaction Manager
Scalar DB: Universal Transaction ManagerScalar, Inc.
 
固定化か?最新化か?オプティマイザ統計の運用をもう一度考える。 -JPOUG Tech Talk Night #6-
固定化か?最新化か?オプティマイザ統計の運用をもう一度考える。 -JPOUG Tech Talk Night #6-固定化か?最新化か?オプティマイザ統計の運用をもう一度考える。 -JPOUG Tech Talk Night #6-
固定化か?最新化か?オプティマイザ統計の運用をもう一度考える。 -JPOUG Tech Talk Night #6-歩 柴田
 
押さえておきたい、PostgreSQL 13 の新機能!! (PostgreSQL Conference Japan 2020講演資料)
押さえておきたい、PostgreSQL 13 の新機能!! (PostgreSQL Conference Japan 2020講演資料)押さえておきたい、PostgreSQL 13 の新機能!! (PostgreSQL Conference Japan 2020講演資料)
押さえておきたい、PostgreSQL 13 の新機能!! (PostgreSQL Conference Japan 2020講演資料)NTT DATA Technology & Innovation
 
トランザクションの並行実行制御 rev.2
トランザクションの並行実行制御 rev.2トランザクションの並行実行制御 rev.2
トランザクションの並行実行制御 rev.2Takashi Hoshino
 

What's hot (20)

PostgreSQLの運用・監視にまつわるエトセトラ
PostgreSQLの運用・監視にまつわるエトセトラPostgreSQLの運用・監視にまつわるエトセトラ
PostgreSQLの運用・監視にまつわるエトセトラ
 
アーキテクチャから理解するPostgreSQLのレプリケーション
アーキテクチャから理解するPostgreSQLのレプリケーションアーキテクチャから理解するPostgreSQLのレプリケーション
アーキテクチャから理解するPostgreSQLのレプリケーション
 
PostgreSQL: XID周回問題に潜む別の問題
PostgreSQL: XID周回問題に潜む別の問題PostgreSQL: XID周回問題に潜む別の問題
PostgreSQL: XID周回問題に潜む別の問題
 
PostgreSQLのリカバリ超入門(もしくはWAL、CHECKPOINT、オンラインバックアップの仕組み)
PostgreSQLのリカバリ超入門(もしくはWAL、CHECKPOINT、オンラインバックアップの仕組み)PostgreSQLのリカバリ超入門(もしくはWAL、CHECKPOINT、オンラインバックアップの仕組み)
PostgreSQLのリカバリ超入門(もしくはWAL、CHECKPOINT、オンラインバックアップの仕組み)
 
最新機能までを総ざらい!PostgreSQLの注目機能を振り返る(第32回 中国地方DB勉強会 in 岡山 発表資料)
最新機能までを総ざらい!PostgreSQLの注目機能を振り返る(第32回 中国地方DB勉強会 in 岡山 発表資料)最新機能までを総ざらい!PostgreSQLの注目機能を振り返る(第32回 中国地方DB勉強会 in 岡山 発表資料)
最新機能までを総ざらい!PostgreSQLの注目機能を振り返る(第32回 中国地方DB勉強会 in 岡山 発表資料)
 
PostgreSQL16新機能紹介 - libpq接続ロード・バランシング(第41回PostgreSQLアンカンファレンス@オンライン 発表資料)
PostgreSQL16新機能紹介 - libpq接続ロード・バランシング(第41回PostgreSQLアンカンファレンス@オンライン 発表資料)PostgreSQL16新機能紹介 - libpq接続ロード・バランシング(第41回PostgreSQLアンカンファレンス@オンライン 発表資料)
PostgreSQL16新機能紹介 - libpq接続ロード・バランシング(第41回PostgreSQLアンカンファレンス@オンライン 発表資料)
 
フックを使ったPostgreSQLの拡張機能を作ってみよう!(第33回PostgreSQLアンカンファレンス@オンライン 発表資料)
フックを使ったPostgreSQLの拡張機能を作ってみよう!(第33回PostgreSQLアンカンファレンス@オンライン 発表資料)フックを使ったPostgreSQLの拡張機能を作ってみよう!(第33回PostgreSQLアンカンファレンス@オンライン 発表資料)
フックを使ったPostgreSQLの拡張機能を作ってみよう!(第33回PostgreSQLアンカンファレンス@オンライン 発表資料)
 
PostgreSQLの関数属性を知ろう
PostgreSQLの関数属性を知ろうPostgreSQLの関数属性を知ろう
PostgreSQLの関数属性を知ろう
 
トランザクション入門
トランザクション入門 トランザクション入門
トランザクション入門
 
監査要件を有するシステムに対する PostgreSQL 導入の課題と可能性
監査要件を有するシステムに対する PostgreSQL 導入の課題と可能性監査要件を有するシステムに対する PostgreSQL 導入の課題と可能性
監査要件を有するシステムに対する PostgreSQL 導入の課題と可能性
 
並行実行制御の最適化手法
並行実行制御の最適化手法並行実行制御の最適化手法
並行実行制御の最適化手法
 
地理分散DBについて
地理分散DBについて地理分散DBについて
地理分散DBについて
 
PostgreSQLモニタリング機能の現状とこれから(Open Developers Conference 2020 Online 発表資料)
PostgreSQLモニタリング機能の現状とこれから(Open Developers Conference 2020 Online 発表資料)PostgreSQLモニタリング機能の現状とこれから(Open Developers Conference 2020 Online 発表資料)
PostgreSQLモニタリング機能の現状とこれから(Open Developers Conference 2020 Online 発表資料)
 
GPUとSSDがPostgreSQLを加速する~クエリ処理スループット10GB/sへの挑戦~ [DB Tech Showcase Tokyo/2017]
GPUとSSDがPostgreSQLを加速する~クエリ処理スループット10GB/sへの挑戦~ [DB Tech Showcase Tokyo/2017]GPUとSSDがPostgreSQLを加速する~クエリ処理スループット10GB/sへの挑戦~ [DB Tech Showcase Tokyo/2017]
GPUとSSDがPostgreSQLを加速する~クエリ処理スループット10GB/sへの挑戦~ [DB Tech Showcase Tokyo/2017]
 
PostgreSQL開発コミュニティに参加しよう!(PostgreSQL Conference Japan 2021 発表資料)
PostgreSQL開発コミュニティに参加しよう!(PostgreSQL Conference Japan 2021 発表資料)PostgreSQL開発コミュニティに参加しよう!(PostgreSQL Conference Japan 2021 発表資料)
PostgreSQL開発コミュニティに参加しよう!(PostgreSQL Conference Japan 2021 発表資料)
 
Scalar DB: Universal Transaction Manager
Scalar DB: Universal Transaction ManagerScalar DB: Universal Transaction Manager
Scalar DB: Universal Transaction Manager
 
MVSR Schedulerを作るための指針
MVSR Schedulerを作るための指針MVSR Schedulerを作るための指針
MVSR Schedulerを作るための指針
 
固定化か?最新化か?オプティマイザ統計の運用をもう一度考える。 -JPOUG Tech Talk Night #6-
固定化か?最新化か?オプティマイザ統計の運用をもう一度考える。 -JPOUG Tech Talk Night #6-固定化か?最新化か?オプティマイザ統計の運用をもう一度考える。 -JPOUG Tech Talk Night #6-
固定化か?最新化か?オプティマイザ統計の運用をもう一度考える。 -JPOUG Tech Talk Night #6-
 
押さえておきたい、PostgreSQL 13 の新機能!! (PostgreSQL Conference Japan 2020講演資料)
押さえておきたい、PostgreSQL 13 の新機能!! (PostgreSQL Conference Japan 2020講演資料)押さえておきたい、PostgreSQL 13 の新機能!! (PostgreSQL Conference Japan 2020講演資料)
押さえておきたい、PostgreSQL 13 の新機能!! (PostgreSQL Conference Japan 2020講演資料)
 
トランザクションの並行実行制御 rev.2
トランザクションの並行実行制御 rev.2トランザクションの並行実行制御 rev.2
トランザクションの並行実行制御 rev.2
 

Similar to LineairDBの紹介

Ossで作成するチーム開発環境
Ossで作成するチーム開発環境Ossで作成するチーム開発環境
Ossで作成するチーム開発環境Tadahiro Ishisaka
 
「宣言的プログラミング」とSDNのひとつの形態
「宣言的プログラミング」とSDNのひとつの形態「宣言的プログラミング」とSDNのひとつの形態
「宣言的プログラミング」とSDNのひとつの形態npsg
 
Mk network programmability-03
Mk network programmability-03Mk network programmability-03
Mk network programmability-03Miya Kohno
 
.NET Core diagnostics tips
.NET Core diagnostics tips.NET Core diagnostics tips
.NET Core diagnostics tipsYusuke Fujiwara
 
ソフトバンクにおける Java による クラウドネイティブの実現
ソフトバンクにおける Java による クラウドネイティブの実現ソフトバンクにおける Java による クラウドネイティブの実現
ソフトバンクにおける Java による クラウドネイティブの実現Shigeru Tatsuta
 
SQL Azure のシームレスな管理
SQL Azure のシームレスな管理SQL Azure のシームレスな管理
SQL Azure のシームレスな管理junichi anno
 
Devsumi2013 Ruby開発者のみなさん、mrubyで楽しく快適な組み込みアプリ開発を始めませんか?
Devsumi2013 Ruby開発者のみなさん、mrubyで楽しく快適な組み込みアプリ開発を始めませんか?Devsumi2013 Ruby開発者のみなさん、mrubyで楽しく快適な組み込みアプリ開発を始めませんか?
Devsumi2013 Ruby開発者のみなさん、mrubyで楽しく快適な組み込みアプリ開発を始めませんか?Takashi Sogabe
 
デブサミ2013【15-E-2】Ruby開発者のみなさん、mrubyで楽しく快適な組み込みアプリ開発を始めませんか?
デブサミ2013【15-E-2】Ruby開発者のみなさん、mrubyで楽しく快適な組み込みアプリ開発を始めませんか?デブサミ2013【15-E-2】Ruby開発者のみなさん、mrubyで楽しく快適な組み込みアプリ開発を始めませんか?
デブサミ2013【15-E-2】Ruby開発者のみなさん、mrubyで楽しく快適な組み込みアプリ開発を始めませんか?Developers Summit
 
Microservices and Servcie Mesh on Azure
Microservices and Servcie Mesh on AzureMicroservices and Servcie Mesh on Azure
Microservices and Servcie Mesh on AzureTsukasa Kato
 
多分モダンなWebアプリ開発
多分モダンなWebアプリ開発多分モダンなWebアプリ開発
多分モダンなWebアプリ開発tak-nakamura
 
知っているようで知らないNeutron -仮想ルータの冗長と分散- - OpenStack最新情報セミナー 2016年3月
知っているようで知らないNeutron -仮想ルータの冗長と分散- - OpenStack最新情報セミナー 2016年3月 知っているようで知らないNeutron -仮想ルータの冗長と分散- - OpenStack最新情報セミナー 2016年3月
知っているようで知らないNeutron -仮想ルータの冗長と分散- - OpenStack最新情報セミナー 2016年3月 VirtualTech Japan Inc.
 
ORTCの仕様書をざっくり斜め読みする
ORTCの仕様書をざっくり斜め読みするORTCの仕様書をざっくり斜め読みする
ORTCの仕様書をざっくり斜め読みするYusuke Naka
 
NSG フローログを支える技術 - NVF Advanced Flow Logging
NSG フローログを支える技術 - NVF Advanced Flow LoggingNSG フローログを支える技術 - NVF Advanced Flow Logging
NSG フローログを支える技術 - NVF Advanced Flow Logging順也 山口
 
Voicepic@FacebookNight
Voicepic@FacebookNightVoicepic@FacebookNight
Voicepic@FacebookNightManabu Shimobe
 
コモディティL3SW/ルータでオープンなSDNを実現しよう
コモディティL3SW/ルータでオープンなSDNを実現しようコモディティL3SW/ルータでオープンなSDNを実現しよう
コモディティL3SW/ルータでオープンなSDNを実現しようTakashi Sogabe
 
RFC5717(Partial Lock Remote Procedure Call (RPC) for NETCONF)の勉強資料
RFC5717(Partial Lock Remote Procedure Call (RPC) for NETCONF)の勉強資料RFC5717(Partial Lock Remote Procedure Call (RPC) for NETCONF)の勉強資料
RFC5717(Partial Lock Remote Procedure Call (RPC) for NETCONF)の勉強資料Tetsuya Hasegawa
 

Similar to LineairDBの紹介 (20)

Ossで作成するチーム開発環境
Ossで作成するチーム開発環境Ossで作成するチーム開発環境
Ossで作成するチーム開発環境
 
「宣言的プログラミング」とSDNのひとつの形態
「宣言的プログラミング」とSDNのひとつの形態「宣言的プログラミング」とSDNのひとつの形態
「宣言的プログラミング」とSDNのひとつの形態
 
Mk network programmability-03
Mk network programmability-03Mk network programmability-03
Mk network programmability-03
 
.NET Core diagnostics tips
.NET Core diagnostics tips.NET Core diagnostics tips
.NET Core diagnostics tips
 
ソフトバンクにおける Java による クラウドネイティブの実現
ソフトバンクにおける Java による クラウドネイティブの実現ソフトバンクにおける Java による クラウドネイティブの実現
ソフトバンクにおける Java による クラウドネイティブの実現
 
SQL Azure のシームレスな管理
SQL Azure のシームレスな管理SQL Azure のシームレスな管理
SQL Azure のシームレスな管理
 
20201127 .NET 5
20201127 .NET 520201127 .NET 5
20201127 .NET 5
 
Devsumi2013 Ruby開発者のみなさん、mrubyで楽しく快適な組み込みアプリ開発を始めませんか?
Devsumi2013 Ruby開発者のみなさん、mrubyで楽しく快適な組み込みアプリ開発を始めませんか?Devsumi2013 Ruby開発者のみなさん、mrubyで楽しく快適な組み込みアプリ開発を始めませんか?
Devsumi2013 Ruby開発者のみなさん、mrubyで楽しく快適な組み込みアプリ開発を始めませんか?
 
デブサミ2013【15-E-2】Ruby開発者のみなさん、mrubyで楽しく快適な組み込みアプリ開発を始めませんか?
デブサミ2013【15-E-2】Ruby開発者のみなさん、mrubyで楽しく快適な組み込みアプリ開発を始めませんか?デブサミ2013【15-E-2】Ruby開発者のみなさん、mrubyで楽しく快適な組み込みアプリ開発を始めませんか?
デブサミ2013【15-E-2】Ruby開発者のみなさん、mrubyで楽しく快適な組み込みアプリ開発を始めませんか?
 
Microservices and Servcie Mesh on Azure
Microservices and Servcie Mesh on AzureMicroservices and Servcie Mesh on Azure
Microservices and Servcie Mesh on Azure
 
多分モダンなWebアプリ開発
多分モダンなWebアプリ開発多分モダンなWebアプリ開発
多分モダンなWebアプリ開発
 
知っているようで知らないNeutron -仮想ルータの冗長と分散- - OpenStack最新情報セミナー 2016年3月
知っているようで知らないNeutron -仮想ルータの冗長と分散- - OpenStack最新情報セミナー 2016年3月 知っているようで知らないNeutron -仮想ルータの冗長と分散- - OpenStack最新情報セミナー 2016年3月
知っているようで知らないNeutron -仮想ルータの冗長と分散- - OpenStack最新情報セミナー 2016年3月
 
ORTCの仕様書をざっくり斜め読みする
ORTCの仕様書をざっくり斜め読みするORTCの仕様書をざっくり斜め読みする
ORTCの仕様書をざっくり斜め読みする
 
MySQL at Yahoo! JAPAN #dbts2018
MySQL at Yahoo! JAPAN #dbts2018MySQL at Yahoo! JAPAN #dbts2018
MySQL at Yahoo! JAPAN #dbts2018
 
最速C# 7.x
最速C# 7.x最速C# 7.x
最速C# 7.x
 
Kernel vm-2014-05-25
Kernel vm-2014-05-25Kernel vm-2014-05-25
Kernel vm-2014-05-25
 
NSG フローログを支える技術 - NVF Advanced Flow Logging
NSG フローログを支える技術 - NVF Advanced Flow LoggingNSG フローログを支える技術 - NVF Advanced Flow Logging
NSG フローログを支える技術 - NVF Advanced Flow Logging
 
Voicepic@FacebookNight
Voicepic@FacebookNightVoicepic@FacebookNight
Voicepic@FacebookNight
 
コモディティL3SW/ルータでオープンなSDNを実現しよう
コモディティL3SW/ルータでオープンなSDNを実現しようコモディティL3SW/ルータでオープンなSDNを実現しよう
コモディティL3SW/ルータでオープンなSDNを実現しよう
 
RFC5717(Partial Lock Remote Procedure Call (RPC) for NETCONF)の勉強資料
RFC5717(Partial Lock Remote Procedure Call (RPC) for NETCONF)の勉強資料RFC5717(Partial Lock Remote Procedure Call (RPC) for NETCONF)の勉強資料
RFC5717(Partial Lock Remote Procedure Call (RPC) for NETCONF)の勉強資料
 

More from Sho Nakazono

述語ロックの歴史 r2
述語ロックの歴史 r2述語ロックの歴史 r2
述語ロックの歴史 r2Sho Nakazono
 
Checkpointing Algorithms on In-memory DBMS
Checkpointing Algorithms on In-memory DBMSCheckpointing Algorithms on In-memory DBMS
Checkpointing Algorithms on In-memory DBMSSho Nakazono
 
LineairDBの紹介 MySQL編
LineairDBの紹介 MySQL編LineairDBの紹介 MySQL編
LineairDBの紹介 MySQL編Sho Nakazono
 
詳説データベース輪読会: 分散合意その2
詳説データベース輪読会: 分散合意その2詳説データベース輪読会: 分散合意その2
詳説データベース輪読会: 分散合意その2Sho Nakazono
 
論文紹介: Cuckoo filter: practically better than bloom
論文紹介: Cuckoo filter: practically better than bloom論文紹介: Cuckoo filter: practically better than bloom
論文紹介: Cuckoo filter: practically better than bloomSho Nakazono
 
輪読資料: Staring into the abyss an evaluation of concurrency control with one t...
輪読資料: Staring into the abyss  an evaluation of concurrency control with one t...輪読資料: Staring into the abyss  an evaluation of concurrency control with one t...
輪読資料: Staring into the abyss an evaluation of concurrency control with one t...Sho Nakazono
 
[xSIG 2018]InvisibleWriteRule: Extended write protocol for 1VCC
[xSIG 2018]InvisibleWriteRule: Extended write protocol for 1VCC[xSIG 2018]InvisibleWriteRule: Extended write protocol for 1VCC
[xSIG 2018]InvisibleWriteRule: Extended write protocol for 1VCCSho Nakazono
 
論文紹介: An empirical evaluation of in-memory multi-version concurrency control
論文紹介: An empirical evaluation of in-memory multi-version concurrency control論文紹介: An empirical evaluation of in-memory multi-version concurrency control
論文紹介: An empirical evaluation of in-memory multi-version concurrency controlSho Nakazono
 

More from Sho Nakazono (8)

述語ロックの歴史 r2
述語ロックの歴史 r2述語ロックの歴史 r2
述語ロックの歴史 r2
 
Checkpointing Algorithms on In-memory DBMS
Checkpointing Algorithms on In-memory DBMSCheckpointing Algorithms on In-memory DBMS
Checkpointing Algorithms on In-memory DBMS
 
LineairDBの紹介 MySQL編
LineairDBの紹介 MySQL編LineairDBの紹介 MySQL編
LineairDBの紹介 MySQL編
 
詳説データベース輪読会: 分散合意その2
詳説データベース輪読会: 分散合意その2詳説データベース輪読会: 分散合意その2
詳説データベース輪読会: 分散合意その2
 
論文紹介: Cuckoo filter: practically better than bloom
論文紹介: Cuckoo filter: practically better than bloom論文紹介: Cuckoo filter: practically better than bloom
論文紹介: Cuckoo filter: practically better than bloom
 
輪読資料: Staring into the abyss an evaluation of concurrency control with one t...
輪読資料: Staring into the abyss  an evaluation of concurrency control with one t...輪読資料: Staring into the abyss  an evaluation of concurrency control with one t...
輪読資料: Staring into the abyss an evaluation of concurrency control with one t...
 
[xSIG 2018]InvisibleWriteRule: Extended write protocol for 1VCC
[xSIG 2018]InvisibleWriteRule: Extended write protocol for 1VCC[xSIG 2018]InvisibleWriteRule: Extended write protocol for 1VCC
[xSIG 2018]InvisibleWriteRule: Extended write protocol for 1VCC
 
論文紹介: An empirical evaluation of in-memory multi-version concurrency control
論文紹介: An empirical evaluation of in-memory multi-version concurrency control論文紹介: An empirical evaluation of in-memory multi-version concurrency control
論文紹介: An empirical evaluation of in-memory multi-version concurrency control
 

LineairDBの紹介

  • 2. LineairDB 101 ▪ NTTが公開したOSS のトランザクションエンジン ▪ インメモリ・単一ノード・組み込み・メニーコア向け ▪ すべての機能が Epoch-based でデザインされている ▪ NWR: Blind Updateに強い高速ConcurrencyControl向け最適化 (NTT + 川島研, 論文投稿中) ▪ Parallel Logging & CPR checkpointing (SIGMOD 2019) ▪ Epoch-based ROWEX Index (VLDB 2020) ▪ サポートしている機能 ▪ Strict Serializability (Linearizability + Serializability) ▪ Durability (Logging & Checkpointing) ▪ Range Scan & Phantom Avoidance (WIP) ▪ Key/Value Interface: #Begin, #Get, #Put, #End, #Scan, #Sync ▪ (現状) サポートしていない機能 ▪ Distributed Transaction ▪ Query Interface. SQL/JDBC/ODBC/etc…
  • 3. Result on YCSB-A (Read 50%, Blind update 50%) CPU four Intel Xeon E7-8870 (total 144 logical cores) Memory 1TB (no swap-out) YCSB Table size 100K YCSB Record size 8-bytes Epoch size 1000ms Contention (θ) 0.9 (highly contended) # of threads to process txns 70
  • 4. • 以下,参考資料 – LineairDBの改善点 • Concurrency Control編 • Logging編 • Checkpointing編 – Epoch FrameworkのPros/Cons
  • 5. Modern In-Memory Database Architecture 1. DRAMの大容量化 Index (Tree) も Logging も,すべてがメモリに乗る前提の設計が必要 -> Disk I/Oよりキャッシュを意識したIndexが良い (B+Tree -> ART, Masstree) -> Dirty Pageが存在しないのでUndo Logが必要ない (No-steal, Force) -> I/Oよりも メモリ上のConcurrency Control で性能が律速される 1. CPUのメニーコア化 単一スレッドで動くコンポーネントは基本的にボトルネックに -> マルチスレッドプログラミングの重要性が増す -> LineairDBの改善点: Logging, Concurrency Control, Concurrent Index 

  • 6. 従来のConcurrency ControlはUpdate-heavyなワークロードに弱い. Version order == Operation orderの従来理論ではLock/Latchが不可避. Concurrency Control: Updateの性能問題 Write(x) T1 T2 T3 Write(x) Write(x) wait wait Read(x) コア数を上げると、むしろ スループットが減少する。 既存トランザクション処理手法
  • 7. LineairDBでは Blind Update を Epochごとに1 versionを残し省略する. 省略することでログ・ロック・インデックス更新などを全て短縮. LineairDBのCC: with Epoch Framework CPUコア数 8倍.世界最速. ト タ ル ス ル プ ト [million txns / s] Write(x) T1 T2 T3 省略可能 Read(x) Write(x) Write(x)
  • 8. マルチスレッドプログラミングに必要な “同期” や “順序決定” の オーバヘッドを最小にするため,実時間を Epoch に区切る. LineairDBのトータルデザイン: Epoch Framework Worker #1 Worker #2 Worker #3 Wall-Clock Time Worker #1 Worker #2 Worker #3 Epoch 1 Epoch 2 Commit Point wait Txn Txn Txn Txn Txn Txn Txn Txn Txn wait Txn Txn Txn Txn Txn Txn Txn Txn Txn Committed Active
  • 9. Logging: Centralized vs Distributed Logging  Centralized Log Bufferを作ると,Latchが厳しい.  Distributedだと,”ログが永続化された順序(LSN)” が失われる Worker #1 Worker #2 Worker #3 Centralized Log Buffer Latch🔒 Centralized Logging Distributed Logging Worker 
 #1 Thread Local Log Buffer Worker 
 #2 Thread Local Log Buffer Worker 
 #3 Thread Local Log Buffer #1->#2->#3 Commitもリカバリも この順で これが分からないと Commitを返す順序も #1 || #2 || #3
  • 10. LineairDBのLogging: with Epoch Framework  Log Formatに “所属するepoch”を入れておけば, 
  Distributed LoggingしてもCommitはまとめて返せる   Distributed Logging Worker 
 #1 Thread Local Log Buffer Worker 
 #2 Thread Local Log Buffer Worker 
 #3 Thread Local Log Buffer #1 || #2 || #3 全WorkerのすべてのTxnsのロ グが永続化されるまで, Epochを進行させない Wenting Zheng, Stephen Tu, Eddie Kohler, and Barbara Liskov. 2014. Fast databases with fast durability and recovery through multicore parallelism. In Proceedings of the 11th USENIX conference on Operating Systems Design and Implementation (OSDI'14). USENIX Association, USA, 465–477. Commit Point ここまで待てば, ActiveなTXはおらず, どの順番でCommitを 返しても問題なし
  • 11. Disk-basedでよく用いられる“Fuzzy Checkpointing”は使えない.  In-memory CheckpointingはConcurrency Controlの問題がある. Checkpointing: Disk-based vs In-Memory Committe d Disk-based Checkpointing In-Memory Checkpointing Active Transaction Log File(s) Active Active Txns Log は触らずに, Committed Txns LogをPagesに反映させればOK. Pages Pages TXN Worker TXN Worker TXN Worker x y z Checkpointer Checkpointerの処理は実質 ロングトランザクション. Read Lockがなければ, Consistent なCheckpoint
  • 12. LineairDBのCheckpoint: with Epoch Framework 1ページにつき,2つのバッファを用意.(live/stable) ”checkpoint epoch” を定期的に作り,stable imageを作成. In-Memory Checkpointing TXN Worker TXN Worker TXN Worker x y z Checkpointer 例えば: 1. 30秒おきに,Checkpoint Epoch ceを作る. 2. ce に属するTxnsは,普段の バッファに加えて “Stable Image” も更新する. 3. ce が充分古くなったら,こ れを読み出すだけで(Latch なしで) Checkpoint完了 x y z Live Images Stable Images Guna Prasaad, Badrish Chandramouli, and Donald Kossmann. 2020. Concurrent Prefix Recovery: Performing CPR on a Database. SIGMOD Rec. 49, 1 (March 2020), 16–23. DOI:https://doi.org/10.1145/3422648.3422653
  • 13. ▪ Epoch Frameworkの性質 ▪ Epochは一定時間と “e-1に属するTxnsが全て終了” で進行する ▪ -> ある epoch e において,e-2 に属するActive Txns は存在しない ▪ 同一epochトランザクションは,全て同じタイミングでCommitされる ▪ Pros ▪ ルーズに同期することで,マルチスレッド処理で必要な “順序” が得られる ▪ epochは「バッチでタイムスタンプを作っている」と捉えられる ▪ -> Distributed Logging, Checkpointing, Index, CC,全てに有用 ▪ Cons ▪ Commitまでの平均レイテンシが伸びる ▪ Long Transactionが入ると Epochの進行が止まる -> 誰もCommitできない! ▪ バッチ処理との相性が極めて悪い. Epoch Framework Pros/Cons