SlideShare uma empresa Scribd logo
1 de 24
Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved
WiredTigerを詳しく説明
2017/09/13
MongoDB勉強会 in 2017
コンサルタント
渡部 徹太郎
1
Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved
自己紹介
2
{"ID" :"fetaro"
"名前":"渡部 徹太郎"
"研究":"東京工業大学でデータベースと情報検索の研究
(@日本データベース学会)"
"仕事":{前職:["証券会社のオンライントレードシステムのWeb基盤",
"オープンソースなら何でも。主にMongoDB,NoSQL"],
現職:["大手Web企業の横断分析基盤,Exadata,Hortonworks,EMR"]
副業:["MongoDBコンサルタント" ]}
"エディタ":"emacs派",
"趣味": ["自宅サーバ","麻雀"]
}
Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved
• 「WiredTiger」をしっていますか?
3
Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved
OS ファイルシステム
WiredTigerとは
• MongoDBの心臓部!
– MongoDBのストレージエンジン
– データの読み書きを担当
– C言語で書かれたOSSを
MongoDB,Incが買収して組み込んだ
• MongoDBの単体性能
≒WiredTigerの性能
4
アプリケーション
MongoDBドライバ
mongodプロセス
WiredTiger
ジャーナル
WiredTiger
データ
WiredTiger
インデックス
ストレージエンジン
WiredTiger
ストレージAPI
クエリエンジン
WiredTigerの担当部分
ディスク
メモリ
Mongoクエリ
BSONと
インデックスの
読み書き
キャッシュ
ファイルIO
Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved
WiredTigerの登場前はMMAPv1
• MongoDB 2.6まではストレージエンジンはMMAPv1だった
– MMAPv1は手抜きのストレージ
• MonvoDB 3.0からはWiredTigerを導入
– ほぼ全ての側面でWiredTigerが優れている(読み込み性能以外)
5
WiredTiger MMAPv1
MongoDB 2.6 ー ✔デフォルト
MongoDB 3.0 (オプション) ✔デフォルト
MongoDB 3.2 ✔デフォルト (オプション)
MongoDB 3.4 ✔デフォルト (オプション)
Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved
WiredTiger と MMAPv1 の違い
6
WiredTiger MMAPv1
概要 特徴 データ永続化に特化 OS提供機能でシンプルに実
装
アーキテクチャ MVCC
(更新は全て追記)
データファイルそのものを
更新
性能 書き込み性能 ◯
ドキュメント単位ロックで高
速
✕
コレクション単位ロックで
低速(※)
読み込み性能 ◯追記型なのでやや複雑 ◎シンプルなので速い
メモリ制限 ◯可能 ✕不可能
(OSが割り当てるだけ使う)
ファイル
システム
データ圧縮 ◯可能 ✕不可能
インデックス圧縮 ◯可能 ✕不可能
データファイルのフラグ
メンテーション
◯最小限 △ドキュメントの肥大化に
より発生
データとインデックスの
分離
◯可能 ✕不可能
耐障害性 ジャーナル無しでクラッ
シュしたとき
◯追記型なので壊れない ✕ドキュメントが壊れる
(リペアが必要)
(※)2.6以前はデータベース単位ロック
Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved
これから
• これからWiredTigerの動作の詳細を説明しますが、
いきなりWiredTigerの説明は難しいので、
まずはシンプルなMMAP v1 から
7
Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved
MMAPv1の動き
• 起動時
– mongodは、OSに対して、
データベースファイルをメモリにmapするように依頼する
– システムコールmmap()を実行
– 起動直後はメモリは空
8
doc1 doc3index doc2
ディスク
メモリ
mongodプロセス
OSが管理
ブロック
データベースファイル
mmap(
)
Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved
MMAPv1の動き
• doc1を読む
– mongodは、OSに対して、ブロックの取得を依頼
– OSは、メモリ上にないので、ディスクから読む(=遅い)
• ページフォルト発生
• doc1と関連するindexのブロックだけが読み込まれる
9
doc1 doc3index doc2
ディスク
メモリ
doc1
mongodプロセス
index
Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved
MMAPv1の動き
• doc1をもう一度読む
– mogodは、OSに対して、ブロックの取得を依頼
– OSは、メモリにあるので、メモリから返す応答する(=速い)
10
doc1 doc3index doc2
ディスク
メモリ
doc1
mongodプロセス
index
Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved
MMAPv1の動き
• doc2を読む
– indexはメモリにあるが、doc2はメモリにないので、ディスク
から読む(遅い)
11
doc1 doc3index doc2
ディスク
メモリ
doc1
mongodプロセス
doc2index
Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved
MMAPv1の動き
• doc3を読む
– doc3はメモリにないので、ディスクから読む
– 空きがないので、最もアクセス頻度の低いブロックを追い出す(ス
ワップアウト)
12
doc1 doc3index doc2
ディスク
メモリ
mongodプロセス
index doc3
Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved
MMAPv1の動き
• doc1を更新(ジャーナル無し)
– mongodは、OSに対して、コレクション単位のロックを依頼して更新
– 他のスレッドからの書き込みは待たされる(=遅くなる)
– メモリ上にindexとdoc1があればメモリ上で更新は完結。なければIO発生
– 非同期でディスクに書き戻し(60秒に一回)
• クラッシュすると最悪60秒間ロストする&データベースファイルが破損する
13
doc1 doc3index doc2
ディスク
メモリmongodプロセス
doc2index'
スレッド スレッド
書き込みを待たされる2.ロック・
doc1とindexを更
新 ×
1.アプリからクエリ4.アプリに返却
ロック開放
5.60秒に1回ディスクに書き戻し
fsync()
doc1'
Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved
MMAPv1の動き
• doc1を更新(ジャーナル有り)
– ジャーナルファイルに更新内容を記載
• クラッシュしても100ms以内の変更は保持
• クラッシュしてもデータ破損自動修復
14
doc1 doc3index doc2
ディスク
メモリmongodプロセス
doc2
スレッド
2.ロックを取得
更新内容を追記
ジャーナル
ジャーナル
5.100msに1回flash
(j:trueなら即時)
4.アプリに返却
ロックを開放
1.アプリからクエリ
3. doc1とindexを
更新
6.60秒に1回ディス
クに書き戻し
doc1'index'
Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved
mongodプロセス
WiredTigerキャッシュ
WiredTigerの動き
• 起動直後
– WiredTigerキャッシュは空
15
doc1
doc
3index ディスク
メモリ
doc2
Readスレッド Writeスレッド
dirtyページ
cleanページ
on diskページ
root
Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved
mongodプロセス
WiredTigerキャッシュ
WiredTigerの動き
• doc1を読む
– ツリーが形成される
– ツリーのリーフはディスクのページ毎に読み込まれている
– indexとdocが含まれるページがキャッシュにのる
16
doc1
doc
3index ディスク
メモリ
doc2
Readスレッド Writeスレッド
doc1index
root
dirtyページ
cleanページ
on diskページ
Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved
mongodプロセス
WiredTigerキャッシュ
WiredTigerの動き
• doc2やdoc3を読む
– キャッシュにのる
17
doc1
doc
3index ディスク
メモリ
doc2
Readスレッド Writeスレッド
doc1index
root
doc
3
doc2 dirtyページ
cleanページ
on diskページ
Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved
mongodプロセス
WiredTigerキャッシュ
WiredTigerの動き
• tx1でdoc1をdoc1'に更新
– ここでトランザクションtx1でdoc1をdoc1'に更新しようとする
– それとは別に、メモリ上のジャーナルに更新内容を書き込む
18
doc1
doc
3index ディスク
メモリ
doc2
Readスレッド Writeスレッド
doc1index
root
doc
3
doc2 doc1’
root(tx1)
dirtyページ
cleanページ
on diskページ
tx1
tx1
tdoc1→doc1'
ジャーナル
ジャーナル
doc1→doc1'
※説明を簡単にするため、
indexの更新は図から省略
50ms毎にディスクに
Snappyで圧縮されて永続化さ
Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved
mongodプロセス
WiredTigerキャッシュ
WiredTigerの動き
• tx2でdoc1を読む
– tx1が終わる前に、doc1の読み込みトランザクションtx2が動き出すと、
tx2には古いドキュメントが見える
19
doc1
doc
3index ディスク
メモリ
doc2
Readスレッド Writeスレッド
doc1index
root
doc
3
doc2 doc1’
root(tx1)
dirtyページ
cleanページ
on diskページ
tx1
tx2
tx2
tx1
tdoc1→doc1'
doc1→doc1'
ジャーナル
Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved
mongodプロセス
WiredTigerキャッシュ
WiredTigerの動き
• tx3がdoc1を読む
– tx1がcommitした後に、tx3がdoc1を読みに行くと、
新しいdoc1' が見える
20
doc1
doc
3index ディスク
メモリ
doc2
Readスレッド Writeスレッド
doc1index
root
doc
3
doc2 doc1’
root(tx1)
dirtyページ
cleanページ
on diskページ
tx3
tx2
tx1
tx3
t
doc1→doc1'
ジャーナル
Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved
mongodプロセス
WiredTigerキャッシュ
WiredTigerの動き
• チェックポイント開始
– 前回のチェックポイントから60秒経過するか、ジャーナルが2GBを超えると、
チェックポイントになる
– Evictionスレッドがcleanなページとdirtyなページをマージしてディスクへ書き込む
21
doc1'
doc
3index ディスク
メモリ
doc2
Readスレッド Writeスレッド
doc1index
root
doc
3
doc2
Evictionスレッド
doc1’
root(tx1)
dirtyページ
cleanページ
on diskページ
doc1→doc1'
ジャーナル
Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved
mongodプロセス
WiredTigerキャッシュ
WiredTigerの動き
• チェックポイント終了
– チェックポイントが終わると、古いツリーは消されて、
キャッシュとディスクが同期する
– ジャーナルは空になる
22
doc1'
doc
3index ディスク
メモリ
doc2
Readスレッド Writeスレッド
index
doc
3
doc2 doc1’
root(tx1)
dirtyページ
cleanページ
on diskページ
ジャーナル
(空)
Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved
まとめ
• WiredTigerはMongoDBの心臓部
• 古い手抜きのMMAPv1から大幅に進化
• ロックを発生させないMVCCを採用
23
Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved
参考にした資料
• ちょっと古い公式説明資料。だいたい同じスライド
– http://www.slideshare.net/mongodb/mongo-db-
wiredtigerwebinar?ref=https%3A%2F%2Fwww.mongodb.co
m%2Fpresentations%2Fwebinar-a-technical-introduction-to-
wiredtiger
– http://www.slideshare.net/NorbertoLeite/mongodb-
wiredtiger-internals
– https://scs.hosted.panopto.com/Panopto/Pages/Viewer.aspx
?id=9a55027f-2b6c-48f4-86f6-73cc167619d0
• 新しい公式セミナ。WiredTigerで使っている様々な工夫を詳細に
説明している。
– https://www.mongodb.com/presentations/mongodb-europe-
2017-building-wiredtiger
• ブログ。WiredTigerのstatの見方や、パフォーマンスチューニング
について解説している
– http://www.developer.com/db/tips-for-mongodb-wiredtiger-
performance-tuning.html
24

