00:16
アサヒさん、今日も宜しくお願いします。
宜しくお願いします。
今日は、DDIA本の公開、
臨読会シリーズ、Ch3&4編ということで、やっていきたいと思います。
ついこの前、DDIAの初回というか、
DDIA本のすすめみたいなタイトルで、
収録を公開したんですけど、
めちゃくちゃ反響があったんですよね。
すごかったですね。
DDIA本のおすすめをしてくれた方でしたっけ?
リツイートしてくれたりして、
いろんな人から反響がきましたね。
サブスクライブしてくれる方も、
10人以上増えたし、
僕らも技術の話をしているのが、
楽しいという感じなので、
僕らが出せるコンテンツとしては、
技術なのかなということで、
今日もやっていきたいと思います。
今日は、Ch3&4、読みました?
読みました。
なんか、レベルが一気に上がった感じがするんですけど、
インデックスとか、話が3は主になると思うんですけど、
かなり難しくて、読むのに時間がかかりましたね、今回は。
1とかは本当に、
Ch1はイントロみたいな感じで、
そこで読者こけさせたら困るから、
割とふわっと書いててね。
で、Ch2で盛り上げて、
からの3でドカーンみたいな感じですね。
そうですね、きましたね。
結構、B3とか、RSM3とか、
実装の詳細にも入ってるし、
ストレージエンジンの実装とは何かみたいなのを、
今まで知らなかったり、
意識しなかったりすると、
いきなり新しいキーコンセプトばっかり入ってきて、
ちょっと迷子になっちゃいがちなショーが、
Ch3の印象ですね。
うん。
はい。
でも結構、
最初のインデックスの歴史というか、
そういったところから始まっていくので、
その辺は何ていうか、
少しずつ進んでいくような感じもあって、
それを読みやすいように思いましたね。
特に最初のデータベースの、
どういうふうに始まるのかというか、
一番シンプルなデータベースの例みたいなのも、
あったりしたんで、
その辺は、
入りとしては入りやすかったかなという気はしました。
そうですよね。
Ch3、深掘る前に軽くCh4も触れとくと、
Ch4はどうでした?
Ch4は、
03:02
結構、このショー好きでしたね。
なんていうか、
あんまりバイナリーエンコーディングを、
私自身は意識したことなかったんですけれども、
だからこそ、
こういうことなのねっていう、
聞いたことある、
プロトコルバッファーとかアブラとか、
そういうのが、
どういう思想のもとに、
作られてきたのかみたいな、
っていうのが分かって、
僕はすごい面白かったですね。
多分、技術的な難易度はそんなにないでしょうで、
多分、
普通のデベロッパーとして、
アプリケーションコード書いてると、
なんかよく分かんないけど、
技術基盤チームとか、
プラットフォームチームに言われて、
プロトコルバッファー入れてみたりとか、
アブロスキーマ書いてみたりとかしてて、
スキーマ定義できるのが便利だよね、
みたいなノリで書いてたけど、
なんであんなにデータ基盤が、
こんなにこの、
スキーマを押してくるのかとか、
バイナリーエンコーディングを押してくるのか、
っていうのを、
ショーメモリとか、
パフォーマンスを上げるとか、
そういった観点で、
ちょっと分かった気になれる、
そこに入れる、
別の視点でね、
今までアプリケーションディグロッパーであれば、
なんかそういう、
新しい視点を得られるショーなのかな、
と思うし、
多分ここで挙げられてる、
バイナリーエンコーディングは、
メッセージ、
フルエントDでも使われてる、
メッセージパックと、
アブロと、
プロトコルバッファーと、
って感じでしたよね。
あと何だったっけな、
ちょっと忘れちゃった。
スリフトみたいな、
Facebookだっけな。
Twitterとか、
Facebookとか使ってる印象ですね、
あそこら辺はね。
Airbnbとか、
Airbnbも使ってたかな、
前なんか、
GraphQLのカンファレンス行った時に、
出てて、
そこら辺、
スキーマを、
スキーマってこう、
データベースを使う側の観点としては、
割と避けて通れない、
ところなんで、
ここも、
かなり実用的なショーでしたよね。
そうでしたね。
結構、
Web開発とかする方、
でも、
すごい、
生きることが多いんじゃないかな、
と思いましたね。
ね。
うん。
逆に、
チャプター5からは、
ストレージの話に入ってるから、
チャプター4までで、
サクッと、
データベース、
インスタンスとか、
使う側についてとか、
触れましたね。
ということで、
じゃあ、
どうしようか、
チャプター3を深掘って、
最後に、
ディスカッショントピックを、
話すって感じにしますか。
はい。
そうしましょう。
ほい。
はい。
じゃあ、
また戻って、
チャプター3。
チャプター3は、
どうかな、
なんか、
基本的に、
大きなテーマとして、
あるのは、
ストレージエンジン、
そもそも、
第3章の始まりが、
結構、
印象的じゃなかったですか。
覚えてますか。
あの、
はい。
最初のデータベースとは、
何か、
みたいな感じで、
あ、はい。
あの、
ね、
Linuxの、
あの、
パイプを使って、
あの、
テキスト、
すごい簡単な、
テキストファイルを使って、
06:00
これがデータベースだ、
みたいな感じで、
始まってるんですよね。
すっごい雑な、
テキストファイル。
うん。
めっちゃ、
分かりやすかったですね。
うん。
なんていうか、
はい。
印象的でした。
ね。
要するに、
テキストファイル作って、
それに、
ゲットとセットができれば、
データベースだよね、
みたいなのを、
超簡単な、
シェルコマンドで、
表現してて、
これがデータベースです、
みたいな。
以上、
終わり、
みたいな感じで、
まず始まってて。
うん。
そんな風に、
できるんだ、
っていう感じでしたね。
うん。
まあ、
もちろん、
そうですよね。
こう、
わからんプロセスが、
動いてるって感じなんですけど、
まあ、
裏側ではね、
基本的に、
独自の、
最適化された、
フォーマットで、
まあ、
バイナリが動いてて、
裏でディスクに書き込んでるって、
だけっちゃ、
だけなので、
まあ、
この入り、
上手いなと、
僕は、
最初読んだとき、
結構、
まあ、
さすが、
マーティン先生、
という感じですが、
うん。
おお。
ね。
で、
ここの話の広げ方が、
じゃあ、
リードするには、
問題があるよね、
っていうことで、
話を広げていくんですよね。
じゃあ、
何が問題があるかっていうと、
まあ、
まず、
基本的にアプリケーションが、
データを読むときに、
まあ、
リードとライト、
それぞれのワークロードが、
あるじゃないですか。
で、
これ、
リードするとき、
どれぐらいパフォーマンス出るの、
ライトしたときに、
こう、
ボトルネックにならない、
みたいな感じで、
まあ、
これは圧倒的に、
単なる一つの、
テキストファイルだと、
まあ、
これ、
どうしたらいいでしょうか、
ってことで、
まあ、
インデックスの話とかに、
繋がっていくと。
この話の繋げ方が、
上手いな。
うん。
いや、
いいですね。
うん。
で、
紹介されてるのが、
まあ、
まずは、
そもそも、
インデックスは何か、
っていうことで、
まあ、
インデックスを作ることによって、
リードのワークロードを、
上げていきましょう、
ということで、
まあ、
まずは、
ハッシュインデックス。
すごい、
まあ、
基本的には、
要するに、
実際のデータベースの例として、
うん。
あ、
どうぞ。
はい。
あ、
すいません。
いや、
キーをメモリに持っておいて、
ってやつですね。
持っておいて、
実際のデータを、
ディスクに置いてあげて、
読み込みを早くする、
っていう、
言い方ですね。
うん。
そうそう。
実際のデータベースで言うと、
例えば、
レディストとかですか?
ビットキャスクの例、
とかが出てたかな。
あ、
はい。
うん。
あ、
そっか、
ビットキャスクか。
そう。
まあ、
基本的に、
プログラミング言語を使ってたら、
Rubyでも、
Pythonでも、
まあ、
ハッシュという、
オプションとか、
ディクショナリーとか、
出てくるんで、
はい。
理解はそんな難しくない、
セクションだったかな、
と思いますが、
うん。
なんか、
こう、
ピックアップしたいキーワードとか、
よく分かんなかったところとか、
ありました?
ハッシュインデックス。
いや、
ここは、
すごい分かりやすかったですね。
09:00
うん。
うん。
で、
そっからさらに、
次に、
まあ、
コンパクトしていくみたいな、
うん。
話に繋がっていくんですよね。
そうそう。
それからまあ、
ハッシュの状態で、
こう、
ディスクに、
データを持っていった、
ディスクとか、
メモリデータを持っていったときに、
どういう問題が起こるか、
っていうことで、
まあ、
セグメンテーション、
ってのは、
まあ、
要するに、
こう、
データを読み書きしたり、
デリートしたりすると、
まあ、
欲しいところのデータが、
こう、
まあ、
セグメン、
なんていうか、
断片化というか、
さあ、
日本語では、
断片化で合ってる気がします。
はい。
浅井さん、
日本語で読んでるんだっけ?
いや、
英語で読んでます。
あ、
そっかそっか。
じゃあ、
ちょっと、
時々、
日本語で訳が、
二人とも間違うかもしれない。
ありがとう。
じゃあ、
断片化して、
それを、
まあ、
コンパクションすることによって、
あの、
必要なデータを、
まあ、
領域上、
近くにまとめておいて、
2回目以降の、
なんだろうね、
あの、
リードのパフォーマンスを、
アップデートするから、
コンパクトな方が、
やっぱ、
パフォーマンスが上がるんだけど、
その、
コンパクションの、
いつ、
どこでするかってのが、
多分、
まあ、
これ、
どのストレージエンジンを、
実装してても、
結構、
なんだろうね、
肝になってくるか、
ところだと思うんですよね。
はい。
うん。
結局、
その、
データに対して、
あの、
データファイルに対して、
あの、
ロックを取って、
アップデートしなきゃいけないから、
まあ、
基本的に、
まあ、
ロックを取ってやるんだけど、
まあ、
なんだろうね、
その、
アプリケーションの、
ワークロードとして、
書き込み自体が多いと、
まあ、
そこと、
デッドロックが発生してしまったりするから、
まあ、
割とこのコンパクション自体も、
こう、
チューナブルにしてるデータベースも多いかな、
という印象ですが、
まあ、
まあ、
多分、
なんでセグメンテーションが必要か、
あと、
コンパクションが必要か、
みたいなところは、
まあ、
サクッと入っていけるんじゃないかな、
と思います。
うん。
やっぱり、
その、
最初のシンプルなデータベースの、
例だと、
まあ、
更新をしたときに、
まあ、
削除を、
その実際に削除されるわけじゃないから、
まあ、
その古い更新前のデータたちを、
実際に消していくために、
まあ、
コンパクションをしていく、
っていう、
ところですよね。
うん。
そうそう。
それは、
すごい、
わかりやすかったです。
ね。
まあ、
だから、
ここぐらいまでだったら、
例えば、
読んで、
なんか、
その、
プログラミングのネタの、
一つとして、
超簡単な、
メモキャッシュD、
みたいな、
メモキャッシュドとか、
キーバリューストアを、
作ってみるとか、
ハッシュインデックスを、
もどきを、
実装してみる、
みたいなのは、
まあ、
割と、
とっつきやすい、
週末プログラミングの、
課題かな、
と思ったりしますね。
まあ、
そうですね。
うん。
まあ、
まず、
まずは、
すごい、
なんだろう、
ワンプロセスで、
作って、
それを、
作ったら、
12:00
インターフェースも、
定義して、
で、
この後の章を読む、
につれて、
ちょっと、
分散、
システムらしい、
機能とか、
メカニズムを入れてって、
みたいな、
こう、
この後で、
盛り上げていく、
みたいな感じで、
まあまあ、
そんなに、
難しい、
セクションじゃなかったかな。
うん。
一章ごとに、
ちゃんと作ったら、
すごい、
勉強になりそうですね。
そんな感じで、
それぞれの学びを。
1年じゃ、
終わんないでしょうね。
確かに。
うん。
データベース。
データベースは、
大変ですよ。
大変そうですよね。
はい。
そうね。
大変さが、
分かるって意味でも、
この、
いいよね。
DDIへの。
そうですね。
うん。
積み重ねられた、
歴史が、
あっての、
データベースですよね。
ね。
この、
インデックスの話に、
そうだけど、
まあ、
要するに、
その、
実装方法によって、
メリデミが、
違うじゃないですか。
リードとライトの、
トレードオフが、
どれぐらいか、
実装の難易度とか、
あとは、
セグメンテーションとか、
コンパクションに対する、
こう、
戦略とか、
まあ、
なんで、
なんか、
シルバーバレットみたいな、
こう、
パーフェクトな、
データベースは、
存在せずに、
いろんな人が、
自分の、
ビジネス要件に合わせて、
データベースを作る、
っていうのが、
まあ、
なんでかな、
っていうのが、
分かるというか。
確かに。
なんで、
こんなに種類があるのか、
っていうのは、
本当に、
一つの解決策が、
まあ、
その次に出てくる、
インデックスの例としてが、
まあ、
Sorted String Tableと、
まあ、
LSMのところですね。
はい。
はい。
ここのセクションは、
どうでした?
多分、
初めてですか?
知った、
名前とか、
初めてですね。
はい。
初めて聞きました。
LSMも、
SS Tableも、
はい。
まあ、
この、
ソートするのが、
結構大事なんだな、
っていうのは、
やっぱり、
まあ、
ソートすることで、
まあ、
どこにデータがあるのか、
まあ、
すぐに見つけることができるというか、
キーがどこにあるのか、
っていうのが、
まあ、
分かりやすくなるっていうのが、
この、
Sorted String Tableの、
あの、
メイトだと思うんですけども、
はい。
なるほどね。
それを、
徐々にディスクに、
書き込んでいくというか、
まあ、
メモリ上で、
ソートすることで、
効率的に、
えー、
ソートも、
できるし、
っていうのが、
効率良さそうだな、
っていう風に思いました。
そうですね。
やっぱり、
この発想の転換というか、
ソートさせておくことによって、
メリットが、
いろいろあるんですけど、
まあ、
例えば、
こう、
バラバラになった、
こう、
バラバラにしてた、
データブロックを、
マージしていくときに、
まあ、
まず、
マージソートが使えるんですよね。
あの、
ソートしてあるから。
うん。
はい。
で、
まあ、
効率的に、
その、
データブロックを、
マージしていくことも、
できるし、
まあ、
あとは、
15:00
その、
素血合の素だけどさ、
こう、
レンスの反対、
あの、
たくさん、
こう、
データが詰まってるのの、
反対ですよね。
はい。
過疎の素ですね。
過疎の素ですね。
過疎。
過疎ってる。
ちょっと、
なんか、
一人ぐらい、
日本語で読んでくれてる人、
次から、
いた方がいいかもしれない。
うん。
っていうことで、
そうです。
うん。
なんか、
もともとが、
たぶん、
Googleの、
ビッグテーブルの、
ペーパーで、
どうに、
こう、
提案されたというか、
世に出されたアイデア、
って書いてあった気がします。
読み間違ってなければ。
うん。
結構、
Googleさんの、
なんか、
貢献が大きいですね。
データベース会話やらと、
こういうやつとか。
ですよね。
あとは、
あとは、
出てくるドレンメルっていうのも、
ありましたけれども。
うん。
うん。
かなり、
データベースに、
投資してるんだなっていう、
なんか、
この本読んでて、
少し分かりました。
ね。
まあ、
メタとか、
結構、
やっぱ、
ここら辺で出してるし、
まあ、
多分、
AWSのDynamoのペーパーとか、
あとは、
LogsDBのインプリメンテーションとか、
結構、
まあ、
ね、
参考にしたりとか、
これを使ってたりとか、
多いけど、
まあ、
なんだろ、
使われてるコンセプトは、
なんか、
めちゃくちゃ特別なものは、
なくて、
いろんなコンセプトがあって、
それどこ、
どのDBがどこを実装するか、
みたいな、
話だったりもするので。
はい。
やっぱ、
こうやって、
なんだろ、
こう、
横展開しやすい知識には、
なるかな、
と思ってたりしますね。
うん。
うん。
はい。
で、
まあ、
多分、
まあ、
いろいろインデックスあるんですけど、
まあ、
一つだけ、
覚えておけばいい、
というか、
一つだけ知っておけばいい、
とするならば、
まあ、
間違いなく、
B3でしょうね。
うん。
はい。
重要度で言うなら。
B3は、
さすがに、
聞いたことがありますね、
自分も。
ね。
普通の世界で言うと、
キングですよ、
キング。
うん。
はい。
B3を押さえておけば、
間違いないとは、
言わないけど。
うん。
まあ、
今の、
ある、
RDBMSとかで、
よく使われてるのも、
基本的には、
B3ですね。
インデックスとかを、
かけるときに。
うん。
そうですね。
まあ、
基本的なRDBMS使って、
クリエイトインデックスを、
発行したときには、
まあ、
大抵B3じゃないですか。
デフォルトとかでは。
うん。
まあ、
まあ、
B3を読んで、
なんでこれが必要だって、
分かんなかったときは、
まあ、
一つこう、
試行実験として、
まあ、
インデックスを、
作りなさいと、
言われましたと。
で、
すごい効率的な、
ルックアップのできる、
インデックスを、
作りなさい。
ただし、
あの、
データは、
全部ディスクに、
置いてくださいと、
いう制限を、
言われたときに、
じゃあ、
あなたは、
どんなインデックスを、
実装しますか、
っていうところなんですよね。
この、
18:00
B3の、
なんと、
一番の肝って、
この、
ページ数が増えても、
木の高さが、
あんまり増えない、
っていうところなんですよね。
うん。
だから、
その、
木構造じゃないですか、
基本的にはね。
はい。
例えば、
木の高さって、
あるよね。
あの、
その、
ルートのノードから、
一番下の、
あの、
ノード、
リーフノードまで、
何回たどっていくと、
あの、
一番下に、
こう、
アクセスできるか、
みたいなところで、
たどっていくことで、
あの、
4つ、
一番下の、
こう、
ノードに、
のデータを取ることができれば、
まあ、
高さが4になるわけだけど、
例えば、
この、
木の高さっていうのを、
なるべく、
少なくしたいんですよ。
ディスクに、
実装するときには。
はい。
それは、
なぜかっていうと、
ディスクに、
ランダムアクセスするって、
めちゃくちゃ遅いじゃないですか。
メモリと違って。
はい。
うん。
だから、
その、
ディスクIoが、
すごい発生する。
基本的に、
アクセスを減らしたい。
まあ、
だから、
世の中的には、
RDBMSを実装するときに、
前段に、
メモリの、
キャッシュを置いたりとか、
まあ、
なるべく、
その、
インメモリに、
オブジェクトキャッシュして、
置いたりするんですけど、
で、
まあ、
その、
ディスクを減らすために、
その、
例えば、
ページ数っていうのを、
ページ数の単位で、
データを、
ディスクに持っておくときに、
こ、
このBツリーの、
あの、
なんていうかね、
あの、
1億エントリー、
1億エントリーとか、
あったときにも、
サイズ、
マックスでも、
4回のルックアップで、
目的のデータが、
見つかるんですよ。
だから、
逆に言うと、
データベースに、
例えば、
1億個の、
データ数が、
入っているときには、
ディスクIOは、
マックスでも、
4回だけで、
目的とする、
データを、
取得することが、
できると。
はい。
うん。
っていうことで、
基本的に、
この、
この、
この、
その、
まあ、
実装もしやすい、
考え方としては、
シンプルだし、
まあ、
多分、
これの実装みたいなのも、
どんどん枯れているので、
他の新しいデータベースを、
作っても、
コピーもしやすいし、
ということで、
まあ、
なんだろう、
インデックスのキングに、
なっているんじゃないかな、
という想像はしますが。
はい。
この、
あの、
1つの、
木のサイズというか、
が、
大体、
4キロバイトでしたっけか、
マックスみたいなのが、
書いてあって、
結構、
小さいんだなっていう、
ブロックのサイズ、
だなっていうのが、
まあ、
思って、
まあ、
それで、
その4回の、
4つの深さで、
まあ、
1億レコードとか、
いけるっていうのは、
すごい良いことですよね。
かなり効率がいいんだな、
っていう風に、
思いましたけど。
うん。
で、
この、
多分、
ブロック数って、
どうだろう、
まあ、
最近だと、
まあ、
違うブロック数、
configurableだったり、
いろんなブロック数を、
試して、
まあ、
21:00
多分、
まあ、
でも、
最初は4KBが、
メインだった気がしますね。
うん。
こんな感じで、
なんか、
気になったキーワードとか、
ありますか?
他に。
うん。
なんか、
あの、
あんまり、
関係ないですけど、
まあ、
インデックスっていうのを、
なんか、
妻に説明してって、
言われたんですよ。
なんか、
その、
今日は何を話すの、
みたいな話になって、
で、
本のトップに、
その、
章立ての、
まあ、キーワードみたいなのを、
書いておけば、
そっから、
本内に飛べるよね、
っていうのを、
説明したら、
まあ、結構、
すぐに分かってくれて、
インデックスっていう、
名付け、
名前がすごい、
いいなっていうか、
まあ、
誰でも分かりやすい名前。
作品。
まあ、実物、
はい、作品っていうのが、
そのまま、
現実世界にあるので、
まあ、
いい名前だなって思いました。
うん。
確かに。
まあ、
アナロジーとしては、
分かりやすいですよね。
はい。
分かりやすいですね。
うん。
まあ、多分、
この章を、
読んでくときに、
なんだろう、
なんで、
ハッシュインデックスから、
LSMツリーみたいなのを、
発明する必要があったのか、
そして、
なんで、
その後で、
また、
Bツリーみたいなのが、
出てきたのか、
っていうのを、
理解するためには、
まあ、
そもそも、
こう、
ディスクとメモリの、
進化とか、
その、
ディスクとメモリを、
アプリケーションから、
使うときの、
違いみたいなのを、
意識すると、
まあ、
分かりやすいんじゃないかな、
とか、
思う、
かな。
うん。
確かに。
ちょっと、
あの、
さらに、
深掘るには、
実際に、
もっと、
データベースを使って、
開発しないと、
実感が、
さらに、
持てないというか、
気はするんで、
ここから、
さらに、
参考文献とか、
まあ、
見ていって、
深掘りしていきたいですね。
なんか、
一回、
ここ、ね、
浅井さんが、
キャリア的に、
よく使ってきた、
RDBMSって、
なんですか?
MySQL?
Posgre?
これは、
Posgreが、
多いですかね。
あとは、
Oracleは、
全色で、
使ってました。
ああ、
Oracleね。
Posgreが、
一番、
そうだね。
まあ、
なんか、
一つ、
データベースを、
ピックアップして、
まあ、
そこの実装を、
軽く見てみて、
まあ、
なんか、
気になったところ、
それで、
やってみたいですね。
うん。
ね。
僕は、
今、
現場でMySQL使ってるけど、
まあ、
比較してみるのが、
面白いと思いますね。
確かに。
B2Dも、
結構、
アッシュがあるので、
データ構造として。
はい。
B2D、
を元にして、
いろんな、
こう、
ちょっと改善したやつとか、
まあ、
そこら辺の言及も、
割と、
最新であったりするから、
まあ、
そこら辺、
ピックアップしていくのも、
いいよね。
24:00
なんか、
ここを読んで、
B2D、
分かった気になったんですけど、
僕も。
まあ、
本当に、
あの、
入り口でしかないので、
本当に、
データベース、
評価入って、
分かるけど。
確かに。
なんだろうね、
B2D、
知ってますってのは、
数学で言うと、
二次公定式、
知ってます、
みたいなぐらい、
分かんないけど、
いい例えかどうか、
知らんけど、
まあ、
つまり、
何も分かってない、
ということです。
はい。
ということで、
うん。
まあ、
業務にどう生きてくるか、
みたいなところで、
ちょっと話すと、
まあ、
データベースのメトリクスを、
例えば、
まあ、
浅井さん、
僕もSREとかだから、
まあ、
データベースのメトリクス、
普段読んでたり、
多分すると思うんですけど、
まあ、
ディスクとメモリの違いとか、
あとは、
内部のね、
ストレージエンジンの実際とか、
それを、
軽くでも、
メンタルモデルとして、
頭に入れておくと、
あれ、
何で、
ここがスパイクしてるんだな、
とか、
まあ、
仮説を立てるときの、
ストーリーへの理解度が、
まあ、
深まるんじゃないかな、
と思うので、
まあ、
ここは、
本当に、
まあ、
僕としては、
最初、
読んでよかったでしょうかな、
と思ってます。
チャプター3。
そうですね。
なんか、
1、
1回、
その、
自分の会社で、
何ですかね、
すごい、
クエリが遅い時が、
ま、
あったりして、
まあ、
それ、
よくよく見てみたら、
まあ、
あるので、
すごい、
基本的な問題、
解決するにも、
インデックス、
向かっていると、
まあ、
いいな、
ということは、
多いと思いますね。
ね。
まあ、
なんか、
せっかく、
いい話が出たから、
じゃあ、
例えば、
思考実験ですけど、
じゃあ、
いきなり、
する、
あの、
クエリが、
遅いって、
言われました。
浅井さんは、
じゃあ、
どっから、
見始めますか。
まず、
言われるんですよ。
ああ、
でも、
まずは、
そうですね、
結構、
最初は、
データベースの状態を、
チェックしますかね。
なんか、
CPUの利用率が、
どうかとか、
まあ、
これまで、
普通に、
速いクエリなのであれば、
データベースに、
他のが、
かかっている可能性が、
あったりするんで、
先に、
そういうとこを、
見ちゃいますね。
で、
問題なければ、
クエリ自体に、
問題がある可能性が、
あるので、
まあ、
その、
クエリを、
アナライズしてみる、
みたいな、
感じですかね。
うんうん。
じゃあ、
クエリが、
非効率だって、
なった時に、
まあ、
はい。
どうなんすかね。
インデックスが、
貼られてない、
みたいな、
処方的な、
ミスって、
どれぐらい、
あるかな。
うん。
なんか、
その、
データベースを、
移行とか、
するタイミングで、
インデックスが、
貼られてない、
みたいなことが、
27:00
あったり、
それも、
想定しない、
ユースケースだった、
ってことか。
そうですね。
とかは、
ある気がしますけど、
まあ、
徐々に気づいていく、
っていう感じですかね。
なんか、
うん。
多分。
ね。
で、
まああと、
それを逆に、
よくありがちなのは、
インデックスを覚えた、
ジュニア、
エンジニアとかが、
インデックス貼りまくる、
問題、
みたいな。
ありますね。
そして、
インデックス貼りまくって、
あの、
インデックス貼りましたよ、
って、
僕もやりました。
そうですね。
まあ、
インデックスが何か、
わかってるのか、
みたいな。
あの、
一行足すと、
食えなくなる、
魔法の杖、
みたいな。
うちでの小槌、
みたいな感じで、
使ってしまう。
うん。
まあ、
でも、
逆に、
この章を読むと、
まあ、
インデックスってのは、
裏側で、
何が起きてて、
みたいなね。
まあ、
結局、
別の、
見方が違う、
データベースを作ってるだけに、
過ぎないので、
自分は、
ありますよ、
って、
書かれてますよね。
例えば、
はい。
基本的に、
その、
元のデータベースに、
書き込んだときに、
整合性が、
あの、
壊れないように、
インデックスも、
更新しなきゃいけないじゃないですか。
で、
そのときに、
こう、
はい。
あの、
ロックを取って、
インデックスも、
更新するわけですよね。
例えば、
一つのテーブルに、
更新するときに、
インデックスが100個あると、
100個のインデックスを、
あの、
シンプルに、
ナレーで考えると、
なんで、
インデックスが多ければ、
多いほど、
その、
ライトのワークロードが、
あの、
パフォーマンスが、
デグレってくので、
デグ、
あの、
下がってくので、
インデックスは、
決して、
魔法の小槌ではないよ、
っていうのは、
まあ、
割と、
僕も初期にやらかした、
話ですね。
うん。
書き込みには、
強くないと、
インデックスは、
うん。
ですよね。
うん。
あと、
なんか、
インデックスとかに、
インデックスを貼っている例を、
見ることがあって、
うん。
タイムスタンプって、
すごい、
あの、
幅広いじゃないですか。
それに、
インデックス貼ると、
まあ、
ものすごい、
インデックスの、
ボリュームが、
でかくなっちゃう、
と思ってて、
まあ、
やっぱり、
それをするのであれば、
例えば、
日付とか、
もっと、
その、
幅が、
振れ幅が狭い、
カラムを、
持っておいて、
そこに、
インデックスを貼る、
みたいな、
どう思いますか。
うーん、
そうですね。
まあ、
一つ、
あえて、
タイムスタンプを、
貼るのが、
メイクセンスな場合、
つまり、
タイムセンス、
いわゆる、
その、
あれですよね、
あの、
せっ、
丸め込みとか、
してなくて、
まあ、
セカンドとか、
ミリセカンドまで、
入っている、
ああ、
そういうことですよね。
うん。
30:00
うーん、
例えば、
例えば、
例えば、
いや、
わかんないですね。
そうですね。
すいません。
具体的すぎて。
うーん、
そういうときが、
あるかな。
いや、
なんか、
ある、
あるとは思う。
ビジネス要件、
本当に、
いろいろだから。
ああ、
はい。
なんか、
その、
実際のクエリが、
まあ、
日付ベースで、
クエリをしているのであれば、
無駄かなって、
感じがしますけど、
まあ、
もし、
タイムスタンプベースで、
うーん、
変にしてくるときとかかな。
うーん。
ということで、
はい。
はい。
ちょっと、
パッと思いつかないので、
はい。
いきちゃいましょうか。
うん。
はい。
まあ、
チャプター3は、
こんなところかな。
じゃあ、
チャプター4行く?
行きましょう。
はい。
チャプター4は、
テーマは、
エンコーディングフォーマット、
ということで、
さっきも、
ちらっと言ったけど、
まあ、
メモリから、
ファイルに保存したり、
ネットワークを、
転送するときに、
もちろん、
バイナリー形式に、
変換する必要が、
あるんですけど、
いかに、
ネットワーク転送量を、
最適化するか、
少なくするか。
もちろん、
少なければ、
少ないほど、
いいので、
まあ、
同じ、
例えば、
ストリングとか、
同じような、
オブジェクトでも、
その、
バイナリーの、
エンコードの仕方、
どういう風に、
こう、
バイナリーで、
表現するかによって、
最適化するための、
いろんな、
こう、
プロトコルが、
ありますよ、
っていう章で、
実際に、
この、
バイナリーの、
ね、
あの、
メモリ上、
どう、
0と1とかがね、
あの、
並んでるか、
みたいなのも、
図もあり、
ながら、
一つ一つ、
紹介していくとね、
まあ、
結構、
分かりやすい、
章だったかな。
はい。
とっつきやすかったですね。
実際、
業務で、
使ったことがあるのは、
出てきた中で、
やっぱり、
なに、
GRPCとかは、
ちょっと、
あの、
運用サイドで、
触ったことあるんですけど、
まあ、
プロトコルバッファーの、
RPCですよね。
うん。
まあ、でも、
実際に、
自分が、
スキーマを書いたりしたことは、
正直、
ないですね。
JSONとか、
XMLとか、
くらいですね、
やっぱり。
あ、
逆に、
運用では、
どういったことやったんですか?
あ、
なんて、
その、
GRPCの、
まあ、
ロードバランシングが、
うまくできない、
みたいなのに、
対応とかを、
したことが、
あって、
まあ、
それ自体は、
あんまり、
型とかとは、
関係なくて、
まあ、
GRPCの、
ネットワーキング側ですかね、
どっちかっていうと、
その、
まあ、
常に、
ネットワークを、
張り続ける形なので、
ロードバランシングが、
うまくできない、
みたいなことが、
あったのを、
33:00
まあ、
対応したっていう感じですかね。
なるほど、
なるほど。
はい。
まあ、
コンパクトな、
作り方も、
いろんな、
使い方が、
あるんだけど、
まあ、
何だろう、
結構割と、
人気というか、
日本のスタートアップでも、
よく聞く印象で、
あの、
データフォーマットとしては、
この、
あの、
セルフ、
なので、
データとして完結してて、
データ自体に、
隙間を、
含まないので、
まあ、
結構、
コンパクトにも、
なりやすいし、
まあ、
Googleも開発してるし、
いろんなクライアントが、
割と、
印象ですかね
メッセージパックとかは
FluentDを使っていたので
よくそこで
メッセージパックを使うという意味じゃないですけど
普通に動いていたというか
使っていたかな裏側で
ここら辺は
どのバイナリデータフォーマットを使うかという
選択する側にはなかなか
プラットフォームエンジニアチームとか
データ基盤チームにないと思うので
複数のバイナリデータフォーマットを
比較検討して
最適なものを選ぶとか実装するという
シチュエーションに
恵まれる人はあんまりいないと思いますけど
何かしらの形で使っているという人は
ほとんどですよね
はい
ケンさんもカフカとかやってて
アブロはかなり触ったんじゃないですかね
アブロスキーマはやっぱり
使いやすいし
コンフルクラウドとかやると
アパッチカフカのマネージドサービス
使うと
多分ドキュメントとかチュートリアル読んでも
もちろんですけど
アブロどうですかみたいな感じで
押してくるので
カフカをとりあえず使ってみようみたいな人が
アブロを入れるみたいなの多い気もしますけど
でもプロトコルバッファーも
使っている例とかもあるし
そうなんですね
カフカ的にも別に
バイナリのフォーマットは何でもいいので
こういう感じかな
多分
アプリケーション
スキーマは基本必要だからね
バージョンアップグレードとか
広報互換性
の担保とかを考えるときには
何かしらのスキーマは必ず必要になってくると思うけど
なんかデータベースの本だけど
やっぱここにも触れてるってのは
割と好印象というか
逆に言うとこれのせいで
ページ数長くなってると言っちゃ言えるんですけど
最初読んだ時飛ばしたな
よく分かんなかったし
数年前に
結構それぞれのスキーマに対しての
互換性がどうなってるかっていう話を
何度か繰り返してるのですごい丁寧だなって思いつつも
逆に若干冗長な感じもありましたね
この章が
なんかこの章だけちょっと浮いてる感じがあるよね
データベースの本読んでたらいきなり
分かるんだけど
今となってはある意味が
でも
B3とかね
36:00
LSMの話読んでたらあれ次いきなり
メッセージパックと
プロトコルバッファーみたいな感じにはなるよね
うん
うん
うん
うん
うん
うん
うん
うん
うん
うん
うん
うん
うん
うん
うん
うん
うん
うん
うん
うん
うん
うん
今後もっと繋がってくるんですかね
結構今後の
章への参照があったので
うん
まあ
メッセージQとかやるときに
出てきたりとか
って感じですかね
うん
ね
こんな感じかな
まあ
シャプター3、4
ちょっとまとめて
見ると
なんかね
まあそもそも
クエス
ディスカッショントピックですけど
ディベロッパーとして
ストレージエンジンの内部実装と
とかよくあるインデックスの特徴とかに
どれぐらい詳しくなっておく必要があるのか
あるならどこまでかっていうのは
一つこう考えるところかなと思うんだけど
採算的には何か意見とか感想ありますか
もしくはこの本を読んで
ここに対する意識が変わったとか
そもそも読んでるってことは
こう素人もって読んでるの
ところもあると思うんだけど
あー
ちょっとずれてるかもしれないですが
思ったのは
結構
設計するタイミングで
例えば実際に開発で使う
スキーマを設計する必要があるんですけども
一方でさらにその読み取りについても
考えはいけなくて
例えば今後データ
まあデータウェアハウスとかから読み取られる時に
まあ全然その
あのなんですかね
アプリケーションで使う
スキーマの方と
違う使われ方をすることがあるので
まあその辺でかなり強調して
設計していかなきゃいけないのかな
というふうには思いましたね
そのカラムとか
テーブル一つ設計するにあたっても
まあどこにインデックス貼ったら
早く読み取れるかみたいなのが
全然変わってくるので
はいっていう意味では
より他のチームとか
まあ連携した方がいいのかなと思いました
そうですね
その他のチームとかなってくると
多分よくある構成としては
なんだろう
例えばデータが増えてくると
そのデータを
分析したくなってきて
データ基盤チームみたいなのを
作ると思うんですね
データウェアハウスとか
まあオラップですね
あのトランザクションの
OLTPに対して
オラップ側を作ったときに
例えば
MySQLとかPOSGREしか
使ったことない感じで
あの
データウェアハウスから
データを取ろうとすると
基本的には
怒られるというか
データベースから怒られるというか
まあ
全然こう
仕組みが違うし
得意なことが
違うので
あの
なんだろう
そこら辺が分かってないと
なんか違うデータベースとかで
違うデータ基盤に
出会ったときに
まあ
基本的にその
データウェアハウスを作ってるとか
他のチームであることが
多いと思うんですけど
39:00
なんか
小さいワークロード
ガンガン
データウェアハウスに飛ばしたら
まあもちろん
データベースにも
必要ですように
負荷をかけてしまうんですけど
じゃあそれが何でなのかっていうのを
まあ投げる前に
自分でちゃんと知っておくとか
まあそういったところの
他のチームが持ってる
データ基盤を使うときに
最適なこう
コミュニケーションがお互いできる
みたいな
一歩にもなると思いますね
うん
まあ
なんだろう
ストレージエンジンの
詳細を調べて
例えば
自分たちで作ったり
しなきゃいけないみたいな
ことになる
企業ってなかなかない
多分それこそ
はい
Googleとか
Metaとか
あの
Amazonぐらい
そういう
の規模にならないと
そのトレードオフが
ならないというか
基本的に
スタートアップだったら
やっぱビジネス作っていくほうが
価値が高いので
そこまでやる
必要はないと思うんですけど
うん
こんな感じかな
うん確かに
で
必須ではない
っていう感じですかね
そのデータベースの
この詳しい
B2Aの知識とかが
まあ
あっても
必ず役に立つわけない
けど
なんか
多分トラブルとか
起きたときとか
まあ急に
必要なときとかに
あったと
あると
まあ
ありがたいというか
すぐに
開かれたときは
めちゃめちゃ出せるみたいなときは
タイミングはあるかもしれないんで
そういう意味では
ナイストハブというか
あったらいいなという感じですかね
そうだね
うん
まあなんかじゃあ
この3章4章として
読んでみて
じゃああなたの
テイクアウェイは
一番のテイクアウェイは
何ですか
えー
そうですね
まあやっぱり
まあ
データベースの
運用に関わってきたので
まあその知識を知っていたら
もっと早く解決できたなっていうことは
まあありますね
それこそインデックスの
まあ問題であるとか
まあ
ただまあ
今回その
そういういろいろ
データベースの運用をちょっと
まあ知ってから読んだので
その分なんか知識との紐づけみたいなのができて
まあそれは
それで読みやすかったと
ところもあるかな
っていうふうに思いました
あああれねみたいな
ちょっと思いながら
読んだりとかできたので
はい
それはよかったです
うん
うん
はい
ケンさんも何かありますか
いやまさに同じで
アサイさんと
はい
なんかこう
経験する前って読んでも
よく分かんないんですよね
知識として入れても
はい
でも実際に現場で
障害対応とか
自分のミスとかをしたときに
あ
あの本に書いてた
このことだったのか
っていうふうに
知識と体験が
結びついて初めて
楽しいというか
そのときにこう
経験になるんですよね
本を読んで
そういった自分のミスとかを
42:01
予防できるかっていうと
ちょっとそこまではできないんですけど
やっぱり現場の知識とか経験って
本当にリアクティブというか
なんか
教科書で書かれてるように
綺麗に一歩ずつ経験できるわけじゃないじゃないですか
結構
いろんな種類の障害とか
いろんなデータベースに触れ合う機会っていうのが
ポンポンポンポン
なんかいきなり来たりするじゃないですか
だからなんかそういう断片的に
入ってくるんですよね
現場の知識っていうのは
それをやっぱり一回
深呼吸して
ストーリーに沿って
いろんな知識をこう
まとめる時間が必要で
僕にとってはそれが読書とか
ソースコードリーディングだったりするので
そういうのが
やっぱりそのデータベースを運用っていう観点においては
やっぱこの本読んだ時はすごい
そういう時間をくれたかな
僕に
ちょっと落ち着いて
業務データ知識を棚卸ししましょうみたいな
この本を読んだ時はアプリケーションデベロッパーだったから
広告配信システムを作ってる
なんか今こうやってアサヒさんと改めて読んでみると
今はこうデータベースを使う側から
SRE DREっていう
データベースの裏側を運用する側になってから
もう一回読み直してるので
そういう観点でも当時の気づきとの違いとか
当時気になった
当時気にかかったコンセプトと
今興味が出てるコンセプトの違いとかを見ながら
自分の趣味ってこう変わったんだなーみたいなとか
あの自分はこれぐらい成長できたなとか
自分は大して成長しないなみたいなのを
分かりながら読んでるってのは面白いかな
うん
確かに
そういうなんか
言い方が全然変わって面白いですよね
当時と2回目読むと
そうそうそう
いやー
まあでも次から本番ですよ
まだパート1これで読み終わったけど
パート2が
パート2が
分散データベース
はい
ここからさらに難しくなるんですね
次はチャプター一つずつかな多分
うん
5と6一緒にやったら1時間超えるか
多分
ポッドキャストの配信的には1個ずつがいいんだろうな
そうですね
うん
いやープレッシャーがすごいな
どんどん難しくなっていくんで
まあ頑張ります
はい
あのーじゃあ
収録前に奥さんにどうやって説明したかっていうのを
あの次も教えてください
毎回やりますかそれはい
それすごい良いトレーニングじゃない
僕もたまにやるけどさ
あの
プログラマーじゃないけど
家族とか友人に
あのコンセプト説明するって
要するにあのよくあるじゃん
猿でも分かるギットとかさ
中学生にでも分かる何々みたいな感じで
45:01
そのコンセプトの本質を
本当に掴んでるかどうかみたいになるから
結構いいですよね
アナロジー使ってみたりとか
確かに
いやでも確かに聞いてくれて良かったなって僕も思いましたね
なんか自分の理解も深まるというか
はい
まあ確かにみたいなことも多かったので
次回もやってみます
じゃあ
それをね
例えば合意のコンセンサスアルゴリズムもするときにさ
クォーラムって何みたいなの言われたときに
クォーラムを
あの
非プログラマーの自分のパートナーに
こう説明できると
いいと思います
とか色々そういうコンセプト出てくると思うからね
そうですね
確かに
大事ですよね
実際そういうのを
非エンジニアに説明する機会っていうのも
必ずどっかであると思うんで
そういうトレーニングは大事ですね
ね
なんかこれも次のディスカッショントピックの一つとしてもいいかもね
この本を読んであなたが考えついた最高のアナロジーを
お互い一つずつ紹介するっていう
確かに
あーそれいいっすね
テーマとしては
忘れないで書いといて
そしたら僕も頑張って思いつくので
はいアナロジー
はいアナロジー
はい
はいじゃあ今日はこんなところかな
どうですか
ありがとうございました
はい
まだ
最後まで読んでいけそうですか
いけます
よし
じゃあ次はチャプター5やっていきましょう
じゃあ今日はこれぐらいで
お疲れ様でした
はいありがとうございました
ありがとうございました
