🐡

登壇ノート「リレーショナルデータベース入門。後回しにしがちな正規化を学ぼう」

に公開
MySQL
RDB
tech

普段の登壇ではスライドを作っているのですが、実験的に登壇ノートをつくりましたので公開しておきます。

https://nishinomiya.connpass.com/event/355662/

生成AIで行間補完できることを期待したのですが思った以上に私が喋ったことと違うことを（笑）補完するので、箇条書きのままです。次回は録音して録音データをインプットに使うとかしてみたいですね。

イントロダクション

  • プロダクトの寿命を考える

    • フロントエンドは2〜4年
    • バックエンドは3〜8年
    • DBはサービス終了するまでずっと

  • なので、私達フロントエンドの人間は、データを一番信用に扱わないといけない

  • DBの種類

    • 古くはCSV保存
    • WebStorageやSQLite
    • MySQLやPostgresといったRDB
    • Amazon DynamoDBやRedisといったNoSQL

  • RDBだから正規化必須、NoSQLだから正規化してはいけないわけではない

    • 設計思想と、得意とする分野が違うだけ
    • 場合によってはどちらも領域を踏み越えることもある
項目 RDB（MySQLなど） NoSQL（MongoDB、Firestoreなど）
データ構造 テーブル（行・列） JSONライク、キー・バリュー、グラフなど
主な設計思想 整合性と正規化を重視 柔軟性とスケーラビリティを重視
よく使われる手法 正規化してJOINする 非正規化してデータを埋め込む（embed）
JOINの得意さ ◎ 高速＆最適化されてる △ or ❌ JOIN自体ができないDBも
  • 非正規化のメリット
    • パフォーマンスがいい（JOIN不要）
    • データ取得が1回で終わる
    • 分散システムと相性がいい
    • すべてのデータが取得できるので思考放棄できる
  • 非正規化のデメリット
    • データの重複が増える
    • 更新箇所が増えて大変に
    • 柔軟な検索や集計がしにくい（Nested Data）
    • Nested Dataを用いてるとスキーマ管理が難しい
  • 正規化の知識を持って、非正規化を選べるバランスが大切。

正規化の手法

（いろいろ解説してるサイトがあるので割愛）

正規化は計算量との戦い

  • 有名なN+1
  • JOINの計算量は、O(M + N)
    • SELECT * FROM A JOIN B ON A.id = B.id
    • O(M)（ハッシュ作成） + O(N)（一致検索）
  • DBで重要なのは、データをとりにいかないこと、計算させないこと
    • 読み取り専用のリードレプリカ（マスターにはとりにいかない）
    • キャッシュ（Redis/Memcached等）
    • 空間情報の計算はElasticサービスにだしたり
  • データが可用性が高く、変更容易であることと計算量を切り分ける

おわりに

  • リアルをデータに落とし込もう
  • 実世界のデータをDBに落とし込む際のポイント
  • 実践的な設計のコツ

Discussion