データベースの雑な話 in 栃木ゆるIT勉強会@小山

Transcript

1. データベースの雑な話 B-TreeだけじゃないDBのあれこれ
2. お願い • スライドの写真撮影はOKです • 「私」の撮影はご遠慮ください
3. 自己紹介 • アークリスプ / 尾上折紙(おのうえ おりがみ) ◦ 本名ではない ▪ あらゆるサービスに偽名で登録している ◦ Lisperだった時期がありそのような名前になった ◦ arcというlisp方言があって… ◦ Twitterの名前はコロコロ変わる • React+TypeScriptでフロントエンドエンジニアをやっている ◦ 現職ではPHPも書いている ▪ むしろこっちがメインでは？？？？ ◦ rustたまに書くけど難しい • 転職をポンポンしてたら経歴が汚れまくって書類面接で落ちまくるようになりかなり ヘコむ
4. ＿人人人人人人人人人人人人人人人人＿ ＞　突然DB自作したくなってきた　＜ ￣Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y￣
5. DBの話 • DBにはいろいろあるが、雑に3個に大別される ◦ RDBMS ▪ MySQL、PostgreSQL、SQLiteとか ▪ いわゆる普通のデータベースシステム ◦ NoSQL ▪ DynamoDB、MongoDB、Redisとか ▪ 水平にスケールしやすいがクセが強い事が多い ◦ NewSQL ▪ AWS Aurora、GCP Spanner ▪ 業務などの実運用で RDBMSのようなものを使いたいとなると候補に上がりやすい • Aurora MySQLとAurora PostgreSQLはそれぞれ「互換」というだけで中身は別物
6. • 作るのならやはりRDBMSだろうという気持ちに • しかし何も知らない ◦ だいたいB-Treeとかいうアルゴリズムで作られているという雑な認識 ▪ 大学でデータベースの講義をとったのにこの程度の理解という残念な状態 ◦ MySQLとかPostgreSQLの実装を見に行ったが案の定複雑かつ大規模 ▪ 何も知らない状態で見に行っても何が何やってるのかわからず困惑 ◦ 勉強しようにもDB関連の本はほぼすべてが「使う」ことが目的 ◦ 初手で詰む
9. ありました • Rustで簡単なRDBMSの実装の紹介 • 小さいので取っ掛かりとしてかなり良かった ◦ SQL文の解釈などはやらない ◦ データの保存と取り出しのみ（語弊がある言い方） ◦ Rustなので型が頑健で理解しやすい • 書籍にすべてのコードが載ってはいないのでGithubを見に行って往復
10. B-Treeがすべてではないことを知る • そもそもB-Treeは基本形なだけであって実際にはB-Treeを拡張したアルゴリズム を使うこともある ◦ MySQLはB+Treeという亜種を使っている • データ表現の方法でしかない • ディスクやメモリ、キャッシュの扱いをちゃんとしないといけない ◦ 結構大変 ◦ 今回はこのあたりの話です
11. そもそもどうやってデータは持ち出されるのか • データの読み書きは基本的にOSのファイルシステムが管理する ◦ ファイルシステムは固定長のサイズでデータをストレージからとってくる ◦ ブロックサイズという ◦ ext4の場合はデフォルトが 4096byteで設定されてる ▪ 変更できるが、実質1024byte, 2048byte, 4096byteの3種類のどれかから選ぶしかない ◦ このブロックサイズを基本としてデータは取りに行かれる
12. データの読み書きはものすごく遅い • HDDへのアクセス時間は10~20msぐらいかかる • SSDでも100~200μsぐらい • メインメモリなら100ns ◦ つまりメモリにないものを HDDから読み込もうとするとアクセスするだ けで10万倍の時間がかかる ◦ SSDならかなりマシになるとはいえそれでも遅い • もっと言えばL1 cacheは1.33~4nsぐらい • ということでストレージへのアクセスの遅さを隠蔽したい ms: 10^-3秒 μs: 10^-6秒 ns: 10^-9秒
13. キャッシュは王様 • すべてのデータをメモリが持ち続けるのは現 実的ではない ◦ 揮発するし ◦ 容量少ないし • よくアクセスされるデータはメモリに持ってお いてなるべくストレージにはアクセスしない • キャッシュヒット率を上げる
14. キャッシュの方法 • OSに任せる ◦ OSの違いやバージョンによってキャッシュの仕方が全然違くて挙動が変わると言ったことが起こり 得る ◦ 大半のシステムならこれでいいが、 DBにおいては不都合 • 自分で実装する ◦ すべてを管理できる ◦ 最適なアルゴリズムを選択できる ◦ メモリの位置などの調節も可能（アラインメント） ▪ アラインメントは結構大事で、読み込みたいデータがメモリ上でデータが連続しているのが理 想的 ▪ 断片化しているとプロセッサはメモリに複数回問い合わせないといけなくなる
15. キャッシュの方法 • LRU (Least Recently Used) ◦ いろいろなRDBMSが採用している ◦ 最近もっとも使用されてない値を捨てる (evictionする)方式 ◦ 実装は多種多様で、それぞれの DBでどのように実装されているかがかなり異なる ▪ ほとんどLRUと名乗っているだけで実質亜種みたいな感じになってる ◦ MySQLの実装例を紹介します • 他にも色々あるがあとで紹介します
17. LRU • LRUは簡単に見えるが実際に使用していくと数々の問題が出てくる ◦ ランダムアクセスが基本となるクエリには強いかもしれないが、シーケンシャルアクセスには極端に 弱い ◦ シーケンシャルなアクセスをした途端キャッシュのすべてがそのデータで埋め尽くされるといったこ とになりかねない ◦ それを踏まえたうえで別のアルゴリズムを選択するか、拡張していくことをしなければいけない ◦ DBのキャッシュというのは地獄 ◦ ちなみに、他のアルゴリズムには MRU、CLOCK、Q2とかがあります
18. ストレージの最適化 • キャッシュは大事だが、そもそもDBは主としてストレージのデータを扱う • ストレージへのアクセスは必須なので、ストレージも最適化の必要がある • SSDなら大丈夫なんてことはない
19. スロット化ページ • ディスク上のデータレイアウトを考える • フラグメンテーションは避けたい ◦ HDDメインの時代にはデフラグなんてことをやってましたね • 保存したいデータ型はいろいろある ◦ 固定長: integer, float, double, char… ◦ 可変長: text, blob • これらを効率的に格納するために、スロット化ページを利用する
20. スロット化ページ • 大まかには、ディスク上にポインタ（実データ位置の情報）とレコードの位置を決定 する • 可変長レコードの保存も簡単にするために、ページを固定長のセグメントに分割す る ◦ 固定長に分割する以上、たとえば 64Byteのセグメントに1Byteしか入らなかったら63Byteの容量が 無駄になる • ページの追加は単にデータを追記すればよい • 削除の際はページを書き直してレコードを移動することで領域を回収
22. まとめ • ここまで紹介したものはかなりざっくりした解説 • 小さな実装では複雑にはならないが… ◦ →実際はもっとややこしいことになっている • 実際にはストレージの故障に備えてバックアップをすることや、ログの保存もやる ◦ マルチスレッド化でLRUなどのキャッシュまわりは大胆に複雑になる ◦ 分散ストレージを採用すれば … ◦ 分散合意アルゴリズム (Paxos, Raftなど)… ◦ クラスター化… ◦ 沼
24. ここ小山市でシェアハウスやる（宣伝タイム） • 小山駅徒歩8分（Google Maps調べ） • 音響設備がなぜか整っている ◦ アンプだけで100万円ぐらいぶっこんだ ◦ 簡易Dolby Atmos環境 ◦ 将来的には音響部屋にスピーカーを 16台設置するつもり • 現行のゲーム機全部ある ◦ PS5 Proも導入しました • 家賃4万円前後 ◦ ギーク割で5000円安くなる https://geekhouseoyama.vercel.app/
25. シアター12の様子
26. 参考文献 • MySQL docs - https://dev.mysql.com/ • PostgreSQLの新しいバッファ戦略 - https://www.postgresql.jp/sites/default/files/2016-12/20040510143054.tanida_ buffering_040511-1.pdf • 計算の高速化のために必要なこと:メモリの観点 - https://qiita.com/zacky1972/items/25e8157a7593398c9730 • 詳説 データベース - ストレージエンジンと分散データシステムの仕組み（オライリー ・ジャパン） ◦ 画像の引用をさせていただきました • AWSとGCPのドキュメンテーション