テッペイの自己紹介
ken
はい、リスナーのみなさん、こんにちは。London Tech TalkのKen Wakatsumaです。
本日は、Bookclub第3章の振り返り収録をしていこうと思います。
お気づきの方もいらっしゃると思うんですが、第1回、第2回目の振り返り収録は、ちょっとソロで収録したんですけど、今回、3章はゲストをお呼びして収録していこうと思ってます。
今日はゲストに、テッペイさんをお呼びしてます。テッペイさん、ようこそ。
Teppei Iwaoka
よろしくお願いします。テッペイです。
ken
いや、昔からね、聞いてくれてるリスナーの方からしたらね、もうお馴染みのテッペイさんだと思うんですけど、
実は今日がテッペイさんゲスト収録10回目の記念出演という、すごいね、10回。
10回もいろいろ話させていただきましたね、ありがたい。
前回の、ちょっと見てみたら、なんかDiscordとかBookclubでよく話すんだけど、ゲスト収録的には前回が2024年の5月なので、
多分最近聞いてくれたリスナーの方もいらっしゃると思うから、改めて自己紹介をお願いしようかなと思います。
お願いしてもいいですか?
Teppei Iwaoka
はい。改めまして、テッペイ岩岡と申します。
今は大阪に住みながら、ロンドンの本社の会社にリモートで勤めていて、主にバックエンドの開発に携わってます。
あと、ちょっと過去の回でもお話しさせていただいたんですけど、大学院にも通ってて、そこでコンピューターサイエンスの勉強をしたりもしています。
今日はよろしくお願いします。
データベースの授業について
ken
ありがとうございます。
ありがとうございます。そうなんだよね。初回ゲスト来てくれた時が、テッペイさんのキャリア編ということで、新卒未経験からソフトエンジニーになった話とか、ジョージア高科、テック高科大学の話とかしてくれて、
それからずっとゆるくコミュニティに携わってくれて。
Teppei Iwaoka
一番はあれですかね、ブッククラブ、多分全部出させていただいてるんで、そこで一番濃く関わらせていただいてるかなと思います。
ken
最近どうですか?大学院の方は順調に進んでる?
Teppei Iwaoka
そうですね、今がちょうど6個目の授業を受けてて、10個終わったら卒業って感じなので、やっと半分折り返し地点に来たかな、折り返し地点を超えたかなって感じですね。
ken
頑張ってるね。最近直近はどんなの受けてたんだっけ?
Teppei Iwaoka
そうですね、今回このDD、データベースの話の輪読会やってると思うんですけど、まさにそれと関わるデータベースの内部実装を学ぶような授業をやってて、丸かぶりな感じですね。
ken
すごい、それは内容とかはもうどんな感じ?この本と割と、この本が共生で使われてるとかではない?
Teppei Iwaoka
ではないですね、そういう意味では丸かぶりではないんですけど、割と扱っている内容もかぶってるところもあって、例えばスロットイットページとかも実は授業でも扱われてたりとかして、
今日もちょっと話すスロットイットページが前回の輪読会のメインのテーマだったりとか、
いいね。
だったりするんで、はい、すごいかぶってますね。
ken
いいね。その授業を受けてみようと思ったきっかけとか何かあったんですか?結構データベースのインターナルに深掘ってくって、好き嫌い分かれるところかなと思って、
CSの収支受けててもOSとかネットワーク側に行く人もいればデータベース、それともやらなきゃいけないのかな、分かんないけど、
Teppei Iwaoka
テッペさんのモチベーションみたいなの聞いてみたい。
そうですね、全然必須とかじゃなくて、自分が受けたくて興味関心を持って受け始めた時期があるんですけど、
今まで体系的にデータベースについて学んだことがなかったので、何かそういうものを一度受けてみたいなっていうのはあったんですけど、
今ある既存の授業がデータベースの扱い方に関する授業で、それは結構普段の業務でもやる内容だったりとか、あとちょっと評判が良くなかったりとかもあって避けてたんですけど、
今期からちょうど新しく内部実装の授業が追加されて、そういう面白そうな授業が入ったから受けてみようかなっていうところなんですけど、
なんか具体的にこういう風な課題があるから、それを学ぶために授業を取るとかっていうよりは、ざっくり今後データベースの選定であったりとか、
そういう機会があった時に、ある程度の土台があった上で話ができるようになれたらいいなみたいな、ちょっとふわっとというかざっくりした動機ではあるんですけど、思って受け始めましたね。
ken
いいね。評判が悪かった方のは、例えばデータベースを使う側だからSQLの話とか、インナージョインとか、内部設計、テーブル設計の話とか、そういうモデリングの話が多い系の授業ってことかな。
モチベーションとタイムマネジメント
Teppei Iwaoka
そうだと思いますね。ちょっと受けてないので詳しくは分からないですけど、そういう内容かなという風に理解してます。
ken
SQLアンチパターンとかね。確かに業務で結構やってるところはあるかもしれないよね。
Teppei Iwaoka
そうですね。
ken
そっかそっか。いいじゃないですか。なるほどね。
なんかその、出される課題とかもう分かってるんですか?中間とか。
Teppei Iwaoka
そうですね。テストが2回あるのと、あとはそのプログラミングの課題が4つぐらいあるって感じですね。
ken
それは何を書くのか分かる?
Teppei Iwaoka
そうですね。今もう2つまで終わってて、1つ目はC++で実装していく授業なので、そこの軽くおさらいみたいな前提知識を揃えるための課題が出て、そこでまずデータベースって感じじゃないですか、データのちょっとした出し入れをするみたいなことを簡単にやった後に、
今回その2つ目の課題を出し終えたところなんですけど、その内容は2Qポリシーってあるじゃないですか。
ken
Qを2つ持っておくやつ。
そうですね。
BotとColdみたいな感じだっけ。
Teppei Iwaoka
そうですね。だから基本的にそのデータをディスクに書くけど、それだとその読み取りとか遅くなったりするんで、データをキャッシュしておく、メモリにキャッシュしておくっていうことがあるんですけど、
メモリに全てのデータを持つことはできないので、どのデータをメモリに持っておいて、いつ、どういうものを取り出して新しいものを入れるのかっていうのを管理するための戦略みたいな、なんですけど、それを実装するっていう課題でしたね。
ken
その話もさ、この本のどっかで出てきた気がするんだよね。
2Qポリシー自体が出てきたかわかんないんだけど、多分そのキャッシュの話が、いろいろブッククラブで3回目やったり、自分では5回目読んだり、あっちこっち言ってるから忘れちゃったんだけど。
確かその、第5章かな、結構キャッシングの話が出てきた気がするんだよね。
Teppei Iwaoka
じゃあもしかしたらかぶってるかもしれないですね。
一応2Qポリシー自体を単語で調べてみたんですけど、それだときっかからなかったんで、これ扱われてないんだなと思ったんですけど、その広い意味ではもしかしたら重なる部分があるかもしれないですね。
ken
そうだね、この本では2Qポリシーっていうよりは別のLFUとかTinyLFUとかあとはボスグレで使われてるキャッシングアルゴリズムだった気がするけど。
そっかそっか、いや楽しそうですね。
Teppei Iwaoka
結構面白い実装でしたね。
ken
なんかそのちょっとステップバックしてみると、半分折り返してみて、今のそのモチベーション維持とか、あとはその習慣化とかっていう観点で言うとどうですか?
仕事とずっと一緒にやってるわけじゃないですか。
Teppei Iwaoka
そうですね。
ken
時間を割いてね。
Teppei Iwaoka
はい、そうですね。
習慣化っていう意味だと、結構なんかいいふうに作用しているなっていう気はしてて、
なんか定期的に何かを勉強して、深い理解を身につけるみたいなことをする習慣ができたな。
土日とかに必ず勉強するみたいなことは、なんか今までならあんまりできてなかったことが少しずつ当たり前のようにできるようになってきたのは一ついいことかなと思いつつ、
若干なんかこう大学院で学ぶことに対する迷いみたいなのも出てきてはいますね。
別にやめようとか思ってないんですけど、ちょっとたまになんで学んでるんだっけみたいなことに立ち返ることはあって、
例えばなんですけど。
ken
例えば、例えば。
Teppei Iwaoka
業務でポストグレを使ってて、その使い方をある程度理解しているけど、内部実装についてはわからないっていう状況で、
内部実装を学ぶこと自体は多分どこかしらで生きてくるかもしれないんですけど、
今すぐにこの明日の業務に何か活かせるかっていうと、ちょっとクエスチョンだったりもする部分もあって、
ken
そうだね。
Teppei Iwaoka
なので、もともと深くCSを学びたいっていうのと、
あとアメリカに移住したいかもしれなくて、その時にビザに有効になるかもしれないっていう2つの軸でちょっと考えてたんですけど、
ken
そうだったよね。
Teppei Iwaoka
なんかこの2つ目のところがちょっと今あんまり考えてなくなってきたんで、
最初の深く学ぶっていうとこ1つになってきた時に、
その深く学んだことでどういう利益が得られるんだろうかっていうことは、費用対効果みたいなことはちょっと考えたりはしますけど、
ken
そうですよね。
いや、1回基礎を学んどくのは良いことだという、
インジェネラル言われるとはいえ、そこは迷いますよね。
じゃあいつ生きてくるの?みたいな感じですかね。
そうですね。
結構周りの新人エンジニアと話してても、
いや俺これ10年前に大学でやったけど全く覚えてないよとかよくなんか口に出てくるけどね。
そうですね。
実際に1回やっておけば、じゃあ2回目忘れててもキャッチアップするとすぐ思い出しやすくなるとか。
はいはいはい。
あとは、でもあとやっぱり自分がやってる業務とはちょっと違う別のドメインのものを持ち込むことで成果出せたりとか、
イノベーションとかもそうだけれども、研究とかもなんかなんだろうね、
ソーシャルサイエンスの概念をちょっとサイエンスに持ち込んでみたり、またその逆をしてみたり行ったり来たりすることで、
何かその他の人に出せない価値を出すという意味で言うと、業務で学ばないことをやっておくことにも価値はあるけど、
じゃあそれをね、モチベーション維持だけにするのは結構厳しいよね。
Teppei Iwaoka
そうですね。
ken
ゴールも見えてきたから難しいよね、よりね。
Teppei Iwaoka
そうですね、はい。
ただただ結構これまで受けてきたのが、例えばセキュリティの話であったりとか、
あと何でしょう、今データベース受けてて、あとOSの話をやって、
結構こう基礎的、土台になっているような話ばっかりをやってると思ってて、
なので、どの分野の話になったとしても、ある程度自分の中でマップがモテてるというか、
みたいな状況にはなりつつあるので、これはすごいありがたいというか、
あまりこう議論する際にも物応じせずに取り組んでいけるかなっていうのは一つメリットとして感じてますね。
ken
確かにそうだね、こう全体感というか全体像を知っておくことで、
細かいテクノロジーはその都度キャッチアップしなきゃいけないけど、
これがどのエリアのこのことを指してるんだねとか、その難しさもわかるよね、なんとなくね。
Teppei Iwaoka
そうですね、そうですね。
ken
そうだよね、確かにそれは間違いない。
そっか、じゃあ後半戦だね、ぜひ頑張ってほしい。
はい、頑張ります。
僕本当にいつもね不思議だったんだけど、大学院もしながら仕事もねちゃんとやりながら、
よくうちのブッククラブも参加してくれてるなと思って、タイムマネジメントどうやってるんですか?
Teppei Iwaoka
マネジメント、気合いですかね、いや本当に。
なんかあんまり他のことをしてないと思います。
ken
逆にね、集中、選択と集中。
Teppei Iwaoka
そうですね、だから自分の趣味とか、あんまりそういうのがないからこそ、
すべての時間はそこに費やせるというか、
基本だからその仕事してるか、大学院の課題やってるか、
ブッククラブの本を読んでたりまとめたりしてるか、
後、死っていうならジムに行ってるぐらいで、本当そういう人生に今なってるので、
あとあれですね、子供とかできたらまたいろいろ、
全然時間の使い方変わってくると思うんですけど、
その時点でほぼすべてをそこに使ってるんで、
あんまりマネジメントっていうようなことをあんまり意識しなくても何とかなってるって感じかもしれないですね。
データレイアウトの重要性
ken
素晴らしいですね、めちゃくちゃ貯金してますね、知識をね。
そうですね。
絶対30代で生きてくるよ、それが本当に。
Teppei Iwaoka
本当ですか。
ken
貯金できるうちに貯金しておいた方がいい。
Teppei Iwaoka
でも、さっきの話の通り、ちょっとずつ土台ができつつあるかなっていう気持ちはあるので、感覚はあるので、
いつかこれが生きることを願って、頑張ります。
ken
間違いなく生きてくると思う。
今回、てっぺいさんをお呼びした理由はいくつかあるんだけれども、
今回はですね、第1回目、第2回目の振り返り収録でもやったように、
タイムゾーンをローリングというか、
最初はAPACとEMEA、次はEMEAとノースアメリカ、
次はノースアメリカとAPACみたいに3分の2ずつ動かしてやってるんですけども、
僕がAPACとノースアメリカの時に出れないから、
てっぺいさんにAPACリーダーという形でファシリテーションをお願いしてたんですね。
今回の3回目はちょうどノースアメリカとAPACだったから、
僕が出れなかったんですよ。
なので、てっぺいさんにお願いしてたので、
当日の雰囲気とかもね、
僕一人じゃちょっとわからないから、
ぜひてっぺいさんに当日の雰囲気などを踏まえつつ、
チャプター3の振り返りを一緒にできたらいいかなとは思ってました。
ざっくりブッククラブに入る前に、
今度チャプター3まで、
どうしようかな、
チャプター3の話に入る前に、
今回ブッククラブやり始めて、
チャプター1、2、3、もしかしたら今読んでるかもしれないけど、
この本についてざっくりとした感想を聞いてみたいなと思っていて、
思ったより難しかったとか、
思ったより授業との親和性なかったなとか、
Teppei Iwaoka
そうですね。
ken
思ったより薄いなとか。
Teppei Iwaoka
まず、読みやすいか読みにくいかで言うと、
結構読みにくいっていうか、
何回だなって感じはしてて、
毎章毎章、何回も何回も読んでやっとわかるみたいな感じですね。
なので、すごい苦労はしてるかなって感じですね。
ただ、さっきの話にもちょっとつながるんですけど、
ちょっと授業と本を読むのと並行していることもあって、
授業で聞いた内容が本に出てきて、
こういうことだったんだとか、
本で読んだ内容が授業に出てきて、
こういうことだったみたいな、
そういう相乗効果みたいなのもあって、
今のところはすごく体系的に着実に
知識を積み重ねられていっているなっていう感覚はあるんですけど、
一人で読んでると、
スロットページとデータ構造
Teppei Iwaoka
多分もう3章の時点で僕やめてると思います。
スロットルページのところで。
ken
やめてると思います。
最初読んだ時、第2章か第3章でやめた気がする。
Teppei Iwaoka
でもそうなりますよね。
ken
てっぺー流読み方はどんな感じなのかな。
例えば、じゃあチャプター3を読みました。
そこに新しいキーワードが全部出てくるよね。
それを一つ一つ全部理解しようとするのか、
自分で結構、じゃあ今回はこれを理解するってピックしてやるのかとか、
あとは読む時に合わせて、
例えば動画でより理解するようにするとか、
あとはそこのリファレンスがある論文を読みに行くとか、
今まで読んできててっぺー流自分なりの読み方っていうのはパターン化してきました?
Teppei Iwaoka
そうですね。
今までは結構全てを理解しようとしてたんですけど、
結構それは時間もかかるし、
結局なんか最終的に何も理解できて、
何も自分に残ってないみたいな、
分かったようで何も残ってないみたいなことが多かったんで、
今回からちょっと工夫してみた点というか、
まずこの章のメインのポイントって何なんだろうかっていうことを考えるところで、
そこでいつもけんさんの読書ノートを参考にさせていただいてて、
あそこでここで大事な、この章で大事なことはこれでここ押さえておきましょうみたいなこと書いてくれてることが多いので、
ken
まずそこを読みますね。
Teppei Iwaoka
で、こういう内容なのかな、ざっくりメインどころをイメージした上で、
まず読んでみて、
で、そのメインのところをまず理解しようとするっていうところがまず一つありますね。
で、それをすることで何かこう、一回想定してから読むんで、
何かただザーって読んでいくよりも入りが深いかなっていうところと、
あとは読書ノートですね。
やっぱりその読んでいく中でここポイントかな、ここポイントかなってところを、
もう全然まとまってないじゃないですけど、メモだけしていって、
そこを読書ノートに書くときに、
ちゃんと理解しようと何度も読み直すみたいな、
それとある程度何個かのポイントについてはちゃんと理解できた状態で、
輪読会を迎えられるみたいな状態になりつつあるかなって感じてますね。
ken
なるほど、最初に全体感をつかんで、
じゃあここのポイントは何だろう、キーワードは何だろうってのを理解して、
で、読み始めて、それに合わせて自分の理解度に合わせて、
追加で動画見たりペーパーとか見たりしながら、
本を何回も読んで理解しようと。
確かにね。そうなんですよね。
この本を書いたカサンドラのコミッターの人も、
あらすじかどっかで言ってたけど、
彼自身がデータベースを実装するために、
いろんな論文とか参照実装を読んで、
キーワードを頑張ってまとめて書いてるんですけど、
例えば、論文3,4本で参照コード数千行ぐらいのものを、
2ページぐらいでペラッと書いちゃってるんで、
この本読むだけで分かりようがないんですよね。
いくつかのキーワードについては。
だから、てっぺさんもそうだし、
他の参加者の方も書いてくれていいなと思ってるのは、
この章のここは自分には今回スキップしようかなとか、
あとここよく分かんないなみたいな、
分からない、もしくは自分にとって今必要ない、
もしくはスキップするみたいなのと、
あとは逆にここは分かる、分かりたい。
例えば、今回はビッグエンディアン、
リトルエンディアンの話に出てきたけど、
ここはちゃんと理解しようとか、
理解したいキーワードとスキップするキーワード、
明確に分けてちゃんとやるとこやる、
みたいな読み方してる人も何人かいて、
それすごいいいなと思ったんですよね。
今の自分の理解とかに合わせながら。
あとその、どうぞどうぞ。
Teppei Iwaoka
自分でピックアップしたのが、
例えば全体のうちの50%だとしても、
他の方のピックアップしてきたものが、
必ずしもそれとイコールではないと思うので、もちろん。
別のところをカバーされてて、
その別の方の話聞いてたら、
それそういうことだったんだ、みたいなの。
理解を受けて、
例えば50%だったのが70%になったり80%になったり、
みたいなこともあるんで、
そういうのもすごいクラブで恩恵を受けてるなと思いますね。
ken
なんか4回目になると結構パターンとか、
いい回し方とかも見えてきて、
すごいいいなと思って。
あとその、何だろう、
読書メモの書き方はどんな考えというか、
どんなことを気をつけて書いてるのかなと、
もう一回聞いてみたくて、
例えばその読書メモって、
人によっていろんな書き方があると思うんですよね。
例えばサマリーを書くタイプ、
そのTLDRとか、
この本をサマリ、この章をサマリました、
みたいな書くタイプもいれば、
あと自分が読んだ順に、
自分の考えをアウトプットしながら、
オーガナイズする意味で、
読んだ順にバーって書く人もいれば、
あとはその、
自分がピックしたキーワードについて深掘りするタイプもいれば、
あとは何だろうな、
外部のリソースを持ってきて、
それについて紹介するとか、
あとは自分の業務と紐付けたりみたいなのありますけど、
てっぺさんはどういう書き方をしているか、
もう一回ちょっと聞いてみたいな。
Teppei Iwaoka
そうですね、
自分は説明しやすい書き方に今は書いてます。
説明しやすい。
この章の重要なポイントはここで、
その重要なポイントは何なのか、
みたいなことが伝わりやすくできるだけ書こうとはしてて、
これもちょっと前の反省で、
今までは結構気になったこと全部書いて、
その内容すべて読書ノートにも移してたんですけど、
そうなると、
実はその読書ノートを通して何が言いたいのかっていうのが全然まとまらないので、
読書ノートをシェアするときに、
これはわかりました、これわかりましたって一個一個言ってても、
あんまり伝わりづらいなって感じたので、
この章のメインはこれだから、
このメインはこういうふうになってますぐらいは、
ちゃんと説明しやすいように書いてるといいなって感じたので、
最近はそこを意識するようにしてますね。
ken
なるほど。
自分の言葉でリフレージングするじゃないですけども、
自分の理解という自分の脳みそというフィルターを通して、
他の人に説明しやすいように言い換えることで、
理解はもう確かめることもできるし、
後で読み直したときに本当に理解してるかどうかも、
見直すことができるみたいな感じかな。
Teppei Iwaoka
そうですね、はい。
ken
いいですね、いいですね。
なんかいつも僕も大抵てっぺいさんの読書ノートとか読んで、
自分の理解の重箱の罪をつついたりとか、
過ちをここ間違ってたなとかってこっそり書き直したりとかもするんだけど、
そうかそうか。
じゃあチャプター3の内容に入っていこうかな。
じゃあ今回のチャプター3はさっきからキーワードもいくつか出てるけれども、
大きく言うと3つなのかな、
ちょっとコレクトしてほしいんだけど、
僕まず基本的にここのサマリーとしては、
データをディスク上に格納するときにどういうバイナリーのレイアウトがいいのか、
それをなぜ気にしなきゃいけないのかっていうのを前提として書かれていて、
その大大大前提となる話として、
エンディアン、ビッグエンディアンとかリトルエンディアンみたいな話があるんだよねっていうのとか、
あとはそのページっていうのは何キロバイトのブロックでとかっていうのを話した前提を抑えた上で、
2つ目のキーワードとしてスロットページというか、
1つ重要なデータ構造について紹介されていて、
ディスク上で効率化を上げるためにはスロットページのような、
これも一例だけれどもデータ構造を使うと、
より効率的にデータをレイアウトとして保存できるよっていうふうなものがありました。
3つ目には、そういってディスクを上にバイナリーのレイアウトとして、
自分たちが決めたフォーマット、インターフェースで保存するときには、
いろんなことを気にしなくちゃいけないですよね。
例えばレイアウトのバージョニングどうするんですか、
バージョンが変わったときどうやって検知したり比較したりするんですかみたいなバージョニングの話もちらっと触れられていたり、
バージョニングとチェックサム
ken
あとデータをディスクに保存して読み出すので、
ディスクが壊れたりとかノードがクラッシュしたりときに、
バイナリーがコラップと壊れてしまうことがあると思うんですけど、
それはチェックサムを使うことでより効率的に簡単に比較できますよね、
みたいな派生トピックについて書かれていたかなと思うんですけども、
第シャプター3のテペさんの振り返りとしては、
キーワードとかまさまりでもいいですし、気になったところとかありますか。
Teppei Iwaoka
そうですね、自分の中では3つ大きく引っかかったところというか大事にしているところがあって、
まず1つ目が導入の部分で、
一番最初に説明されていた内容として、
メモリーってバーチャルメモリーがあるおかげで、
ポインターを使ってデータにアクセスできるので、
実際の物理的なアドレスが何なのかということは、
管理しなくても簡単にデータを扱うことができるけど、
ディスク上に管理されているデータっていうのは、
そういう便利なものがないから、
あるデータを取りたいときは、
どの位置にあるのかみたいなことをちゃんと意識しなければ取得できない、
っていうところが導入にあって、
だからこそデータを取得しやすかったり、
操作しやすいフォーマットっていうのが大事なんだよっていうことを説明してくれたのかなと思ってて、
まずそこの導入が大事かなって感じたのと、
あと次にページっていうところが出てきて、
そのページっていうのは順番にデータを詰めていくだけっていう内容だけど、
それだとデータを削除したときに、
じゃあその削除したデータを、
削除されたスペースを埋めるためにデータを移動させなければならないっていう非効率性であったりとか、
あとその可変調のデータを扱おうとすると難しいとかっていう課題、
簡単に考えるとページっていうところがあるけど、
そこにはいくつかの課題がありますっていうところが説明されたのが2つ目のポイントかなと思ってて、
じゃあそれを解決するためにはスロットイットページっていうのがあって、
データの位置とかをいちいち意識しなくてもスロットっていうところで、
実際のデータに対するポイントを持ってるんで、
それによってデータへのアクセスをしやすくして、
いろんな課題、さっき言ったような課題が解決されますよみたいなところが、
自分の中での3本柱かなっていうふうに感じてて、
データベースの実装と理解
Teppei Iwaoka
さっき言ってくれたようなチェックサムとかそういうところも付随していくつかあるかなと思うんですけど、
自分のメインのところはそこでしたね。
ken
確かに、その3つのまとめ方綺麗ですね。
そうなんですよ。この章から一気にChapter2とB3の話した後で、
データベースの実装のメンタルモデルを前提として話し入ってっちゃうんですよね。
ガクッと深掘りしていく。
まずそもそもメモリとディスクの違いを意識して読まないと迷子になっちゃいますよね。
テペさんが一つ目に言ってたポイント。
二つ目に言ってたページも、
そもそもページってデータベースマネジメントシステムの中で何ですかっていう、
ディスク上のデータ保存するブロックなんだけども、
そこも紐付けられてないと一気に迷子になってしまうポイントなんですよね。
だから、結構個人的には第2章と第3章のギャップというのは大きいなと思っていて、
ここで迷子になる、僕は最初そうだったんですけど、
人が多いかなと思うので、
ぜひ第2章か第3章のギャップっていうのを意識して読んでもらいたいなと思いますね。
現実世界でデータベースを作るという意味では、
スローテッドページなりいろんなデータ構造が必要なんだよっていうところまでたどり着ければいいんですけども、
でもその前にテペさんが言ってくれた一つ目と二つ目の観点。
基本の基本ですよね。
そこが理解できればもういいんじゃないかな。
合格点はいってるんじゃないかなとは思いますね。
別にスローテッドページが分からなくても、
エンディアの話しっかり、メモリとディスクの違い、VMの話しっかりとかが理解できれば、
第4章まで続いていけるんじゃないかなと思いますね。
ディスカッションと学びの共有
ken
実際のその当日の雰囲気っていうのもぜひちょっと聞いてみたくて、
アシステーション丸投げしちゃったんですけど。
どうでした?
Teppei Iwaoka
本当に参加者の皆さんが結構発言してくださったことで、
結構いい学びの場になったんじゃないかなって個人的には思ってて、
例えばなんですけど、ある参加者の方が質問してくださって、
そこに対して回答があって、
それを聞いていた別の方がその説明を聞いてて、
理解できるようになりましたみたいなコメントをくださったりとか、
自分もその方の、分かりましたって言ってくださった方の説明を聞いて、
ある部分が分かるようになったとか、
そういうのがちらほらあったので、
そういう議論の中からそういうのが生まれてるのがすごいいいなと思ってて、
みんなで地を寄せ集めて、
一つのより大きな地につながっていくような感じかなって思ってます。
ken
集合地じゃないけどね。
Teppei Iwaoka
集合地、はい。
ken
3人よればね、文字の地へじゃないけど。
めちゃくちゃいいですよね。
やっぱりもう2回目とか3回目の参加者の方も増えてきてるし、
お互いの顔知ってるよみたいな人も結構増えてきたので、
なんか発言しやすい雰囲気というのも徐々にできているんじゃないかなとは思ってますし、
なんかいいですよね。
Teppei Iwaoka
でもとはいえ、初めましての方もいらっしゃったみたいで、
そういう新しい繋がりがまだ増えていくのもそれはそれで嬉しかったことですね。
それ自身もちょっと今回の、今回についてはなかったんですけど、
前回初めてヨーロッパのタイムゾーンの方と初めましてになったりとか、
そういう繋がりが増えていくのも一つの魅力ではありますよね。
ken
確かに確かに。
それは僕も何回か見てめっちゃいいなと思って、
なんか今までエピソードは聞いてましたけど、
初めて話しますみたいな感じで。
すごい。
今回はあとはあれかな、ディスカッションポイントもてっぺいさんが2つ挙げてくれまして、
1つ目が第3章の内容で実際の開発に生かしそうなポイントはありましたかみたいなところと、
2つ目はそこ出てきたチェックサブを実際に活用した経験はありますかみたいなところで、
そのディスカッションポイントのどんな感じで議論が済んだかなというのを聞いてみたいんですけど、
なんかこの章から自分の業務でこういうことがありましたみたいなのを絡みつつコメントしてくれる人も多かったかなと思って、
1人の参加者の方がPOSグレを使っていて、
そこで過去に出た障害のことについてコメントしてくれて、
それでスレッドで盛り上がったりとかしましたけれども、
ディスカッションポイントを踏まえつつ、
実際の開発に生かしそうなポイントとの絡みでいうとてっぺいさんは、
どんな学びがあったもしくはなかったかっていうのを聞いてみてもいいですか。
Teppei Iwaoka
そうですね。
このディスカッションポイントを挙げさせていただいた背景として、
個人的にはどうやって活かそうかなってちょっと迷ってたからこそ、
他の方の意見を聞いてみたいなみたいなところがあって挙げたっていうのもあるんですけど、
結構絞り出すと、一つはページっていう概念を理解したからこそ、
それがどういうふうに動くかっていうことを理解したからこそ、
今後そのページっていうのを構成するもののサイズっていうのも設定として持ってて、
それを設定変更できるんだなっていうのを理解したんですけど、
今後そのデータベースを選定するとか、ちょっとパフォーマンスを改善するとかってなった時に、
もしかしたらこのデータの特性上、もうちょっと大きくした方がいいとか、
もうちょっと小さくした方がより効率的になるんじゃないかみたいなことは、
一つ考えられるようになったのかなっていうのがまず一つと、
あと直接すぐに活かせるかどうかわかんないですけど、
なんかこうドキュメント、
自分基本的にはポスグレを使うことが多いんですけど、
ドキュメントを読んでてあんまり理解しきれないっていうか、
明確に書かれてないかもっていう時に、
実際の行動を見に行くっていうことも今ならできそうかなって思ってて、
今回もスロッティッドページの実装があったので、
それを見てたりしたんですけど、
それを見た時に今までだったら何書いてるのか全然わからんっていう感じだったと思うんですけど、
ある程度ハイレベルな理解があるからこそ、
実装を見に行ってこここうなってるんだみたいなことも、
わかるかもしれないなっていうところですかね。
ken
そうだよね。
その二つ目のポイントも特に僕も話そうと思ってたんだけど、
今回ポスグレの実装をいくつか見てみて、
具体的なイメージは来ましたってテッペイさんもコメントしてくれてて、
スロットページのデータ構造とかチェックサムの実装を見てくれてて、
こういうのめちゃくちゃいいなと思ったんですよね。
何だろう、業務に使えるかどうか、
さっきの大学院のところでも基本的な学習は業務にどれくらい来てくるのかみたいな話がありましたけれども、
なんか業務で使ってるシステムのソースコードを見に行くってすごいいいことだなと思ってて、
さっき言ったようにどういうメトリックスとかどういう設定ができるのか、
ページのサイズとかできるのかって理解するのもそうなんだけど、
いざ何かあったときにそれがバグなのかどうなのかっていうのを見に行くスキルだと思うんですよね。
ソースコードのレイアウトとか、
あとどのパッケージにどの実装が書かれてるかっていうのをやっぱ知ってるか知らないだけで結構すぐ障害ポイント発生したりとか、
あとはそもそも自分が何を読んでるかも知らない状態よりはソースコードが、
例えばチェックサムの実装がどこに入ってるかっていうのも雑なグレップじゃなくてちゃんと取りに行けるというか、
あとPOSGLEって結構オフィシャルドックスって意外と何も書いてないんですよね。
書いてるんだけど、コンフィグレーションとかに関してはね、
POSGLEのソースコードのREADMEとかソースコードコメントの方が、
いろいろ実装上の細かいところがいろいろ書いてるので、
そっちを取りに行くっていうのは一つ差別化ポイントにもなるし、
業務でも中小企業では生きてくるんじゃないかなと思ってて。
だからソースコードにリンク貼っててめっちゃいいなと思って。
見てる見てると思って。
Teppei Iwaoka
結構細かく書いてくれてますよね。
ドックストリングというか、コード内の説明にめちゃくちゃ行数を割いてて、
ちょっとそこに感動したので共有させていただきました。
ken
そうなんですよね。
POSGLE実装結構難しいというかね、ジャイガンティックなソースコードだから、
でも自分の知ってるキーワードを紐元につまみ食い今しとくだけで、
5年後10年後全然違うと思うので、
ぜひこれは習慣化してほしいなと思いますね。
Teppei Iwaoka
習慣化していきたいですね。
でもその時結構気持ちの問題もあったんですけど、
読むこと自体にすごい壁を感じていたというか。
一回見始めると意外とわかるんだなっていうのがあるので、
今後他にも近い似たような実装の中身を見たいみたいなことがあった時にも
見に行けるメンタルのちょっと変化も感じますね。
ken
いいね。バリアを取っ払ったね。
Teppei Iwaoka
そうですね。
ken
素晴らしい。いいな嬉しいな。
そういう人が一人でもたくさん増えるといいな。
だからまずは本読んでキーワード知って、
キーワード知っとくとソースコードのドックストリングとか見に行った時に、
この話してるんだなっていうのがまずコネクティングだとできるというかひも付くよね。
そうやってコメントを読むことで、
次にどこに何が実装されてるのかっていうのが見えてくると思うんですよ。
例えばNBツリーみたいなポスグレにパッケージがありますけど、
ノンバランスツリーの実装とデータ構造
ken
これはノンバランスツリーの実装でBツリー関連がここに書かれてるんだなとか、
そのパッケージごとに何の実装がされてるか分かって、
さらにその次の段階としては、
例えば本書とか記事とかに書かれていたロジックが、
ここのメソッドで実現されてるんだなみたいな、
ポインターの写し替えであったり、
マージ、ツリーのマージなんちゃってあったりとか、
そういったものがここに書かれてるんだなみたいなのを、
メソッド単位で理解しておくとたぶん楽しいと思うんで。
ここに書いてるな。
Teppei Iwaoka
今話してて気づいたというかなんですけど、
やっぱりこういう具体的なところに見に行けるようになるためにも、
ある程度のざっくりした、
例えばスロットイットページって何なんだろうみたいな、
理解がないと見てもさっぱりって感じになっちゃいそうだなと思ってて、
だからこそハイレベルなある程度の理解を、
すぐに行けるか分かんないけど、
いろんなところに貼っておくことで、
今後そういうことがあった時に詳しく見に行けるような状態になっておく、
みたいなことは、
さっきの最初の話に戻りますけど、
これが必要なのかどうか迷いましたけど、
結構必要なのかもってちょっと今気づいたというか、
改めて思いますね。
ken
そうだね。
データベース選定の留意点
ken
あとは昔僕がバックエンドエンジニアだったことを振り返りつつなんですけど、
データベースにちょっと興味があるバックエンドエンジニア、
てっぺいさんみたいな方に一つ、
これも意識してみるといいんじゃないかなと思うのは、
例えばデータベースの選定をするときに、
今いろいろありますよね、データベースって。
Google Spannerがあったりね、
AWSのAuroraもあったり、
コクロウチDBみたいなのも出てきたりとか、
VectorDBという中でいろいろ出てきたり、
Pineconeとか出てきたりしますし、
オフィシャルページを見に行くと、
僕らのデータベースはこれがすごいんだよみたいな感じで、
結構ジャーゴンが散りばめられているというか、
こういう合意形成アルゴリズムを使っているから、
他よりコンシスタンシーが高いんだよとか、
こういうLSMツリーを使っているから、
ライトのパフォーマンスが出るんだよみたいな、
結構ブラグしていたり自慢していたり、
オフィシャルページを書いているわけですよね。
でもこういったベースの知識が分かると、
大したこと言っていないなというのが分かると思うんですよ。
例えば、どこのデータベースか言いませんけど、
ここのデータベースでライトのパフォーマンスを上げるために
LSMツリーを使っているから速いんだよとか書いていますけど、
でもそれって他の、
これは次の次の次の章くらい読んでいくと多分出てくるキーワードなんですけど、
これは別にB3とLSMツリーの違いであって、
例えばロックスDBとか他のDBでもやっているから、
ここをブラグしてもしょうがないんじゃないの、
みたいなツッコミであったり、
ここの合意ケースアルゴリズムに自慢しているけど、
内部ではライブラリ使っているだけだよね、
それ他も一瞬使っているよね、みたいなのであったりとかが、
見えてきちゃうんですよね。
見えてくるようになると、
例えばバックエンドエンジニアで新しくシステムを作るとか、
マイグレーションするときにデータベースの評価をすると思うんですけど、
そこが見えてくると楽しいと思いますね。
なんかベンチマークがいいから、
何々DBみんな乗り換えたいってチームメンバー言ってるけど、
でもそれ実装とか内部見に行くと大して違わないよね、
であったりとか。
そうですね。
そうそうそうそう。
Teppei Iwaoka
なんかちょっと話すとれちゃうかもしれませんけど、
前回ですかね、前々回ですかね、
ダトミックですか、何て読むのかな、
ダトミックみたいな名前のものを紹介してくださった方がいて、
でちょっとそれを自分も見てみたっていうのがあったんですけど、
なんかこの内容も改めて振り返ると結構難しいというか、
普通にパッて見てもすぐに理解できない内容かなって思うんですけど、
それが、
例えばDDIAの内容とかも多分、
相まってっていうか、
それの後継もあると思うんですけど、
すっと入ってきたというか、
そこまで理解するのに苦労しなかったなっていうのをちょっと思い出してて、
ken
素晴らしいじゃないですか。
Teppei Iwaoka
そうですね。
だからそれあれですね、
ダトミックって多分、
1回書いたもの全く変えないみたいな考え方だと思うんですけど、
ken
それが多分、
Teppei Iwaoka
DDIで多分そういう考え方を1回入れてるからこそ、
すっと入ってきたというか、
そういうのなしに読んでも何がすごいのか分かんないというか、
って感じたと思うんですよね。
そういうのが一つ一つ分かっていくっていうのは、
すごい感じますし、
大事なことだなっていうふうに思いますね。
ken
そうなんだよね。
いやーめちゃくちゃいい話じゃないですか。
それは積み重ねがなせる技だと思うんで。
Teppei Iwaoka
そうですね。
ken
一つ一つで見ると、
Teppei Iwaoka
そんなにこう何なんだろう、
何が良くなってるんだろうって分かんないかもしれないけど、
後々こういうふうに気づけるんだなっていうのにちょっと今気づいてますね。
ken
そうなんだよね。
間違いない。
結構データベースの勉強してるけど、
これもコメントしたけど、
ネットワークとか、
あと実はフロントエンドのところとかでも、
似たようなデータ構造とかアルゴリズムが使われてたりするんですよね。
それもだから別にデータベースだけのね、
考え方じゃ全然ないものも多いので、
例えばディスク上のライトとかリードを高速化するために、
こういう考え方がありますよねってことでいろんなデータ構造があるけど、
それって例えばメモリが限られたIoTデバイス用のところでも使えるようなアルゴリズムもあったりとか、
あとペイロードサイズを最適化したいネットワークを超えたそのやり取り、
バックエンドとモバイルのクライアントのやり取りのところでも似たようなことが使えたら、
例えばチェックサムの話なんかいろんなところで使われてますけど、
結構応用できたりすると思うんで、
一歩引いてどうやったらこれ応用できるんだろうな、
みたいな読み方も楽しいと思いますね。
Teppei Iwaoka
そうですね。
ken
いいですね。
Teppei Iwaoka
どうかな。
ken
今は第4章読んでる感じかな。
これから読む感じかな。
Teppei Iwaoka
そうですね。読み始めたって感じですね。
ken
楽しみですね、後半。
そうですね。
どんどんどんどんいい意味で難しかったからね。
Teppei Iwaoka
そうですね。
ただやっぱり内容がないようなだけに、
やっぱりちょっとしんどいなっていう時期も来るかなと思うんで、
頑張ってみんなで励まし合いながら、
みんなで進んでいけたらいいなと思いますね。
ken
しんどい。
Teppei Iwaoka
DDIAも何度もくじけそうになったんですけど、
みんなでやったからこそ乗り越えられたみたいなこともあって、
今回も参加させていただきたいなと思ったとこもあって、
それも一つのドッククラブのメリットだと思うんで、
仲間と共に学ぶ楽しさ
Teppei Iwaoka
みんなで助け合いながらやっていきたいなと思いますね。
ken
ほんとそうですね。
しんどいは間違いないんで、
これを聞いている一緒に読んでくれているリスナーの方も、
ゲスト参加者も、これしんどいと思うんで。
しんどいからね、読み切った時楽しいっていうのもあるんで。
あとこの本の構成として個人的に好きなところは、
前半がいわゆる単体のノードのデータベース1台のプロセス、
プロセス1つの実装について深掘りして、
後半ではDistributed Environment、
分散環境のテクニックについて書かれているんで、
まず前半読んで、中間テストじゃないけど、
折り返した感が出るので、
そこはまず前半を乗り切るぞっていう気持ちでね、
途中休憩があるので、チャプター全部14ぐらいあるけど、
チャプター7までかな、が前半だからね。
そこまではじゃあまずやるぞみたいな感じで。
なんかチャプター3関連で、もしくは今回のブッククラブのファシリテーション関連で
Teppei Iwaoka
コメントしておきたいところ何か他にありましたか?
そうですね。
今後も、さっき言ったようにやっぱりつまずくところあると思うんですけど、
みんなで一緒に進んでいけたらなって思っているので、
前回すごい参加者の方の発言に助けられたので、
今後も一緒にやっていけたらなっていうのが思ってますね。
ken
いいですね。
僕も個人的にちょっと意識してやろうと思っているのは、
つまずいた時に読書メモで表現するのもいいんだけど、
もっとディスコードがあるからリアルタイムで呟いていこうかなと思って、
ここ難しいんだよね、みたいな感じで。
読んでいる最中に、読んでいる最中とかブッククラブに参加して、
ここが難しかったっていうのはもう前々回ぐらいから結構雰囲気ができてきたんですけど、
リアルタイムで今読んでいるんだけど、ここはわからない、誰か助けてみたいなのが
もっと僕は作っていけたら、
多分ブッククラブに参加する前の読書メモを作る段階でより理解が進むかなと思ってたりして。
Teppei Iwaoka
確かに。
一緒に読む時間とかもしかしたらあってもいいかもしれないですね。
もくもく会みたいな。
ken
何それ、めっちゃいいじゃないですか。
もくもく会大好き。
タイムゾーンの難しさはあるかもしれないですけどね。
ローカルのAパックもくもく会みたいなのが文化会みたいなのあってもいいよね。
ちょっとやってやって。
考えてみますね。
勝手にね、ボイスチャンネルとかもあるからさ、ディスコードって。
とりあえずフラーっと入って、今から30分読みまーすみたいな。
興味ある人入ってくださいみたいな。
そういうのもいいかもしれないな。やろっかな。
そうですね。
確かに確かに。
Teppei Iwaoka
ちょっと進化していってますね。
ken
ね。
昔それを別のディスコードチャンネルでやったときに全然参加者がいなくてちょっと慣れたっていうことがあるんだけど。
タイミングが合えばね、誰か参加してくれるからな。
ここは。
まあね。
こんなところかな。
ちなみにポスグレを、ちょっと最後にポスグレの話をちょっとして終わりたいと思うんですけど。
業務でポスグレを使ってるということでしたけれども。
なんかその、今の会社に入ってからポスグレになった?
それともずっともうポスグレ使ってる?
Teppei Iwaoka
今の会社に入ってからですね。
前の会社もそうなんで、今と前とですね。
最初の会社はオラクルをメインで使ってたので、全然知らなかったって感じですね。
ken
なんかその、ポスグレ仕草とか感じる瞬間ってありますか?
Teppei Iwaoka
あー。
ken
なんかその。
なんかバキュームが必要でそれでインシデントが起こったとか。
あとはマイシークエルとの違いでちょっとクエリでなんか考えるところがあったとか。
自分が感じたでもいいし、なんか同僚が話してたでもいいし。
Teppei Iwaoka
ちょっと今のところ具体的なとこないんですけど。
なんか今回のショーの内容でもちょっとそのデータベース間で違いがあるんだなって気づいたところとして、
ポスグレのデータベース管理
Teppei Iwaoka
そのスロットイットページの話でデータが削除されて空きができたときに、
それをコンパクションするかどうかっていうところで、
オラクルとかSQLサーバーとかはそこコンパクションするけど、
ポスグレはそれをしなくて定期的なバキュームっていう処理で、
それをそのデータの非効率さをなくしているみたいなことがあるんだなってちょっと知ったんですけど、
ちょっとずつそういう違いに気づき始めてるっていうところで、
この本を読みながらもう少しそういう濃い違いがあるんだなっていうところを気づいていきたいなって感じですね。
現時点では使っててこういうところがポスグレっぽいなとかって気づけるほどまだ理解してないかもしれないです。
ken
ちなみにデータベースってどういう風にチーム構成として管理してるんですか。
例えばそのプロダクトごとにそれぞれクラスターレベルでポスグレを管理してて、
各チームが勝手にテラフォーム使うところもあったり、
コンソールでポチポチボタンでやったりとかしてやってるのか、
大きなエンジニアリングチームみんなでポスグレの大きいものがあって、
そこにみんなでスキママイグレーションしたりテーブル作ったりとかで共有してるのか、
それをマネージする専門のSREであったり、
インフラチームであったり、データベースディライアビリティー、
もしくはデータベースエンジニアみたいなのがいたりとかで言うとどうですか。
Teppei Iwaoka
そうですね、基本的には本当に大きい単位でいくつかプロダクトというレベルがあって、
それが3,4個ぐらいあって、それごとにデータベースが作られているような感じで、
でもその全ては多分自分の理解では全部ポスグレでやってると思うんですよね。
その比較的大きいのにみんなでデータベースのスキマを出したりしながらやっているって感じですね。
それを管理するプラットフォームエンジニアリングのチームがいてって感じですね。
ken
プラットフォームエンジニアリングがその3つ4つをまとめて管理してくれてて。
Teppei Iwaoka
そうですね。
スキマの変更とかはもちろんバックエンドエンジニアが勝手に、
これはポスグレというよりもジャンコ。
Python使ってるんですけど、ジャンコの話なのかもしれないですけど、
マイグレーションファイルとか自動で作ってくるんで、
それをコミットしてマージしたときに自動でスキマが変わるみたいなことを自動的に仕組みとしてなってるんですけど、
そこの部分管理とかはないんですけど、
データベースの複雑さ
Teppei Iwaoka
もうちょっと大きい意味ではプラットフォームエンジニアチームが見てくれてると。
ken
ジャンコのマイグレーションは全然知らないんだけど、
例えばそこでマイグレーションファイル、
Railsみたいな感じかな。
マイグレーションファイルを変えて実行させるじゃない。
例えばそれはバックエンドエンジニアの仕事だと思うんだよね。
新しくテーブルが必要になったとか、
パラメータを変更しますみたいな。
実行させる手段、実行させるワークフローにおいて、
それはバックエンドエンジニアが自律的に最後までできちゃうものなの?
例えばテーブルサイズを気にしてマイグレーションを走らせる時間を気にしたりとか、
それともマイグレーションはプラットフォームエンジニアがやってくれるの?
Teppei Iwaoka
マイグレーションファイルの中にちょっとしたロジックが入って、
それPythonで書かれた、本当のただのPythonファイルなんですけど、
そのロジックがあって、そこにちょっと細かい、
ちょっとした永久にロックされないようにするために何秒間かだけロックして、
それ以降はリリースするみたいなロジックをかけたりとか、
そういうちょっとしたロジックの追加っていうのはバックエンドエンジニアがやってて、
それがマージされた後にどういう仕組みでスキマが変更されていってるのかっていうところは正直理解してないですね。
ken
じゃあいい感じにプラットフォームエンジニアリングの方でカプセル化というか隠蔽してくれてるんだろうね、
その実行のところはね。
Teppei Iwaoka
それがプラットフォームエンジニアリングチームが何かしらを書いてやってくれてるのか、
ken
そういう仕組みがすでにあるのかっていうところはちょっと分かってないんですけど。
その反映されるまでラグはあるよね、でもね。
Teppei Iwaoka
ありますあります。
ken
それはじゃあ翌日気づいたら反映されてたみたいな感じかな。
Teppei Iwaoka
そうですね、もう翌日というか、
マージしたらサークルCIのパイプラインが走って、
それがいろんなことをした上で最後までいって、
それが数十分とかくらいですかね、
経った後に実際のあらゆる環境に適応されてるみたいなイメージで、
だから1時間とかそれぐらい後には反映されてるみたいなイメージですね。
ken
そっかそっか、なるほどね。
大きいテーブルのね、スキーマのマイグレーションとか結構難しいというか、
まあまあ99%ぐらい上手くいくんですけど。
Teppei Iwaoka
そうですね、なんかすごいそこが難しいポイントとしてやっぱ、
ken
一番怖いところがやっぱりスキーマ変更かなって感じで、
Teppei Iwaoka
で、カラムの追加とかは全然大丈夫なんですけど、
削除したりとか変更したりするときに結構問題が起きるんで、
そこを慎重に扱わないといけないなっていうのをすごい感じますね。
ken
そうだよね。
例えばインデックスのさ、
データベースインターナル読んでるとインデックス自体は別のファイルリソースを食う、
ディスクリソースを食う別のなんだろうね、
データ構造だっていうことが理解できるじゃない。
例えばインデックスを雑に作っちゃったりすると、
ディスクのストレージを食っちゃって、
もしくはディスクIOが跳ねちゃって、
他のところで影響が出ちゃったりとか、
あとはプロダクトチームAが、
このインデックスもう使わないから消すねって言って消したら、
すごいタイミングでプロダクトチームBが、
その消そうと思ってたインデックスを使い始める、
新しいコード追加しちゃって、
スロークエリが出てインシデントが起こったりとか、
いろんなパターンがあるからさ。
Teppei Iwaoka
なんかデータベース、
そうですね、データベース扱うのが、
あらゆる問題の原因になってる気がしてて、
だからこそ今回、ちょうど昨日もあったんですよ。
ken
おー、話せる範囲でざっくり聞ける。
すごい、抽象的な感じでいいから。
Teppei Iwaoka
JSONのフィールドがあるんですけど、
そこにキーがいくつかあるっていう、
そのデータを持ってるカラムがあるんですけど、
そのアプリケーションロジック側で、
そこに一つキーを追加したんですね。
そこにはデフォルト値とかも別に設定せずに。
新しく作られていくレコードには、
そのキーが多分追加されるので問題ないんですけど、
古いデータはそのキーを持ってないので、
そのデータをデータベースから引っ張ってきて、
それをディシリアライズするときに、
ken
キーがなくてエラーになるみたいなことが起こって。
Teppei Iwaoka
ほんとやっぱりあらゆる、
自分が経験してきた問題はデータベース絡み、
そういうスキーマを変更したりとか、
そういうところに気にしてるなって感じますね。
ken
なるほどね。
それあれ?
POSグレのJSONカラムタイプを使ってる、
JSONかJSONBを使ってる。
Teppei Iwaoka
そうですね。
ken
そうかそうか、そうなんだよね。
JSON丸っと入れちゃうのって結構、
ほんと嫌いな人は嫌いだし、
そこにスキーマがないから、
嫌いな人はほんと、
禁止してるスタートアップチームとかもあるぐらいだからね、JSON。
Teppei Iwaoka
そうですね。
ken
でも楽なんだけどね。
そこ使うならちゃんと正規化して使えって言って、
正規化に時間をかけすぎて、
でもそのプロダクトが不要になったんで、
その正規化を全部マイグレーションに戻さなきゃいけないとかも地獄だし、
じゃあそこだけ別のドキュメント趣向をデータベースに入れるかっていうと、
別々のデータベース管理しなきゃいけないし、
ラウンドトリップもどっちからも取ってこなきゃいけないし、
そこのジョインどうするのってなるし、
JSONBタイプがPOSグレにあるのはすごいメイクセンスなんだけど、
MVCCとパフォーマンス
ken
でも気にしないとね、
JSONのスキーマの型が違って障害が起きたりとかするからね。
そうですね。
Teppei Iwaoka
今のお話を聞いてちょっと思ったんですけど、
あれってPOSグレの固有というか、
あんまり他のデータベースでは持たない絡むフィールドタイプなんですか?
ken
いや、でもJSONは基本的にバイナリーとしてまるっと入れちゃうこともあるし、
他のデータベースも最近では入れられるように、
入れられないものはないんじゃないかな。
そうですね。
ただ、例えば他にintegerとかbooleanとかstringがあるじゃない?
JSONに入れてるものも結局はそうじゃない?
ストリングとかキーワードとか。
なんでJSONで入れるんだっていう話で、
JSON絡むタイプを使わずに正規化して入れられないのみたいな話。
でもそれする。
でもこれ派閥だからな。
個人的には企業サイズとスタートアップのプロダクトのスピード感によって決めるしかない。
でも別に嫌いとか好きとかじゃないんだけど。
でもJSON Bに複雑な構造を入れるならスキーマはどっかで管理したくて、
その管理手法はどっかで必要だと思うんだけどね。
Teppei Iwaoka
そうですね。
ken
例えばそこだけプロトコルバッファーでバイナリにしたもの入れちゃうとかね、
JSONじゃなくてね、とか。
Teppei Iwaoka
あとJSONスキーマーみたいなの入れてみるとか。
ken
そっかそっか、ポスグレね。
面白いよねポスグレ。
ポスグレの話じゃないけど。
Teppei Iwaoka
でも今みたいにポスグレっぽさ。
ポスグレがあって他にはないとか、他にはあってポスグレがないとか、
ポスグレのちょっと特殊な動きとか、
そういうのもこの輪読会を通して拾っていけたらいいなと思いますね。
ken
ね。
そのバキュームとかも結構、なんだろうね。
そんなにバキュームってあれさ、
そもそもポスグレってMVCCっていう、
もうこの本出てきたかな。
マルチバージョンコンカルシーコントロールっていう仕組みで実装してて、
データに更新があったときに、
例えばすごいナイーブなB3の実装だと、
ライトとかデリートがあった変化があるよね。
それをそのB3をその都度最新の状態にアップデートしなきゃいけないよね。
例えばそのデリートがあったらそのデータを消して、
ノードをマージとかノードスプリットしてみたいな。
で、それが起こりすぎると、
例えばライトヘビーなデータベースワークロードだと、
常にB3をアップデートにしなきゃいけないから、
そこでそのマチが発生したりとか、
あとはパフォーマンスが下がっちゃうので、
例えばそのMVCCっていう仕組みは、
ライトとかデリートが発生したときに、
そのマルチバージョンって言ってるんだけど、
別のバージョンのスナップショットみたいなのを追加で作るんですよね。
だから発想の肝としては、
ライトパスとリードパスを完全に分ける。
具体的にどういうことかというと、
そのデータにライトが入ってきたときに、
そのライトが入ってきたデータを更新しなきゃいけないんだけど、
ただ読みたいだけのリードのワークフローって結構あるじゃないですか。
機関系のシステムとかだったら、
データベースのメンテナンス
ken
ライトがそこそこあるけどほぼリードとかっていうのがあると思うんで、
そのリードはデータがコンシスタンシーを担保できる限りは、
古いバージョンのマルチバージョン、
別のバージョンのスナップショットを読ませといて、
その間にライトを更新させて。
だからいろんなバージョンのものが出てくるんですよね。
そうすると古くなっていくバージョンがどんどん増えていくじゃないですか。
ディスクサイズを使って。
だからそれをバキュームというか、
ガベッジコレクターみたいな感じで、
古くなったデータとか削除されたデータを綺麗にするみたいな、
コンパクションみたい、
コンパクションみたいなんだけど、
要するにガベッジコレクションみたいなのが働かなくちゃいけないみたいなのがあるんですよね。
バキュームはインクリメンタルにいく小さいオートバキュームもあれば、
フルバキュームみたいなメンテナンスタイムウィンドウを使っているバキュームもやらなきゃいけないんだけど、
データベース管理者からすると、
オフピークに仕事しなきゃいけないし、
しかもライトが多いボスグレーとかだったりすると、
そこのバキュームをキャッチアップしなくて、
いろいろインシデント障害になったりするし、
マルチバージョンなんで、いろんなバージョンをどんどん保存していくんで、
いわゆるテーブルブロートっていう問題があって、
要するにストレージをめちゃくちゃ食うんですよ。
っていう問題があったりするんで、
難しいですよね。
理解と解決策
ken
障害が起こったときにボスグレー仕草みたいなのも、
もしかしたら今後いろいろ見えてくると思いますし、
楽しいと思います。
そうですね。
Teppei Iwaoka
やっぱりさっき言ったように、
これまで遭遇してきたの結構データベース関連のものが多かったので、
それに遭遇したときに、
この本を読んだことでより深く理解していこうと解決策とか、
なぜこれが起こったのかっていうところをうまく説明できたりとか、
そういうのにもつながるかもなってちょっと聞いてて思いましたね。
ken
間違いないですよ。楽しみですね。
楽しみですね。
こんなところかな。結構話したね。
Teppei Iwaoka
そうですね。
ken
チャプター3、チャプター4、チャプター5も一緒に頑張っていきましょう。
ということで、本日はゲストにてっぺいさんをお呼びして、
Book Club Database Internalsのチャプター3の振り返り収録をしました。
てっぺいさんありがとうございました。
Teppei Iwaoka
ありがとうございました。