Mais conteúdo relacionado

Mais procurados

Mongo dbを知ろう
Mongo dbを知ろうMongo dbを知ろう
Mongo dbを知ろう
CROOZ, inc.
 
MongoDBを用いたソーシャルアプリのログ解析 〜解析基盤構築からフロントUIまで、MongoDBを最大限に活用する〜
MongoDBを用いたソーシャルアプリのログ解析 〜解析基盤構築からフロントUIまで、MongoDBを最大限に活用する〜MongoDBを用いたソーシャルアプリのログ解析 〜解析基盤構築からフロントUIまで、MongoDBを最大限に活用する〜
MongoDBを用いたソーシャルアプリのログ解析 〜解析基盤構築からフロントUIまで、MongoDBを最大限に活用する〜
Takahiro Inoue
 

Mais procurados (20)

分散システムについて語らせてくれ
分散システムについて語らせてくれ分散システムについて語らせてくれ
分散システムについて語らせてくれ
 
はじめてのElasticsearchクラスタ
はじめてのElasticsearchクラスタはじめてのElasticsearchクラスタ
はじめてのElasticsearchクラスタ
 
Redisの特徴と活用方法について
Redisの特徴と活用方法についてRedisの特徴と活用方法について
Redisの特徴と活用方法について
 
がっつりMongoDB事例紹介
がっつりMongoDB事例紹介がっつりMongoDB事例紹介
がっつりMongoDB事例紹介
 
