参加メモ/中国地方DB勉強会 in 渋谷 - ぜんまい(手巻き式)ブログ

SQLアンチパターンでおなじみの、和田省二さんに会えると聞いて、参加してきました。会場を提供いただいたVoyageGroup様、主催の id:Soudai さんはじめ、参加者の皆様ありがとうございました。

控え目にいって最高の勉強会でした

dbstudychugoku.connpass.com

最近大きめのDB負債と戦っているところだったので、何かヒントが得られるかと思って参加しましたが、いい意味で期待を裏切られました。ブログを書くまでが勉強会ということで、以下メモ。

Postgreの内部構造と監視の話

speakerdeck.com

ふだんMySQL使ってますが、他のDBMSとの比較もありつつ、参考になった。
MySQLの内部構造がわかるようになりたさが増した。
監視の基本: 推測->計測(点で見る)->観測(継続的に見る)
計測に使うライブラリの選定には、企業が作ってるものを選ぶ。
個人が作っているものだと、メンテが突然止まってしまうことがあり、長いスパンで見ないといけないものを計測するにはその方が安心感ある。

pg_stats_reporter読影会

qiita.com

グラフを定期的にみんなで見ながら障害の振り返りや、各種メトリクスグラフの勘所などを共有する試み。
（Mackerelなどのグラフを見るだけだから）事前準備が不要。
2週に1回定期開催してるそう。
良さしかなさそうなので、来週から早速やっていきたい。
監視サービスを複数使う際は、担当範囲の重なりと視点の違いを意識して使う。

和田さんによるデータモデリングの話

データと情報の違い
- データ: 事実。変えようがない。取り損ねたらおしまい。
- 情報: データを加工して取り出したもの
  - アプリケーションで扱うのは「情報」。データベースが扱うのは「データ」

SQLアンチパターン監訳者まえがき xii より

さて、皆さんは「情報」と「データ」の違いをご存知でしょうか。

(中略)

データは唯一無二の事実値ですから、それから作り出される情報はどれも正しく、互いに整合性が取れています。

　もうお分かりと思いますが、「データ」を永続化して蓄えるのに適しているのがRDBであり、それから「情報」を生成するのに適しているのが「SQL」なのです。

「データ」モデリングは論理設計。物理設計で「情報」化を初めて考える。
- 実世界（ドメイン）をデータモデリングすることで、データをつくりだす（RDBに貯める）。SQLを使って「情報」としてとり出す。

データモデリングの話

正規化まで行かないといけないデータモデリング

ERDで森を鳥瞰する。テーブル定義書で木を見る。
Entity: 6W2H(When, Where, Who, What, Why, Whom, How, How much/How many)で表す。
- Event: 定期的に繰り返されるコト。When(これが一番大事), How much/How manyで表されるコト。
  - 事実なので過去しかない。システムに「現在」は存在しない。
- Resource: 登録するモノ。Eventのやつ以外で表されるモノ。
  - 権利や資格など目に見えないモノも含む。
  - 発生〜消滅がある期間。未来開始もあり。消滅時点が未設定もあり。
- Relationship: EventにResourceを供給する
  - EntityもResourceもKeyを持った集合。
  - キー
    - 最近はORマッパーの都合でサロゲートキーが濫用されている。SQLアンチパターン「とりあえずID」を参照のこと。
      - サロゲートキーが登場するのは、代用キー(Alternate Key)が複数のキー項目で構成される場合に、論理的なポインタとして利用する時。
    - 関数従属
    - 多値従属
      - 4NF, 5NFの理解には必須。
        
        Key1が決まれば、Key2, Key3が決まる→4NF
        
        Key1が決まれば、Key2, Key3が決まる。Key2が決まればKey3が決まる→5NF
        
        Key2, Key3だけの集合を作り、一方をPK、もう一方をAKにする→BCNF

時間割を例にした5NF化

クラス(学級)の時間割表なら、x軸に曜日・y軸に時限。
属性として、学級(年度、学期、学年、組番号<これらがAK)、時間割セル(曜日×時限)、学科、担当する教師、授業を実施する教室があるはず。
#chugokudb
— 腹周りたぷたぷ (@hanahiro_aze) August 18, 2018

ここに制限がかかってくる
- 学級によって学科が制限される（文系・理系など）
- 学科ごとに教えられる教師が制限される
- 学科ごとに教室が制限される（音楽室、理科室など）
- 曜日によって開始時間が変わる
- 曜日によって教師の出勤状況が制限される
#chugokudb
— 腹周りたぷたぷ (@hanahiro_aze) August 18, 2018

(学科)--(担当教科)--(教師)
(学科)--(履修科目)--(学級)
(学科)--(使用教室)--(教室)
(学級)--(授業)--(時間割セル)
(時間割セル)--(執務約束)--(教師)
#chugokudb
— 腹周りたぷたぷ (@hanahiro_aze) August 18, 2018

それぞれのエンティティの中間に作ったエンティティで時間割を構成するようにすれば…

鳥肌が立っております！！！！
#chugokudb
— 腹周りたぷたぷ (@hanahiro_aze) August 18, 2018

BCNF以降の正規化は本を読んでも具体的な例が少なくて、今までちゃんと理解できてなかった。というより、理解する努力を怠っていたと言うべきか。反省。

LT

SR(Streaming Replication)+FDW(Foreign Data Wrapper)による集計バッチ
- 集計の計算をマスタから分離したところでやってもらうことで、負荷をかけずに集計処理をするはなし。
MySQL関連のパラメータ(主にInnoDB)について - hiroi10の日記

メルカリのDB分割の話

tech.mercari.com

巨大テーブルからカラムを別テーブルとして切り出す垂直分割
CIで落ちたところが変更後に影響を受けるところだ。というあたりの付け方。
- テストがしっかりあるからこそできる。

次回開催時には何か発表できるようになりたいなぁ。