失敗から学ぶRDBの正しい歩き方 / 曽根壮大

著者: 曽根壮大
読了日: 2022/04/29
出版日: 2019/02/27

読み返したい章

2章: 失われた事実
4章: 効かないINDEX
5章: フラグの闇
10章: 転んだ後のバックアップ
16章: キャッシュ中毒

感想、まとめ

例が分かりやすくて想像しやすい。想定するレベルはDBを使った簡単なアプリケーションの構築経験+多少正規化などもしたことがある、という程度だと思う。「レプリケーション」「外部キー制約」とかの単語を聞いたことがある、というのが最低条件？

ただ、DB使ってWebアプリケーション作ったことある人だったらだいたい理解している内容だった。正規化はしようね、とか制約は使おうね、とか監視はしようね、とか。前提知識としてRDBを使った経験が求められていそうなのにも関わらずベストプラクティス的な、初歩を説明しているのでターゲットがイマイチ分からない。日頃RDB触っている人は言われずとも実践していそうだし、触ってない人は門前払いを食らいそうな内容だし。

ベストプラクティスを知り、ベストプラクティスに従う。が一番大事なこと。

以下読みながら書いたざっくりとしたまとめ。推敲なし。

1章

1章の例、想像できたり見に覚えがあったりする部分が多いのでよい(？)

一度雑な設計をしてしまうと割れ窓的にその設計が他でも使われ始めてそのうち身動きが取れなくなるからコツコツと直しながら進もうね、という話。

2章

要約　履歴が必要なデータかどうかの見極めはしっかりすべき。

「今ある事実のみを保存してしまうと過去の事実を失ってしまう」イミューダブルにデータを保存すると変更履歴が残って嬉しいよね。

履歴いらないと思って設計するとあとから履歴ほしいと思った時に無いものは無いので遅延レプリケーションやログをElasticsearchとかに投げるなどしておくと良い。

3章

各種JOINの説明の図、今まで見たものの中でもすごく分かりやすい。

JOINの処理は対象テーブルが増えれば増えるほど急激に重くなるけど、INDEXを貼れば軽くなる。

JOINのアルゴリズムには3種類あって、MySQLは1つしかサポートしてないけどPostgreSQLは他のアルゴリズムもサポートしている。そのためPostgreSQLは大きなテーブルのJOINや不等号を使ったJOINが得意。

マテビュ、自分で使ったことがまだない。ちょっと調べてみる。いやよく考えたら使ったことあった。

4章

実行計画、見たことない。

BTree INDEXを使った参照の仕組みが簡単に書かれている。分かりやすい。

INDEXは検索結果がテーブルの20%未満、対象テーブルが数万から数十万行と十分大きいこと、という条件でなければ使用されない。知らなかった。

条件句にも注意が必要。WHERE age*10 > 100ではINDEXが使われない、

age > 100/10なら使われる。へー。

こういうのもINDEXを使えるようにするため、PostgreSQLには式INDEXというものがある。

LIKE検索では前方一致(LIKE ‘hoge%’)でしかINDEXは使われない。後方一致したいのであれば保存時にreverse()をかけるなどの工夫が必要。

『RDBMSは「今のデータ情報をサンプリングした統計情報」をもとにオプティマイザが判断しています。』p52

WHERE狙いのキー、ORDER BY狙いのキー、というスライドがいいらしい

5章

ブログ投稿システムがあるとする。ユーザーにも記事にも削除フラグが使われている。現在有効な記事一覧を出そうとするとuserをjoinして削除フラグを見て…みたいなことになる。更新時も削除フラグを変更して追加insertしていくタイプだとタイトルとユーザーIDのユニークキーは貼れなくなる。いろいろ問題がある。

うーん、イミュータブルな追記型設計だと確かにユニーク制約付けられないな。

案として削除テーブルを作る、が書いてある。これもなあ…

状態が削除だけならいいけど更新、予約、下書き、みたいに複数あるとまたややこしい。

うまい解決策は書いてなかった。