DockerとPodmanの比較
DockerとPodmanの比較DockerとPodmanの比較
DockerとPodmanの比較
 
Mongo dbを知ろう
Mongo dbを知ろうMongo dbを知ろう
Mongo dbを知ろう
 
MongoDB〜その性質と利用場面〜
MongoDB〜その性質と利用場面〜MongoDB〜その性質と利用場面〜
MongoDB〜その性質と利用場面〜
 
本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話
 
Innodb Deep Talk #2 でお話したスライド
Innodb Deep Talk #2 でお話したスライドInnodb Deep Talk #2 でお話したスライド
Innodb Deep Talk #2 でお話したスライド
 
CloudNativePGを動かしてみた! ~PostgreSQL on Kubernetes~(第34回PostgreSQLアンカンファレンス@オンライ...
CloudNativePGを動かしてみた! ~PostgreSQL on Kubernetes~(第34回PostgreSQLアンカンファレンス@オンライ...CloudNativePGを動かしてみた! ~PostgreSQL on Kubernetes~(第34回PostgreSQLアンカンファレンス@オンライ...
CloudNativePGを動かしてみた! ~PostgreSQL on Kubernetes~(第34回PostgreSQLアンカンファレンス@オンライ...
 
Cassandraのしくみ データの読み書き編
Cassandraのしくみ データの読み書き編Cassandraのしくみ データの読み書き編
Cassandraのしくみ データの読み書き編
 
さいきんの InnoDB Adaptive Flushing (仮)
さいきんの InnoDB Adaptive Flushing (仮)さいきんの InnoDB Adaptive Flushing (仮)
さいきんの InnoDB Adaptive Flushing (仮)
 
MongoDBを用いたソーシャルアプリのログ解析 〜解析基盤構築からフロントUIまで、MongoDBを最大限に活用する〜
MongoDBを用いたソーシャルアプリのログ解析 〜解析基盤構築からフロントUIまで、MongoDBを最大限に活用する〜MongoDBを用いたソーシャルアプリのログ解析 〜解析基盤構築からフロントUIまで、MongoDBを最大限に活用する〜
MongoDBを用いたソーシャルアプリのログ解析 〜解析基盤構築からフロントUIまで、MongoDBを最大限に活用する〜
 
At least onceってぶっちゃけ問題の先送りだったよね #kafkajp
At least onceってぶっちゃけ問題の先送りだったよね #kafkajpAt least onceってぶっちゃけ問題の先送りだったよね #kafkajp
At least onceってぶっちゃけ問題の先送りだったよね #kafkajp
 
Fluentdのお勧めシステム構成パターン
Fluentdのお勧めシステム構成パターンFluentdのお勧めシステム構成パターン
Fluentdのお勧めシステム構成パターン
 
後悔しないもんごもんごの使い方 〜アプリ編〜
後悔しないもんごもんごの使い方 〜アプリ編〜後悔しないもんごもんごの使い方 〜アプリ編〜
後悔しないもんごもんごの使い方 〜アプリ編〜
 
ゲームエンジニアのためのデータベース設計
ゲームエンジニアのためのデータベース設計ゲームエンジニアのためのデータベース設計
ゲームエンジニアのためのデータベース設計
 
MongoDBのアレをアレする
MongoDBのアレをアレするMongoDBのアレをアレする
MongoDBのアレをアレする
 
Yahoo! JAPANにおけるApache Cassandraへの取り組み
Yahoo! JAPANにおけるApache Cassandraへの取り組みYahoo! JAPANにおけるApache Cassandraへの取り組み
Yahoo! JAPANにおけるApache Cassandraへの取り組み
 
コンテナにおけるパフォーマンス調査でハマった話
コンテナにおけるパフォーマンス調査でハマった話コンテナにおけるパフォーマンス調査でハマった話
コンテナにおけるパフォーマンス調査でハマった話
 

Semelhante a WiredTigerを詳しく説明

dstn交流会_DataSpider のソーシャルとの融合、手組との融合
dstn交流会_DataSpider のソーシャルとの融合、手組との融合dstn交流会_DataSpider のソーシャルとの融合、手組との融合
dstn交流会_DataSpider のソーシャルとの融合、手組との融合
dstn
 
Introduction to MongoDB
Introduction to MongoDBIntroduction to MongoDB
Introduction to MongoDB
moai kids
 

Semelhante a WiredTigerを詳しく説明 (20)

高速にコンテナを起動できるイメージフォーマット
高速にコンテナを起動できるイメージフォーマット高速にコンテナを起動できるイメージフォーマット
高速にコンテナを起動できるイメージフォーマット
 
ビックデータ処理技術の全体像とリクルートでの使い分け
ビックデータ処理技術の全体像とリクルートでの使い分けビックデータ処理技術の全体像とリクルートでの使い分け
ビックデータ処理技術の全体像とリクルートでの使い分け
 
スマートフォン×Cassandraによるハイパフォーマンス基盤の構築事例
スマートフォン×Cassandraによるハイパフォーマンス基盤の構築事例スマートフォン×Cassandraによるハイパフォーマンス基盤の構築事例
スマートフォン×Cassandraによるハイパフォーマンス基盤の構築事例
 
10大ニュースで振り返るpg con2013
10大ニュースで振り返るpg con201310大ニュースで振り返るpg con2013
10大ニュースで振り返るpg con2013
 
ビッグデータとioDriveの夕べ:ドリコムのデータ分析環境のお話
ビッグデータとioDriveの夕べ:ドリコムのデータ分析環境のお話ビッグデータとioDriveの夕べ:ドリコムのデータ分析環境のお話
ビッグデータとioDriveの夕べ:ドリコムのデータ分析環境のお話
 
PostgreSQL開発コミュニティに参加しよう!(PostgreSQL Conference Japan 2021 発表資料)
PostgreSQL開発コミュニティに参加しよう!(PostgreSQL Conference Japan 2021 発表資料)PostgreSQL開発コミュニティに参加しよう!(PostgreSQL Conference Japan 2021 発表資料)
PostgreSQL開発コミュニティに参加しよう!(PostgreSQL Conference Japan 2021 発表資料)
 
データベースアプリケーション開発セミナー・最新のデータベースとアプリケーション開発の関係
データベースアプリケーション開発セミナー・最新のデータベースとアプリケーション開発の関係データベースアプリケーション開発セミナー・最新のデータベースとアプリケーション開発の関係
データベースアプリケーション開発セミナー・最新のデータベースとアプリケーション開発の関係
 
レガシーな Perl システムに DDD (ドメイン駆動設計)を取り入れる
レガシーな Perl システムに DDD (ドメイン駆動設計)を取り入れるレガシーな Perl システムに DDD (ドメイン駆動設計)を取り入れる
レガシーな Perl システムに DDD (ドメイン駆動設計)を取り入れる
 
Dbtechshowcasesapporo mysql-turing-for-cloud-0.9.3
Dbtechshowcasesapporo mysql-turing-for-cloud-0.9.3Dbtechshowcasesapporo mysql-turing-for-cloud-0.9.3
Dbtechshowcasesapporo mysql-turing-for-cloud-0.9.3
 
ownCloud のあれこれ July Tech Festa 2016
ownCloud のあれこれ July Tech Festa 2016ownCloud のあれこれ July Tech Festa 2016
ownCloud のあれこれ July Tech Festa 2016
 
EmbulkとDigdagとデータ分析基盤と
EmbulkとDigdagとデータ分析基盤とEmbulkとDigdagとデータ分析基盤と
EmbulkとDigdagとデータ分析基盤と
 
EmbulkとDigdagとデータ分析基盤と
EmbulkとDigdagとデータ分析基盤とEmbulkとDigdagとデータ分析基盤と
EmbulkとDigdagとデータ分析基盤と
 
[db tech showcase Tokyo 2016] B31: Spark Summit 2016@SFに参加してきたので最新事例などを紹介しつつデ...
[db tech showcase Tokyo 2016] B31: Spark Summit 2016@SFに参加してきたので最新事例などを紹介しつつデ...[db tech showcase Tokyo 2016] B31: Spark Summit 2016@SFに参加してきたので最新事例などを紹介しつつデ...
[db tech showcase Tokyo 2016] B31: Spark Summit 2016@SFに参加してきたので最新事例などを紹介しつつデ...
 
不揮発メモリ(NVDIMM)とLinuxの対応動向について
不揮発メモリ(NVDIMM)とLinuxの対応動向について不揮発メモリ(NVDIMM)とLinuxの対応動向について
不揮発メモリ(NVDIMM)とLinuxの対応動向について
 
OpenStack Congress Deep Dive
OpenStack Congress Deep DiveOpenStack Congress Deep Dive
OpenStack Congress Deep Dive
 
dstn交流会_DataSpider のソーシャルとの融合、手組との融合
dstn交流会_DataSpider のソーシャルとの融合、手組との融合dstn交流会_DataSpider のソーシャルとの融合、手組との融合
dstn交流会_DataSpider のソーシャルとの融合、手組との融合
 
私とOSSの25年
私とOSSの25年私とOSSの25年
私とOSSの25年
 
Introduction to MongoDB
Introduction to MongoDBIntroduction to MongoDB
Introduction to MongoDB
 
PHP開発者のためのNoSQL入門
PHP開発者のためのNoSQL入門PHP開発者のためのNoSQL入門
PHP開発者のためのNoSQL入門
 
[de:code 2017] 並列分散処理の考え方とオープンソース分散処理系の動向
[de:code 2017] 並列分散処理の考え方とオープンソース分散処理系の動向[de:code 2017] 並列分散処理の考え方とオープンソース分散処理系の動向
[de:code 2017] 並列分散処理の考え方とオープンソース分散処理系の動向
 

Mais de Tetsutaro Watanabe

Mais de Tetsutaro Watanabe (19)

データサイエンティスト向け性能問題対応の基礎
データサイエンティスト向け性能問題対応の基礎データサイエンティスト向け性能問題対応の基礎
データサイエンティスト向け性能問題対応の基礎
 
MLOpsはバズワード
MLOpsはバズワードMLOpsはバズワード
MLOpsはバズワード
 
ドライブレコーダの動画を使った道路情報の自動差分抽出
ドライブレコーダの動画を使った道路情報の自動差分抽出ドライブレコーダの動画を使った道路情報の自動差分抽出
ドライブレコーダの動画を使った道路情報の自動差分抽出
 
IoTデバイスデータ収集の難しい点
IoTデバイスデータ収集の難しい点IoTデバイスデータ収集の難しい点
IoTデバイスデータ収集の難しい点
 
ドライブレコーダの画像認識による道路情報の自動差分抽出
ドライブレコーダの画像認識による道路情報の自動差分抽出ドライブレコーダの画像認識による道路情報の自動差分抽出
ドライブレコーダの画像認識による道路情報の自動差分抽出
 
先駆者に学ぶ MLOpsの実際
先駆者に学ぶ MLOpsの実際先駆者に学ぶ MLOpsの実際
先駆者に学ぶ MLOpsの実際
 
データ収集の基本と「JapanTaxi」アプリにおける実践例
データ収集の基本と「JapanTaxi」アプリにおける実践例データ収集の基本と「JapanTaxi」アプリにおける実践例
データ収集の基本と「JapanTaxi」アプリにおける実践例
 
ML Ops NYC 19 & Strata Data Conference 2019 NewYork 注目セッションまとめ
ML Ops NYC 19 & Strata Data Conference 2019 NewYork 注目セッションまとめML Ops NYC 19 & Strata Data Conference 2019 NewYork 注目セッションまとめ
ML Ops NYC 19 & Strata Data Conference 2019 NewYork 注目セッションまとめ
 
タクシードライブレコーダーの動画処理MLパイプラインにkubernetesを使ってみた
タクシードライブレコーダーの動画処理MLパイプラインにkubernetesを使ってみたタクシードライブレコーダーの動画処理MLパイプラインにkubernetesを使ってみた
タクシードライブレコーダーの動画処理MLパイプラインにkubernetesを使ってみた
 
JapanTaxiにおけるSagemaker+αによる機械学習アプリケーションの本番運用
JapanTaxiにおけるSagemaker+αによる機械学習アプリケーションの本番運用JapanTaxiにおけるSagemaker+αによる機械学習アプリケーションの本番運用
JapanTaxiにおけるSagemaker+αによる機械学習アプリケーションの本番運用
 
JapanTaxiにおけるML Ops 〜機械学習の開発運用プロセス〜
JapanTaxiにおけるML Ops 〜機械学習の開発運用プロセス〜JapanTaxiにおけるML Ops 〜機械学習の開発運用プロセス〜
JapanTaxiにおけるML Ops 〜機械学習の開発運用プロセス〜
 
ビッグデータ処理データベースの全体像と使い分け
2018年version
ビッグデータ処理データベースの全体像と使い分け
2018年versionビッグデータ処理データベースの全体像と使い分け
2018年version
ビッグデータ処理データベースの全体像と使い分け
2018年version
 
Google Cloud Next '18 Recap/報告会 機械学習関連
Google Cloud Next '18 Recap/報告会 機械学習関連Google Cloud Next '18 Recap/報告会 機械学習関連
Google Cloud Next '18 Recap/報告会 機械学習関連
 
巨大なサービスと膨大なデータを支えるプラットフォーム

巨大なサービスと膨大なデータを支えるプラットフォーム
巨大なサービスと膨大なデータを支えるプラットフォーム

巨大なサービスと膨大なデータを支えるプラットフォーム

 
リクルートを支える横断データ基盤と機械学習の適用事例
リクルートを支える横断データ基盤と機械学習の適用事例リクルートを支える横断データ基盤と機械学習の適用事例
リクルートを支える横断データ基盤と機械学習の適用事例
 
ビッグデータ処理データベースの全体像と使い分け - 2017年 Version -
ビッグデータ処理データベースの全体像と使い分け - 2017年 Version - ビッグデータ処理データベースの全体像と使い分け - 2017年 Version -
ビッグデータ処理データベースの全体像と使い分け - 2017年 Version -
 
リクルートテクノロジーズ における EMR の活用とコスト圧縮方法
リクルートテクノロジーズ における EMR の活用とコスト圧縮方法リクルートテクノロジーズ における EMR の活用とコスト圧縮方法
リクルートテクノロジーズ における EMR の活用とコスト圧縮方法
 
MongoDB3.2の紹介
MongoDB3.2の紹介MongoDB3.2の紹介
MongoDB3.2の紹介
 
MongoDB World 2014に行ってきた!
MongoDB World 2014に行ってきた!MongoDB World 2014に行ってきた!
MongoDB World 2014に行ってきた!
 

WiredTigerを詳しく説明

  • 1. Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved WiredTigerを詳しく説明 2017/09/13 MongoDB勉強会 in 2017 コンサルタント 渡部 徹太郎 1
  • 2. Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved 自己紹介 2 {"ID" :"fetaro" "名前":"渡部 徹太郎" "研究":"東京工業大学でデータベースと情報検索の研究 (@日本データベース学会)" "仕事":{前職:["証券会社のオンライントレードシステムのWeb基盤", "オープンソースなら何でも。主にMongoDB,NoSQL"], 現職:["大手Web企業の横断分析基盤,Exadata,Hortonworks,EMR"] 副業:["MongoDBコンサルタント" ]} "エディタ":"emacs派", "趣味": ["自宅サーバ","麻雀"] }
  • 3. Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved • 「WiredTiger」をしっていますか? 3
  • 4. Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved OS ファイルシステム WiredTigerとは • MongoDBの心臓部! – MongoDBのストレージエンジン – データの読み書きを担当 – C言語で書かれたOSSを MongoDB,Incが買収して組み込んだ • MongoDBの単体性能 ≒WiredTigerの性能 4 アプリケーション MongoDBドライバ mongodプロセス WiredTiger ジャーナル WiredTiger データ WiredTiger インデックス ストレージエンジン WiredTiger ストレージAPI クエリエンジン WiredTigerの担当部分 ディスク メモリ Mongoクエリ BSONと インデックスの 読み書き キャッシュ ファイルIO
  • 5. Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved WiredTigerの登場前はMMAPv1 • MongoDB 2.6まではストレージエンジンはMMAPv1だった – MMAPv1は手抜きのストレージ • MonvoDB 3.0からはWiredTigerを導入 – ほぼ全ての側面でWiredTigerが優れている(読み込み性能以外) 5 WiredTiger MMAPv1 MongoDB 2.6 ー ✔デフォルト MongoDB 3.0 (オプション) ✔デフォルト MongoDB 3.2 ✔デフォルト (オプション) MongoDB 3.4 ✔デフォルト (オプション)
  • 6. Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved WiredTiger と MMAPv1 の違い 6 WiredTiger MMAPv1 概要 特徴 データ永続化に特化 OS提供機能でシンプルに実 装 アーキテクチャ MVCC (更新は全て追記) データファイルそのものを 更新 性能 書き込み性能 ◯ ドキュメント単位ロックで高 速 ✕ コレクション単位ロックで 低速(※) 読み込み性能 ◯追記型なのでやや複雑 ◎シンプルなので速い メモリ制限 ◯可能 ✕不可能 (OSが割り当てるだけ使う) ファイル システム データ圧縮 ◯可能 ✕不可能 インデックス圧縮 ◯可能 ✕不可能 データファイルのフラグ メンテーション ◯最小限 △ドキュメントの肥大化に より発生 データとインデックスの 分離 ◯可能 ✕不可能 耐障害性 ジャーナル無しでクラッ シュしたとき ◯追記型なので壊れない ✕ドキュメントが壊れる (リペアが必要) (※)2.6以前はデータベース単位ロック
  • 7. Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved これから • これからWiredTigerの動作の詳細を説明しますが、 いきなりWiredTigerの説明は難しいので、 まずはシンプルなMMAP v1 から 7
  • 8. Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved MMAPv1の動き • 起動時 – mongodは、OSに対して、 データベースファイルをメモリにmapするように依頼する – システムコールmmap()を実行 – 起動直後はメモリは空 8 doc1 doc3index doc2 ディスク メモリ mongodプロセス OSが管理 ブロック データベースファイル mmap( )
  • 9. Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved MMAPv1の動き • doc1を読む – mongodは、OSに対して、ブロックの取得を依頼 – OSは、メモリ上にないので、ディスクから読む(=遅い) • ページフォルト発生 • doc1と関連するindexのブロックだけが読み込まれる 9 doc1 doc3index doc2 ディスク メモリ doc1 mongodプロセス index
  • 10. Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved MMAPv1の動き • doc1をもう一度読む – mogodは、OSに対して、ブロックの取得を依頼 – OSは、メモリにあるので、メモリから返す応答する(=速い) 10 doc1 doc3index doc2 ディスク メモリ doc1 mongodプロセス index
  • 11. Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved MMAPv1の動き • doc2を読む – indexはメモリにあるが、doc2はメモリにないので、ディスク から読む(遅い) 11 doc1 doc3index doc2 ディスク メモリ doc1 mongodプロセス doc2index
  • 12. Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved MMAPv1の動き • doc3を読む – doc3はメモリにないので、ディスクから読む – 空きがないので、最もアクセス頻度の低いブロックを追い出す(ス ワップアウト) 12 doc1 doc3index doc2 ディスク メモリ mongodプロセス index doc3
  • 13. Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved MMAPv1の動き • doc1を更新(ジャーナル無し) – mongodは、OSに対して、コレクション単位のロックを依頼して更新 – 他のスレッドからの書き込みは待たされる(=遅くなる) – メモリ上にindexとdoc1があればメモリ上で更新は完結。なければIO発生 – 非同期でディスクに書き戻し(60秒に一回) • クラッシュすると最悪60秒間ロストする&データベースファイルが破損する 13 doc1 doc3index doc2 ディスク メモリmongodプロセス doc2index' スレッド スレッド 書き込みを待たされる2.ロック・ doc1とindexを更 新 × 1.アプリからクエリ4.アプリに返却 ロック開放 5.60秒に1回ディスクに書き戻し fsync() doc1'
  • 14. Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved MMAPv1の動き • doc1を更新(ジャーナル有り) – ジャーナルファイルに更新内容を記載 • クラッシュしても100ms以内の変更は保持 • クラッシュしてもデータ破損自動修復 14 doc1 doc3index doc2 ディスク メモリmongodプロセス doc2 スレッド 2.ロックを取得 更新内容を追記 ジャーナル ジャーナル 5.100msに1回flash (j:trueなら即時) 4.アプリに返却 ロックを開放 1.アプリからクエリ 3. doc1とindexを 更新 6.60秒に1回ディス クに書き戻し doc1'index'
  • 15. Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved mongodプロセス WiredTigerキャッシュ WiredTigerの動き • 起動直後 – WiredTigerキャッシュは空 15 doc1 doc 3index ディスク メモリ doc2 Readスレッド Writeスレッド dirtyページ cleanページ on diskページ root
  • 16. Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved mongodプロセス WiredTigerキャッシュ WiredTigerの動き • doc1を読む – ツリーが形成される – ツリーのリーフはディスクのページ毎に読み込まれている – indexとdocが含まれるページがキャッシュにのる 16 doc1 doc 3index ディスク メモリ doc2 Readスレッド Writeスレッド doc1index root dirtyページ cleanページ on diskページ
  • 17. Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved mongodプロセス WiredTigerキャッシュ WiredTigerの動き • doc2やdoc3を読む – キャッシュにのる 17 doc1 doc 3index ディスク メモリ doc2 Readスレッド Writeスレッド doc1index root doc 3 doc2 dirtyページ cleanページ on diskページ
  • 18. Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved mongodプロセス WiredTigerキャッシュ WiredTigerの動き • tx1でdoc1をdoc1'に更新 – ここでトランザクションtx1でdoc1をdoc1'に更新しようとする – それとは別に、メモリ上のジャーナルに更新内容を書き込む 18 doc1 doc 3index ディスク メモリ doc2 Readスレッド Writeスレッド doc1index root doc 3 doc2 doc1’ root(tx1) dirtyページ cleanページ on diskページ tx1 tx1 tdoc1→doc1' ジャーナル ジャーナル doc1→doc1' ※説明を簡単にするため、 indexの更新は図から省略 50ms毎にディスクに Snappyで圧縮されて永続化さ
  • 19. Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved mongodプロセス WiredTigerキャッシュ WiredTigerの動き • tx2でdoc1を読む – tx1が終わる前に、doc1の読み込みトランザクションtx2が動き出すと、 tx2には古いドキュメントが見える 19 doc1 doc 3index ディスク メモリ doc2 Readスレッド Writeスレッド doc1index root doc 3 doc2 doc1’ root(tx1) dirtyページ cleanページ on diskページ tx1 tx2 tx2 tx1 tdoc1→doc1' doc1→doc1' ジャーナル
  • 20. Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved mongodプロセス WiredTigerキャッシュ WiredTigerの動き • tx3がdoc1を読む – tx1がcommitした後に、tx3がdoc1を読みに行くと、 新しいdoc1' が見える 20 doc1 doc 3index ディスク メモリ doc2 Readスレッド Writeスレッド doc1index root doc 3 doc2 doc1’ root(tx1) dirtyページ cleanページ on diskページ tx3 tx2 tx1 tx3 t doc1→doc1' ジャーナル
  • 21. Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved mongodプロセス WiredTigerキャッシュ WiredTigerの動き • チェックポイント開始 – 前回のチェックポイントから60秒経過するか、ジャーナルが2GBを超えると、 チェックポイントになる – Evictionスレッドがcleanなページとdirtyなページをマージしてディスクへ書き込む 21 doc1' doc 3index ディスク メモリ doc2 Readスレッド Writeスレッド doc1index root doc 3 doc2 Evictionスレッド doc1’ root(tx1) dirtyページ cleanページ on diskページ doc1→doc1' ジャーナル
  • 22. Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved mongodプロセス WiredTigerキャッシュ WiredTigerの動き • チェックポイント終了 – チェックポイントが終わると、古いツリーは消されて、 キャッシュとディスクが同期する – ジャーナルは空になる 22 doc1' doc 3index ディスク メモリ doc2 Readスレッド Writeスレッド index doc 3 doc2 doc1’ root(tx1) dirtyページ cleanページ on diskページ ジャーナル (空)
  • 23. Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved まとめ • WiredTigerはMongoDBの心臓部 • 古い手抜きのMMAPv1から大幅に進化 • ロックを発生させないMVCCを採用 23
  • 24. Copyright ⓒ2017 CREATIONLINE, INC. All Rights Reserved 参考にした資料 • ちょっと古い公式説明資料。だいたい同じスライド – http://www.slideshare.net/mongodb/mongo-db- wiredtigerwebinar?ref=https%3A%2F%2Fwww.mongodb.co m%2Fpresentations%2Fwebinar-a-technical-introduction-to- wiredtiger – http://www.slideshare.net/NorbertoLeite/mongodb- wiredtiger-internals – https://scs.hosted.panopto.com/Panopto/Pages/Viewer.aspx ?id=9a55027f-2b6c-48f4-86f6-73cc167619d0 • 新しい公式セミナ。WiredTigerで使っている様々な工夫を詳細に 説明している。 – https://www.mongodb.com/presentations/mongodb-europe- 2017-building-wiredtiger • ブログ。WiredTigerのstatの見方や、パフォーマンスチューニング について解説している – http://www.developer.com/db/tips-for-mongodb-wiredtiger- performance-tuning.html 24