Slide 1

Slide 1 text

Cloud Native Database Cloud Native Database Meetup LT Meetup LT Cloud Native DBと言えば論文!! Cloud Native DBと言えば論文!! @kenji @kenji 1 1

Slide 2

Slide 2 text

About me About me 名前/所属: 米川 賢治 @ 某SIer 名前/所属: 米川 賢治 @ 某SIer Likes: 分散システム, Google Cloud, MLが大好きなエンジニア Likes: 分散システム, Google Cloud, MLが大好きなエンジニア お手伝い: GCPUG Yokohama, JTUG お手伝い: GCPUG Yokohama, JTUG linkedin: linkedin: https://www.linkedin.com/in/kenjiyonekawa/ https://www.linkedin.com/in/kenjiyonekawa/ 2 2

Slide 3

Slide 3 text

アウトライン アウトライン なぜCloud Native DBと言えば論文なの? なぜCloud Native DBと言えば論文なの? 効率の良い論文の読み方 効率の良い論文の読み方 論文読んでみた例 論文読んでみた例 3 3

Slide 4

Slide 4 text

なぜCloud Native DBと言えば論文なの? なぜCloud Native DBと言えば論文なの? 4 4 . . 1 1

Slide 5

Slide 5 text

Cloud Native DBの多くが論文を参考にしてる! Cloud Native DBの多くが論文を参考にしてる! 一例: 一例: : : : : , , : : , , : : , , , , : : : : , , HBase HBase Bigtable Bigtable Spanner Spanner Paxos Paxos Bigtable Bigtable CockroachDB CockroachDB Spanner Spanner Logical Physical Clocks Logical Physical Clocks TiDB TiDB Spanner Spanner Percolator Percolator Raft Raft Apache Drill Apache Drill Dremel Dremel Dynamo Dynamo Vector Clock Vector Clock Consistent Hashing Consistent Hashing 4 4 . . 2 2

Slide 6

Slide 6 text

論文読めば設計思想や制約が分かる! 論文読めば設計思想や制約が分かる! 例えば。。。 例えば。。。 Raft vs Paxos: 複雑さとコミュニケーションオーバヘッドのト Raft vs Paxos: 複雑さとコミュニケーションオーバヘッドのト レードオフ レードオフ Percolator: リポジトリよりもアップデートのサイズが小さい Percolator: リポジトリよりもアップデートのサイズが小さい 時に、高い性能を発揮する 時に、高い性能を発揮する TiDBは2PCのベースでPercolatorを使ってる TiDBは2PCのベースでPercolatorを使ってる Vector Clock: causalityは分かるけど、パラレルは分からない Vector Clock: causalityは分かるけど、パラレルは分からない Raft             Paxos Raft             Paxos 4 4 . . 3 3

Slide 7

Slide 7 text

使うにしても作るにしても意識したほうが良い! 使うにしても作るにしても意識したほうが良い! どういう背景や思想で作られたもの? どういう背景や思想で作られたもの? 制約はどう解決する?それともそのまま受け継ぐ? 制約はどう解決する?それともそのまま受け継ぐ? 自分たちのワークロードでも満足に動くアーキテクチャ? (デ 自分たちのワークロードでも満足に動くアーキテクチャ? (デ ータ量?レスポンス?) ータ量?レスポンス?) ちゃんと理解しておくことで、正しく使えるし、 ちゃんと理解しておくことで、正しく使えるし、 何か合っても直し方の当たりが付きやすい! 何か合っても直し方の当たりが付きやすい! 4 4 . . 4 4

Slide 8

Slide 8 text

効率の良い論文の読み方 効率の良い論文の読み方 5 5 . . 1 1

Slide 9

Slide 9 text

これで これで30分もあれば要点理解できる 30分もあれば要点理解できるはず はず メタデータ見てみる メタデータ見てみる 被参照数:多い方が良い ( 被参照数:多い方が良い ( ) ) 学会  :良い学会の方が良い ( 学会  :良い学会の方が良い ( , , , , , , , , とか) とか) Author :1st/lastだけ見ればOK Author :1st/lastだけ見ればOK 参照先 :良いのが多い方が良い 参照先 :良いのが多い方が良い 論文の中身読んでみる 論文の中身読んでみる Abstract読む -> intro読む(長かったら飛ばす) -> Abstract読む -> intro読む(長かったら飛ばす) -> conclusion読む -> チャート見る conclusion読む -> チャート見る PageRank PageRank SIGKDD SIGKDD SIGMOD SIGMOD TKDE TKDE WWW WWW VLDB VLDB 5 5 . . 2 2

Slide 10

Slide 10 text

論文読んでみた例: 論文読んでみた例: 今日のテーマである 今日のテーマであるトランザクション トランザクション 6 6 . . 1 1

Slide 11

Slide 11 text

“Opportunities for Optimism in Contended Main- “Opportunities for Optimism in Contended Main- Memory Multicore Transactions”を読んでみる Memory Multicore Transactions”を読んでみる 6 6 . . 2 2

Slide 12

Slide 12 text

論文の概要 論文の概要 競合が多いマルチコア&メインメモリのトランザクションの話 競合が多いマルチコア&メインメモリのトランザクションの話 結果: TPC-Cで 結果: TPC-CでMVCCで3.4倍 MVCCで3.4倍、 、OCCで3.6倍 OCCで3.6倍の性能出た! の性能出た! 結論: 結論: OCC(楽観的並行性制御)はこれまで考えられてたよりも OCC(楽観的並行性制御)はこれまで考えられてたよりも 使い物になるはず 使い物になるはず コントリビューション: コントリビューション: 正しいトランザクション評価方法の提案 正しいトランザクション評価方法の提案 既存の評価方法に色々不具合があって、OCCは過 既存の評価方法に色々不具合があって、OCCは過 小評価されていた 小評価されていた Commit-time updatesとTimestamp splittingの組み合 Commit-time updatesとTimestamp splittingの組み合 わせ わせでOCCもMVCCも性能上がる でOCCもMVCCも性能上がる 6 6 . . 3 3

Slide 13

Slide 13 text

サマリ サマリ Cloud Native DBは Cloud Native DBは論文読むことで理解深まるし、 論文読むことで理解深まるし、 より適した使い方できる! より適した使い方できる! 設計思想や制約が分かる 設計思想や制約が分かる コツつかめば、サクッと読める コツつかめば、サクッと読める 7 7

Slide 14

Slide 14 text

終わりに & 宣伝 終わりに & 宣伝 技術書展11でGoogleのSRE第3弾の本出してるので良かった 技術書展11でGoogleのSRE第3弾の本出してるので良かった ら見て下さい:) ら見て下さい:) 多くの分散システムを設計してきたGoogleによる、セキュア 多くの分散システムを設計してきたGoogleによる、セキュア &信頼性の高いシステム設計の話 &信頼性の高いシステム設計の話なので、Cloud Native DBに なので、Cloud Native DBに もゆかりが深い(と思います) もゆかりが深い(と思います) https://techbookfest.org/product/6336646121259008? https://techbookfest.org/product/6336646121259008? productVariantID=6060960819183616 productVariantID=6060960819183616 8 8

Slide 15

Slide 15 text

Thanks!!!:) Thanks!!!:) 9 9