00:14
はい、じゃあ、浅井さん、今日もよろしくお願いします。
よろしくお願いします。
はい、ということで、引き続き、DDIA Book Clubの、
まあ、週、Book Club後の収録になりますね。
今日は、Chapter 7、Transactionsの章を読んできましたね。
はい。この本、全部で12章なんで、ちょうど折り返せず第7章だと。
あー、そっかそっか。
多分。
まあ、なかなか、ボリューミーな、濃い内容でしたね、今回もね。
はい、面白い内容でしたね、なんか。
ね。
やっぱり、この本読むだけだと、あんまり理解できないんですけど、
そっから、この臨読会を通して、かなり理解が深まった感じがあるので、
今日も良かったなというふうに思います。
ね。いや、もうね、この臨読会のおかげで、結構頑張って読んでるみたいなところ、僕はあるので、
今はね、2週間に2回ぐらいのペースでやってますもんね。
はい。
なんかその、臨読会で皆さんが結構、かなり発言もしてくださるし、
まあ、コメントも事前に書いてくださるじゃないですか。
まあ、それが皆さん結構、日に日に、ていうか、2週間ごとにレベルが上がってくるので、
もっと頑張んなきゃなみたいので、どんどん自分も調べる量が増えていったみたいなところがあって、いいですね。
なんかね、いい感じのポジティブループになってる気がするね。
うん。
僕も最初、なんか。
1センテンスぐらい書いてて、終わってたんだけど、戻ってきたらすっごい書いてたから、ああ、もうちょっと書こうかなみたいな。
確かに。
ねえ。
Google Docsのページ数にすると、5ページ、4ページ分くらいコメントになってて、すごいな。
まじか。
はい。
これ、公開したいぐらいだね。
確かに。
公開してもいいかもしれないです、なんか。
ねえ。まあ、参加者のね、あの、同意があればですけど。
そうですね。
全部公開しなくても。
はい。
1センテンスやってるよみたいなスクショぐらいね、どっかで共有したいけど。
ブログとかに書いたりとかしてもいいかもですね。
ああ、いいかもね。
やっぱなんか、交流が発生してるのがいいね。
ちょっと今回からやってみたけど、Google Docsでコメントしてみたりとか。
はい。
ブッククラブのね、最中も、なんか、絵文字くれたり、スタンプくれたり、コメントくれたりみたいな感じで。
一方向じゃん、基本。本って。
読んで終わりみたいな。
そうですね。
確かに。
せいぜい、字号を読んだ後にブログ書いて、発信してはするかもしんないけどさ。
うん。
うん。
僕もその、けんさんにコメントしていただいて、なんか、あ、確かにこの、自分が言ってること微妙に、なんか、間違ってるかもなっていうの気づいたりして、
それでさらに調べ直してみたいなのがあったんで。
03:02
うん。
さらにフィードバックグループを何度か回せるみたいなのが、いいですね、交流があると。
ねえ、うん。
他人がわか、他人に質問されて自分が答えられないってことは多分。
多分、自分もわかってなかったってことだしね。
うん。
どうすか、こう、林独会ファシリテーションするみたいな意味で、もう3回かな?
そうですね。
いや、まあ、徐々に慣れてきて、最初は結構、知らない方も来たんで緊張したんですけど、
まあ、同じメンバーで3回やらせていただいて、だいぶ慣れてきて、まあ、すごいやりやすいですね、今は。
ね。
かつ、あの、参加者のともしさんも今日褒めてくださったんですけども、
フォーマットがいいっておっしゃってくださって、まあ、けんさんと僕で作ったフォーマットにはなると思うんですけど、
あの、これを他の自分の会社でも使ってくださってるってことは、林独会のフォーマット、なんか。
ねえ、あれめっちゃ嬉しいんじゃないですか、浅井さんとしては。
嬉しいですね。
うん。
交流が広がっていくっていうのが。
ねえ。
なんかこう、ブッククラブノウハウじゃないですけど、ブッククラブやってどうだったみたいなのを最後にやりたいですよね。
なんかこう、DDIAボーンのデータベースと言い寄せたりとか。
確かに。
データベースという要素を抜きにして。
確かに。そうですね。ブッククラブの進め方みたいな話みたいなのができるかもしれないですね。
ね。まあ、データベース要素を抜かないと、ずっと無限にしゃべっちゃう人が一人いるので。
そうなんですか。
ブッククラブということで。
はい。
いや、でもブッククラブめっちゃいいね。浅井さんもこうやってここでやっとくとさ、例えば今後会社で、
はい。
なんか同じフォーマットでやってみたりとかさ、できるかもしれないしね。
そうですね。
いろいろ試せるので楽しそうですね。
うんうん。
読みたい本もいっぱいあるんで。
うんうん。
どんどんいろんなところやってみたいですね。
なんとなくこうブッククラブに向く本と向かない本ってある気はする。
ああ、なるほど。
どうですか?
なんか読んでみたい本、例えば何かありますか?
まあ、読んでみたい本というよりは、
うんうん。
けっこうセキュリティの勉強とかしたいなみたいな思うこともあるので。
うん。
そういうテーマごとにいろいろ本を読んで
いい本があればそれをやるみたいなイメージでしたね
確かにセキュリティは興味ある
何かありますかイメージ
何かそういうのやったみたいな
僕が挙げるとついね
例えば紹介データベースデータベースインターナルとか
ちょっとそこら辺の領域になっちゃうので
逆に今参加してくれてる
ブッククラブの他のメンバーから
全然違う領域のアイデアを聞いてみたい
じゃあそろそろ内容やってきますかね
トランザクション
ということで
今回のキーワードとしては
まずあれだよね
06:00
トランザクションとは何かみたいなのに始まり
大まかにはアノマリーですね
リードスキューとかライトスキューとか
あとリピータブルミード
あとはファントムリードみたいな感じで
トランザクションを使っているときに起こるというか
気にしなきゃいけない失敗パターンというか
アノマリーというのが出てきて
それらを対応するためには
どういったアイソレーションレベルを使うといいですよということで
リードコミッティット リードアンコミッティットとか
あとはスナップアイソレーションとか
シリアライザブルみたいなのが出てきたりしましたね
この2つの概念を理解するっていうのが
多分1つ分かりやすいゴールの1つになるんじゃないかなと思いましたね
それらのあとは実装パターンとしては
コンカレーシーコントロールの方法として
マルチバージョン コンカレーシングコントロール MVCCっていうのがあり
最近でいうとオプティミスティックCC
あとはよくあるペシミスティックCCで
ロックベース ロックベースじゃないのがありますよねみたいな感じで
アノマリーを理解し
アイソレーションレベルを理解する
興味がある人は実装方法として
発展としてコンカレーシングコントロールについても
ちょっと話を広げるみたいな感じになるのが
よくある読み方なのかなと思ったんですけど
小字体に対してざっくり感想としては
アサイさんの方からはどうですか
そうですね
まず最初にアシット特性の説明もちょっとあって
トランザクションっていうのは
アシット特性を満たすもの
アトミシティ コンシステンシー アイソレーション リアビリティですね
っていうのが話があったんですけど
ここで特に自分が
自分がっていうかこの本で重要になったのは
そのAとIですかね
アトミシティとアイソレーション
Cはアプリケーション側で対応すべきもので
Dが僕はあんまり
トランザクションとそんなに関わるものでないのかなと
思ったんですけれども
この
はい なかなかこの
言葉の何ですかね
アシットっていうのはちょっと分かりにくいなって思ったのと
一方でこのAとIが
主な特性なのかなっていうのをちょっと理解して
自分はちょっとすっきりしたような気持ちになりました
確かに
アシットをちゃんと説明したのが
DDIこのショーが初めてか
確かにそうですね
ですかね はい そうかもしれない
なんかね
アシットのコメントも誰かしてたよね
知ってますか
Dさんか
アシットのうちコンシスタンシーの説明で
アプリケーションエンジニアだからね
彼は
そのコンシスタンシーのところというか
09:00
一貫性を保つようにトランザクション適切に
定義することはアプリケーションの責任になります
という言葉を胸に刻みましたとおっしゃってましたね
いやでも僕自分がアプリケーションエンジニアだった時
胸にあんまり刻んでなかった気がするからね
すごいですね
コンシスタンシーもどうすればOKなのかっていうのが
やっぱり難しいところだと思うんで
そのディスカッションの中でも
平行処理で一貫性を保つっていうのが
難しいみたいな話もあったと思うんですけど
そうですね
ここでまた一つの深いトピックになるのかなと思いました
コンシスタンシー
SREという観点とかだと
やっぱりアプリケーションソースコードとか
ビジネス要件が分かんないと口出せないところなので
この前もそういう障害あったんですよね
Read Your Lightみたいな話が出てきた時に
大きめのデータベースがあって
それもうちょっとパフォーマンス上げられないの
みたいな話がなった時に
こういうコンシスタンシーを
担保しなきゃいけないからね
みたいに言われたんですよね
言ってることは分かるんだけど
それが具体的に
アプリケーションのソースコードという観点
データモデルという観点では
どのテーブルの話をしているの
それがどういうビジネス要件と関わってくるの
っていうのはやっぱり
SREがやってる領域から
ビジネス要件とかアプリケーションとか
ドメインロジックの方に
降りていかなくちゃいけないので
そこはこう
個人的には楽しいけど
領域審判になりがちなポイントでもあったので
難しいなというか
そこでそのコンシスタンシーを担保してるのは
アプリケーション開発者なので
実際にそこはどうやって関わっていくんですか
いやもうまだ障害があって
そういう問題があるよねって
明らかになっただけなので
まだ対応策も解決策も何もやってないんですし
いやまだ障害があってそういう問題があるよねって明らかになっただけなのでまだ対応策も解決策も何もやってないんですし
やるとしたら結構大きい話になるのでね
トランザクション周りのロジックを変えるとかっていうのは
確かにすごい大きい話になるのかなって読んでちょっと思って
例えばトランザクションレベルを変更しますというだけでも
クエリの仕方とかを変えなきゃいけなかったりすると思うんで
それがいろんなところに影響してると大変そうだなっていうのは思いました
そうなんですよね
アプリケーションで必要なクリティカルパスみたいなのを
全部明らかにしなきゃいけないんですよね
どこのクエリとか
どこのデータフローは
どのコンシスタンシーを
12:00
担保しなきゃいけなくて
みたいなのを
ミイシーに明らかにしなきゃいけない
と思うんですよ
一個でも漏れてると
特にコンシスタンシーを担保しなきゃいけないのに
それが担保しなくていいよねみたいな
リストに加わってて
破壊的な変更を加え
ちゃうとそれは後から大変なことになる
データ非整合の問題になって
結構後から直すの大変になるのでね
直せないこととかもあるからね
例えば
イベントソーシングとか
みたいな感じで
起こったイベントすべて
ライトアヘッドログ的な感じに
溜めといて
最初から読めば
現在の状態を
再現できるみたいな風に
ちゃんとデータ取ってればいいんだけど
そういう工夫とかも
しないと
破壊的な変更を加えると
データ壊れちゃってもうおしまいです
さよならみたいな
さすがに今の会社はそんなのはないけど
本の中でもマルチオブジェクトとか
シングルオブジェクトの話がちょっとあって
シングルオブジェクト
一つのテーブルに対しての
トランザクションであればシンプルだけど
大体複数にまたがって
例えば残高テーブルと
在庫テーブルとみたいな話があったので
確かにそれの全部を巻き戻すことができるようになったので
大変そうですよね
そうですね
あとアシットのDは
デュラビリティのDだよね
そうですね
多分Dは
リカバリーと結構関係してくると思いますね
例えば
トランザクションのリデューとかアンドゥをしたい
みたいなとき
結局
アプリケーション観点じゃなくて
例えばデータベースがダウンする
シチュエーションって
いろいろあると思うんですよね
例えばハードウェア障害とか
ネットワークの寸断とか
あとはリージョン障害とか
データセンターの障害みたいな
ありますと
データベースがデータ
たくさんのクエリを処理してました
どこでポツンとネットワークでも
ハードウェア障害でもいいと思うんですけど
特定のデータベースが
インスタンスがダウンしました
で復帰しました
復帰したときのデータベースの状態
どこに戻しますかって話ですよね
ここでトランザクションというか
どこまでリデューするか
どのクエリをアンドゥするか
っていうのが結構大事になってくると思うんですよ
だから
DDIAには
そのドゥラビリティの観点とか
リカベリーの話は確かに
この章はそんな書いてなかったんだけど
ドゥラビリティの話をちょっとすると
まず
ここら辺のトランザクション周りの
実装とかって
軽く
よく読んだりしたりしたことあります?
ここら辺でよく出てくるのって
4つぐらいサブコンポーネントみたいなのがあって
一つがトランザクションマネジャー
これはトランザクションをすべてを
15:00
いい感じに管理してくれる
クラスみたいなイメージしてくれればいいんですけど
あとはロックマネジャーですね
ロックマネジャーっていうのは
実際のロック自体を担当する
サブコンポーネントみたいな感じ
3つ目がバッファープール
もしくはページキャッシュって呼ばれるもので
聞いたことありますかね
これは先に4つ目説明するか
4つ目がログマネジャーって言うんですけど
ライトアヘッドログってあるじゃないですか
ワル
ワルはどういう風に使われるかっていうと
データベースに起こった
例えばクリエイトとかインサートアップデートみたいな
イベントログをどんどんどんどん貯めていくんですよ
イミュータブルな感じで
ライトアヘッドな感じでアペンドしていくんですね
例えばデリートっていう操作が入るじゃないですか
デリートって操作が入った時に
ワル的には何も削除しないんですよ
デリートしましたっていうイベントがワルに入るんですよ
わかります?
アップデートした時も
ワルの
ワルっていうのも本当にこう
どんどんどんどんこう
長くなってく
短方向のリストみたいな感じなんですけど
ワルの最初の方のログを見て
そのデータを更新するみたいなのじゃなくて
アップデートしましたっていうのが
後からポンって入るだけなんですよね
だから現在の
じゃあデータって何?って
みたいになった時には
ワルの最初のデータからぐわーっと舐めていって
例えば更新があったら
更新をイベント反映させて
デリートがあったらデリート反映させて
最後までワルの一番後ろの
ログまで
イベントまで見た時に初めて
現在の状態っていうのが
わかるんですよね
このワルを
ディスクに書き込んでおくことによって
途中で
データベースのインスタンスが
落ちてもそのワルから
ある程度再現できるんですよ
なるほど
でも
ワルをディスクに書き込むって
要するに
めちゃくちゃ
遅いし
現在のデータの状態は
ワルから毎回クエリがあるたびに
反映させられないので
ページキャッシュって言って
メモリに
置いとくんですよね
ある程度このページという単位で
そこのページから
実際のデータ
本体は
別のディスク領域に
フラッシュ的にさせながら
やっていくんですよね
というのが
あった前提で
アシットのDのデュラビリティの話をしてるんですけど
このワルがどんどん長くなっていっちゃうので
よくある形
例えば僕もNeo4jに入ってたときに
18:01
ワルがどんどん
伸びていっちゃうじゃないですか
永遠にデータベースのインスタンスが
走ってれば走ってるほど
途中でコンパクション的なことを
しなきゃいけないんですよね
それをチェックポイントみたいなことで
ここからここまでは
ここのチェックポイントまでは
ある程度
いい感じに圧縮するというか
圧縮という用語は
ちょっと適切じゃないかもしれないけど
ここら辺までは
スナップショットみたいな感じで
ここのチェックポイントまでは
ここから後ろはもう見なくていいよみたいな感じで
差分更新みたいな感じにして
というのがあると
ワルが長ければ長いほど
データベースが再起動したときに
再起動の時間がかかっちゃうと
ネットワークの寸断とかで
ダウンしました
再起動しました
そのときになめなきゃいけない
ワルのログの数が多いと
それだけ時間かかっちゃうから
再起動の時間が
1分2分とかなってくると
リライアビリティにも関係してくるじゃないですか
確かに
処理を全部やらせるんですよね
ワルのログ分の
それは時間かかりますね
新しいインスタンスを立ち上げるのに
もう5分10分もかかってきますってなると
リージョン障害が起こったときの
移行とか
あとラフトとかで
コンセンサス組んでるときに
リーダーの障害
リーダーの昇格をするときとかに
他のインスタンス立ち上がるのに
5分も10分待ってられないので
っていうことで
結構アシッドの4特性っていうのは
データベースの実装レベルで見ると
結構関わってくるというか
なるほど
ちょっとDのところが
全然理解できてなかったので
今の説明ですごい
しっくりきました
DDIAではこの章ではあんまりD触れてないですけど
ちなみにそのチェックポイントのところで
スナップショットみたいなのを
チェックポイントで撮って
そこからの差分をワルでやるみたいな感じなんですか
4Gのときは
差分チェックポインティングみたいなのを
当時は実装していて
最新の実装がどうかは追ってないんですけど
でも確かmysqlとかでも
チェックポイントみたいなの聞いたことがあるんで
同じようなアーティストなのかな
そうですね
基本的にワルにログのイベントが
どんどんどんどん溜まっていって
長いリストがあったときに
そのポインターみたいな感じで
ここまでは処理しましたよ
ラストタイムスタンプ
ここから処理しますよ
begin timestamp
begin timestamp
begin timestamp
あと何だったっけな
ここまで今処理中ですよ
end timestampみたいな感じが
なんか3つぐらい
どこまで処理したよみたいな
ポインターを一個一個前に移動させながら
ここまではもうOKです
21:02
ここはチェックポイントですみたいな感じで
バサッと切るみたいな
でそこのチェックポイントから
前のデータもいらないので
そのデータをコミットしちゃえば
あとはワルの消しちゃうみたいな
ディスクからとかやってたら
まあ多分データベースによって
結構実装は違うと思いますけど
はい
このassitのdの部分だけでも
なんかすごいいろんな仕組みがあって
データベースって本当すごいですねっていう
当たり前の感想なんですけど
データベースすごいっていうのを
毎章読みながらね
思いますね
他に何か気になったキーワードとかありますか
そうですね僕は
アイソレーションの段階がいくつかある中で出てきた
スナップショットアイソレーションの
MVCCっていうのが気になりまして
これ結構いい仕組みだなというか
スナップショットアイソレーションを解決するのは
確かLightSkewとか
Phantomとかだったかな
そっちだったかな
あと
今すぐに申し訳ないですけど
いつかリードコミットでは解決できない問題を解決していて
そのトランザクションごとのバージョンを保持する
MVCCっていうのを使って
各トランザクション
新しいトランザクションが
違うトランザクションIDのものを読み込まないように
処理するみたいな仕組みがあると思うんですけども
そのMVCCを使った場合に
トランザクションが一気に
10個くらい入ってきて
その10個のトランザクションのバージョンを
例えば全部保持した場合に
ストレージの負荷とか
どのくらいかかるのかなみたいな
ちょっと気になっていて
すごい良い仕組みだなと思いつつも
逆にデータベースにどのくらい負荷があるんだろうっていうのが
気になって
この辺ケンさんもコメントくださったんですけども
結構調べてくれましたよね
軽くMVCCについて最初に説明すると
お願いします
まずアイソレーションレベルっていうのがありますよね
リードアンコミッティットとか
リードコミッティットとか
すいません
ちょっとブッククラブで喋りすぎて
喉がちょっとやられて
そうそうで
あとはリピータブルリードっていうのがあって
それの実装としてよく使われるMVCC
これはマルチバージョンコンカレッシー
コントロールレベルで
それの実装としてよく使われるMVCCこれはマルチバージョンコンカレッシーコントロールレベルで
それの実装としてよく使われるMVCCこれはマルチバージョンコンカレッシーコントロールの略ですよね
このコンカレッシーコントロールっていうのは
24:00
データベースのパフォーマンスを上げるために
クエリを複数実行したいんですよね
基本的には
とあるタイミングで実行できるクエリが
一つしかないっていうのは
シティアライザビリティの観点からすっごい楽ですけど
めちゃくちゃ遅いので
実現ほぼ不可能
実用段階で
理解ということを考えると
そんなデータベース誰も使ってくれないから
ある程度コンカレントに実装する必要はあるんだけど
コンカレントに実装すると
じゃあこの
整合性どう担保するのよっていう話が出てくるので
そのコンカレントに
実行されるクエリ同士の
制御する仕組みっていうのが必要なんですよね
平行に処理されるクエリの
それには
MVCCっていう
古典的な有名的なのとか
それに対して
あとはペシミスティック
コンカレーシングコントロール
これはいわゆるロックを取る形と
ロックを取らない形あるんですけど
ロックを取ると例えばデッドロックになったりする
やつですね
ペシミスティック
悲観的っていうことなので
要するにこれは
なんだろうね
競合するかどうかわからないと
わかんないからとりあえず
ロックを取っておきましょうみたいな
ロックベースとペシミスティックコンカレーシングコントロールの
アイデアなんですけど
要するに
生前説と小悪説で言うと
小悪説
みたいな感じで
先に悲観的に
ロックを取っていく
3つ目に出てくるのが
オプティミスティックコンカレーシングコントロールで
これは楽観的な話で
問題が出たら考えようよ
みたいな
イージーなやつですね
基本的には
悲観ロックみたいな感じでロックを取らずに
問題が出たときに考える
っていう風に3つ大まかな
コンカレーシングコントロールの実装があるんですけど
そのうちの1つが
MVCC
これがスナップショットアイソレーションの
実現にあたって使われていると
マルチバージョン
って書いてある通り
複数の
バージョンを持つんですよね
とあるリードの
ワークロードが入ってきたときに
ライトと競合してのように
どのバージョンを
オールドバージョンを見れば
他の
ライトと競合しないようにってことで
複数なんだろ
マルチバージョンを持たせることによって
整合性を壊さずに
かつある程度のパターンでは
パフォーマンスを殺さずにできる
みたいな感じで
これが割と結構
デフォルトで使われてるデータベースとかも
ストレージエンジンも多かったりするので
多分このSHOWでも
大々的に取り扱ってるんだと思いますね
メリデメも結構あるんですけどね
アサイさんがね
調べてくれた通り
さっきちょっと間違ったこと言ったんですけど
27:02
このSnapShot Isolationとかを使った場合は
リードロックを取らなくていいっていうのが
メリットなんですかね
読み込みの時にロックをしなくていいから
他の読み込みを邪魔したりしない
みたいなメリットがあって
一方でライトのロックは取るので
えっと
その分
ちょっとより
混乱したんですけど
問題としては
ライトスキルとかファントムみたいなの出てくるみたいな
ちょっとありますね
これちょっとクランブでもコメントしたんですけど
MVCCと
オプティミスティックコンカレーションコントロール
OCCの
違いっていうのを
すっごい
一言で
雑に言うと
MVCCはリードのワークロードに対して強くて
OCCはライトのワークロードに対して強いんですよね
OCCはなんでライトに強いかっていうと
結局その
危険な時にだけ
バリテーションすればいいので
基本的には普段は問題なく
どんどんどんどん書き込みしてるんですよね
なのでMVCCは
そのライトでかつ
コンフリクトが起こりやすいみたいな時に
光る
コンカレーションの実装ではないんですよね
で
多分コメントもあったけど
バージョンをたくさん保持しなきゃいけないので
ある程度
ストレージにどれくらい負荷がかかるのか
みたいなのを事前にアサイさんがね
コメントしてくれて
これは僕も知らなかったので
ちょっと調べたら教えてください
みたいな感じで
コメントしてたんですが
なんかこれは
そうですね
まず
ロックを取る
のが
バージョンを複数
複製するのが
業ベースとかだったりするので
その場合はそんなに負荷がかかんないんじゃないかな
っていうのをまず
推測でちょっと思ったのと
あと調べていく中で
MySQLの
処理の仕方が書いてあって
例えば
巨大なカラム
ラージオブジェクトですね
ロブみたいなやつが
カラムがある時に
そのカラムのバージョンを全部保持してると
たぶんすごい量になるので
例えばそのロブの変更が部分的な場合は
その部分だけのバージョンを複製して
他の変わってない部分は保持して
そのまま複製せずに
同じとこ参照するみたいな
やり方があって
そういう風にちょっと
ストレージの負荷かからないような
工夫がされているのかな
みたいなのを調べて分かりましたね
あとはそうですね
この
どんどん溜まってる
溜まっていったバージョンみたいのは
30:01
バキュームをうまくしていくことで
ストレージを解放することができるみたいな
できると思うんですけど
そのバキューム処理も
たぶんCPUとかに負荷がかかったりするんで
またデメリットの一つになるのかな
っていうのはありそうですね
そうなんですよね
PosgreのMVCCとかは
バキュームが必要
要するにガベッジコレクションですよね
運用の観点からすると
なかなか嬉しい話で
言うことはないですよね
たぶんデータベースによると思いますけど
ストップターワールド的な
プロセスをフリーズさせなきゃいけない
バキュームとかになると
普通にデータベースのパフォーマンスにも
影響してきたりするし
レプリケーションとかにも
バキューム中にレプリケーションが
うまくできないみたいな問題が
自分の昔あった気がしてて
そういう設定によりますけど
そういう影響は色々出そうですね
古典的な感じで
普通にクローンジョブで
毎日特定の時間にバキュームさせてとかね
昔もそんなの見た気もするけど
レプリケーションとかパーティションを考えると
組み合わせて考えると
なかなか難しいところですよね
ボトルネックになっちゃうからね
ケンさん他に何か気になったトピックありますか
気になったトピック
気になったトピックはですね
トピックじゃないけども
今日のアナロジーやりましょうよ
今日のアナロジーやりましょう
一応今回から聞いてくださってる方のために
2回くらい前かな
インデックスって何みたいなのを
アサイさんが奥様に聞かれて
それをアナロジーで説明したら
すごい良かったっていう話があって
アナロジーって結構難しい概念を説明するのに
いいよねってことで
それから今回
それ以降
そのショーで一つアナロジーをお互い考えてくるっていう
謎の宿題を自分に化して
やってみたら面白いんじゃないかなということで
やったんですけど
僕はね一つ
結構今回のショーで大事なのって
シリアライザビリティが何回も出てくると思うんですよね
シリアライザビリティっていうのは
なんで大事かっていうところで
データベースにとってはね
シリアライザビリティを維持しつつ
ここにトランザクションを実行することで
パフォーマンスを上げることができますっていうのがあって
じゃあこれを自分もね
パートナーとかに聞かれたら
なんて説明しようかなと思ってたんですけど
これは僕が考えた例としては
電車の例で考えると分かりやすいのかなと思ってて
例えば線路が一つしかない路線を考えてほしいんですよね
なんかこう東北の田舎に行った時の
なんかすごい田舎の
33:01
なんか一路線しかないような
なんだろうね
ローカル
三陸層
全然東北の人を批判してるわけじゃん
僕が東北出身だから東北を選んだだけなんです
ごめんなさいって感じなんですけど
僕の出身です
そういったね
線路が一つしかない路線って
どんな時刻表
スケジュールを使ってもシリアルなんですよね
だからどの順番で電車が来るっていうのは分かるんですよ
なんだけど
しかし向こうから電車が来た時っていうのは
どちらかの電車は基本的には待たなくちゃいけないので
非常にパフォーマンスは悪い
ここでいうパフォーマンスはデータベースのパフォーマンス
例えば電車で言うなら
時間あたりに運べる人数とでも言いましょうか
これが線路が複数あると
シリアルじゃなくて
普通にコンカレントに実行できるとなると
複数の車両が並行して進むことができるので
全体のパフォーマンスは高いですよね
例えば東京駅を考えてもらうと
メトロの丸の内線から中央線総務線から
いろんな交線が入ってくるので
新幹線も入るので
ただ時刻表がシリアルではないので
どの順番で乗り越えたら
最終目的にどのように行けるかっていうのが
事前に分からないと
なので乗り換えアプリを使いながら
リアルタイムで
今この中央線のこの車両に
乗ると早く新宿に着けそうだよ
みたいのをやっていかないと
なかなか最終目的地に
最短で身につくことができない
っていうのはあるかなと
考えてきたんですけど
どうでしょう
めちゃくちゃわかりやすいですね
これいつも説明したら
理解してもらえますね
データベースってこうやって
制御してるんだって
もうこれ聞いて全然
お前のってこと分かんねえよみたいな
リスナーの意見とかも
いたらぜひ意見欲しいですね
例えるのは本当に難しいですよね
なんていうか
現実世界で
電車の例は想像しやすい例で
ありがたいですね
なんかこのデータベースを実践するときに
一連のデータベース更新である
トランザクションのリスナーのことを
スケジュールって読むんですよ
スケジュールなんかあるかな
電車のスケジュールみたいな感じで
あーはい
時刻表
ただこれをね
昨日の夜ね
MVCCを説明するときにも
使えるかなと思って
この電車の例を発展させて
MVCC使えないかなと思って
考えてたんだけど全然思いつかなくて
いやー難しいっすね
電車のアナロジーに
おけるマルチバージョンとは
みたいな感じになっちゃって
それはどうやって説明せないんだろうか
ね
36:00
電車に乗って
サラリーマンが東京駅で降りて
丸の内で降りて
なんか会社に入ってみたいな
なんか
なんか説明が袋小路になってる
全然出れなくて
それで眠れなくなるっていう
そうそうそう
ややこしいからやっぱ確かに
なんか別のアナロジー考えてたら
アナロジーのデメリットですね
うん
そう
一つで説明するのが
いいっすね
間違ったアナロジー使っちゃうと
逆に
ねなんだろう
誤った
価値観じゃなくて
誤った理解を与えてしまうのでね
確かに
そうですね
これ誰か言ってたけど
例えばそのプログラミングを
中学生とか小学生も教えるときに
あの
インスタンスバリアブル
変数ってあるじゃないですか
はい
どの言語でも
うん
なんか
例えばJavaScriptだったら
const
who
イコール
3ってすると
whoという変数に3が入りますよみたいな
これをあの
アナロジーで
ボックス
箱
って教えると
はい
これ結構危険だよねって誰かが言ってて
すごい僕なるほどって思ったんですけど
あの箱で教え
結局その教えちゃうと
まあこれはねJavaScriptとかRubyとかPythonみたいな
高級言語使ってるからなんですけど
メモリの概念が入ってこないんですよね
メモリとかポインターの概念が
はい
確かに
うん
でここでもう箱っていう感じで
メンタルモデルをフィックスさせちゃうと
あとで
例えばC
Cプラプラとかラストとかを始めた時に
ポインターという概念が出てきて
結構こう
箱の概念をこう乗り越えるのが難しいんですよね
いやそれめっちゃ分かりますでも
うん
これはまさにその被害者ですね
うん分かる
僕もその被害者
うん
そうか
だからそのね
分かんない人に教えないと
そういう人がアナロジーを使うって結構諸刃の剣で
結構責任が問われるんですよ
要領を守りくださいって感じですね
そうそうそうそう
うん
そうか
無理してやんない方がいいですねこれはきっと
うん
まあね
まあでも無理してやんないとできないので
失敗覚悟で僕はちょっとやっていこうかな
仲間の子かなあ
はい
あと何か触れたいところありますか
まあ何かじゃあ
ディスカッショントピックで
1個あったのが
やっぱり自分はその平行処理とかをやってるときのテスト方法が気になりまして
まあそれをトピックとして1個出したんですけれども
平行処理で発生するデータベース上の問題をどうテストするかっていう
まあところをちょっと聞いたときに
前回出ていたともしさんが結構その経験があることですごい勉強だったんですけども
39:05
まあそのどうするかっていうのはまあ数を打つっていうところが結論としては出てきて
まあ明らかに傾向になるように処理を流して
まあそれで起きる問題を無理やり起こさせて
まあそれに対処していくみたいなことがやるべきことだというふうに
教えていたのでまあそれはすごい勉強になりましたね
まあ例えば1つのテーブルの行に一気に100回連続で更新かけてどうなるか見るみたいな
まあそういうことだと思うんですけども
まあそういうふうにテストできるっていう話だったんでそれは面白かったですね
うん
いやここら辺は僕さっぱり分かんなかったので
はい
なんかいろいろ知見とかもありそうですよね
そうですね
他の会社どうやってるんだろう
うん
なんかそういうライブラリとかももしかしたらあるのかもしれないですね
平行処理のテストをするためのちょっと分からないですけど
うんうん
まあ多分世の中にこうテストがあるんですよね
テストにめちゃくちゃ思いがあるエンジニアの方って結構いるから
僕がデータベースならテストにすごい情熱かけて
まあそういう人がもしリスナーの方にいたらぜひ教えてください
確かに
うん
ディスカッション今回からねあの
ブッククラブ今までのフォーマットあと最初に浅いサマリーが入って
各人がテイクアウェイを話してディスカッショントピックだったんだけど
うん
サマリーをやめたんですよね今回から
そうですね
うん
もういらないですよね皆さんのノートが濃すぎて
みんなちゃんと読んでるもんねあれ
そうですね
はい
僕が前のブッククラブでサマリーやってたから最初に浅井さんにサマリーやってたよって言ったのは
あの時読んでない人結構いたんですよだからサマリーね足並み揃えてみたいな
はい
このブッククラブ濃すぎてみんなの情熱がすごいからなんか
はい
こういう風にしてる間に多分上の空って感じになっちゃうから
うん
そうですね知ってるよね
読んでる前提で
うん
はい
でもなんかそうですよねバーを下げずにできるっていうのすごいいいなんだろう
いいメンバーですよね
そうですね
うん
ちょっと自分のために下げてもらっていいかもなちょっと思う時あるんですけど
まあでもはいめちゃくちゃ密度濃いなと思いますはい
本当それは感じなかったですけど
本当ですかじゃあよかったです
うんまあねバーを上げていけるって人はどこでも重宝されるので楽しいですね
はい
こんな感じかな今回は
そうですね
まあ結構何人かも触れてたけどじゃあこれが分散環境でディスビューティッド環境でどうなるのかっていうのは結構気になってる人がいて
42:06
これは多分今後の章にも出てくるのかな旧章って言ってたかな誰だっけな
旧章ですね
旧章でディスビューティッドトランザクションコンセンサスがちょっと入ってたりするので今回は単体データベースインスタンスの話でしたけどこれは分散環境でどうなるかっていうのは今後また出てくるんでこれも楽しみですね
楽しみです
2フェーズコミット3フェーズコミットとかスパナーとかいろいろ出てくるんで
はい
うん徐々に勉強していきたいですね
ですねうんまあこのペースはいいかもねじゃあ今日はこれぐらいにしましょうか
はい
はいということでDDI本第7章トランザクション章の振り返り会でした次回は第8章トラブルウィズディスビューティッドシステムということで次回も楽しみにしててくださいじゃあお疲れ様
ありがとうございました
