【イベントレポート】めぐろLT #24 「データベース」 #めぐろLT

いつも記事を読んでいただきありがとうございます！
モブエンジニア（@mob-engineer)です！

今回は2025.02.17（月）に開催しためぐろLT #24 「データベース」へ参加しましたので、アウトプットとしてイベントレポートを執筆しましたので、お気軽に読んで頂ければ幸いです。

誤字脱字、分かりづらい表現に関しては極力なくすように心がけていますが、リアルタイムで執筆しているため、誤字脱字があるかもしれません。

イベントページ

目次

• 概要
• LT
  • 「stored function のすゝめ」
  • 「PostGISを用いた地理空間データベース入門(仮)」
  • 「【PostgreSQL】JSON データを SQL クエリで絞り込みする方法」
  • 「Google Cloud の CloudSQL から AlloyDB へ移行した話」
  • 「PostgreSQLのVACUUMとは」
  • 「AI × A5M2で見える化！～混沌の設計書から奇跡の共有へ～」
  • 「モバイルアプリ開発におけるDBの進化を振り返る」
• まとめ

概要

オフで集まってワイワイしようぜというイベントです！
「めぐろLT」というタイトルですが、特に所属場所は問いません。 今回は、目黒にあるHRBrainで実施します。
駆け出しの方から登壇経験者まで様々な方が集うゆる〜い会にできればと思っています。LT登壇初めての方もぜひお気軽にご参加ください！

LT

「stored function のすゝめ」

参考サイト

• 自己紹介
  • ひとり法人の方
  • みんなのしくじり大賞をを受賞
• Stored Function
  • データベースごとにユーザ関数を定義できる
  • ストアドプロシーシャを利用すれば高度な処理も可能
• メリット
  • アプリとの通信回数を削減
  • 状況に応じてキャッシュが出来る
  • いい感じで利用すればスローSQLを防げる
• 難しさ
  • ソースコードのバージョン管理が厳しい
    • DB Migrationの中に含めるのが吉
  • Unit Testが厳しい
    • 自作のUnit Testを作成するのが吉
• 使いどころ
  • DB上のデータに絡む複雑な処理が何度もあるとき
  • Window Functionが使えない環境でA has many Bのような処理
    • N+1問題への対応がスムーズにいける
• まとめ
  • 使いこなすと、いい感じのデータベース生活が送れる

「PostGISを用いた地理空間データベース入門(仮)」

参考サイト

• 自己紹介
  • ミーちゃんさん
  • 仕事ではGolang/GIS（地理空間システム）のアプリ開発
• 地理空間データベースとは
  • ざっくり言えば、地図が絡んだデータベース
  • 経度緯度を普通のDBに入れてもNG
    • いい感じでチューニングさせる必要がある
  • 利点として位置の比較・演算を行うことが可能
• Dockerでの構築
  • Docker Pull⇒テーブル作成の流れ
  • 座標生成時にユニークなIDが生成される
• まとめ
  • MySQL・Oracle DBでも地理空間DBは開発しているが、一番利用されているのはPostGIS

「【PostgreSQL】JSON データを SQL クエリで絞り込みする方法」

• 自己紹介
  • HRBrain所属の方
  • 人事評価サービスの開発・バックエンドエンジニアのロール
  • 最近はPodcastを聞いている
• 伝えたいこと
  • JSONデータでもSQLデータの絞り込みが可能
  • 過去に開発された機能が廃止されているが、レコードに残っているといった疑惑
  • いったん、データベース設計はスコープ外とする
• JSON型 vs JSONB型
  • JSON型：テキストベースの処理に向いている
  • JSONB型：バイナリベースの処理に向いている
  • 今回はJSONB型を採用
• JSONBでの操作
  • 特定キーの絞り込み、数値条件で絞り込み
  • 使用可能な演算子が多数ある
• まとめ
  • 真偽値処理など幅広く処理できるので広く行うことが出来る
  • JSONに入っているデータでもPostgreSQLなら簡単に絞り込み可能

「Google Cloud の CloudSQL から AlloyDB へ移行した話」

参考サイト

• 自己紹介
  • HRBrain所属の方
  • ドイツ出身の方
  • SurveyチームのBEエンジニアの方
  • 謎解きが趣味だが4連敗中の方
• 移行する理由
  • CloudSQLのHDDをSSDに変えたい
    • 変えるのであればAlloyDBに変えてもいいのでは
    • 社内でも初チャレンジの案件
• 検討した移行方法
  • ファイル利用、CloudSQLのバックアップ、DMSを導入
    • 学習コストを考慮してファイル利用を選択した
• 検証したこと
  • PostgreSQLのバージョンによる互換性確認
  • AlooyDBでのアプリケーション動作検証
  • 切り戻し確認（どのくらい時間が掛かったのかなど）
  • 結果的に無事移行完了した
• まとめ
  • 様々な点で検討・検証を行った
  • データベース移行を完遂したことによる自信が付いた
  • 移行後もDBに関する負荷対応が残っている

「PostgreSQLのVACUUMとは」

参考サイト

• 自己紹介
  • ウォンテッドリー社所属のインフラエンジニア
• VACUUMあれこれ
  • VACUUM=PostgreSQLのイメージ
  • 語源は掃除機
• 追記型アーキテクチャと更新型アーキテクチャ
  • 追記型：削除対象のデータに削除フラグをつけ、追加していく
  • 更新型：削除対象のデータに削除フラグをつけ、そのデータを更新していく
    • VACUUMを実行することで削除フラグデータを整理出来る
    • 基本は自動実行だが、たまに上手くいかない
• 不要データが削除されない場合
  • 大体ロングトランザクションが原因
  • その場合は手動対応を行っていく
• まとめ
  • 自動削除が上手く出来なかったときはロングトランザクションを疑え

「AI × A5M2で見える化！～混沌の設計書から奇跡の共有へ～」

参考サイト

• 開発で一番無駄な時間
  • 設計時の用語すりあわせ
  • 同じ意味を持つ用語が統一されていない
    • 電話番号一つとってもTELL NUMBERなど違いがある
  • せっいつも記事を読んでいただきありがとうございます！
    モブエンジニア（@mob-engineer)です！

今回は2025.02.17（月）に開催しためぐろLT #24 「データベース」へ参加しましたので、アウトプットとしてイベントレポートを執筆しましたので、お気軽に読んで頂ければ幸いです。

誤字脱字、分かりづらい表現に関しては極力なくすように心がけていますが、リアルタイムで執筆しているため、誤字脱字があるかもしれません。

イベントページ

目次

• 概要
• LT
  • 「stored function のすゝめ」
  • 「PostGISを用いた地理空間データベース入門(仮)」
  • 「【PostgreSQL】JSON データを SQL クエリで絞り込みする方法」
  • 「Google Cloud の CloudSQL から AlloyDB へ移行した話」
  • 「PostgreSQLのVACUUMとは」
  • 「AI × A5M2で見える化！～混沌の設計書から奇跡の共有へ～」
  • 「モバイルアプリ開発におけるDBの進化を振り返る」
• まとめ

概要

オフで集まってワイワイしようぜというイベントです！
「めぐろLT」というタイトルですが、特に所属場所は問いません。 今回は、目黒にあるHRBrainで実施します。
駆け出しの方から登壇経験者まで様々な方が集うゆる〜い会にできればと思っています。LT登壇初めての方もぜひお気軽にご参加ください！

LT

「stored function のすゝめ」

参考サイト

• 自己紹介
  • ひとり法人の方
  • みんなのしくじり大賞をを受賞
• Stored Function
  • データベースごとにユーザ関数を定義できる
  • ストアドプロシーシャを利用すれば高度な処理も可能
• メリット
  • アプリとの通信回数を削減
  • 状況に応じてキャッシュが出来る
  • いい感じで利用すればスローSQLを防げる
• 難しさ
  • ソースコードのバージョン管理が厳しい
    • DB Migrationの中に含めるのが吉
  • Unit Testが厳しい
    • 自作のUnit Testを作成するのが吉
• 使いどころ
  • DB上のデータに絡む複雑な処理が何度もあるとき
  • Window Functionが使えない環境でA has many Bのような処理
    • N+1問題への対応がスムーズにいける
• まとめ
  • 使いこなすと、いい感じのデータベース生活が送れる

「PostGISを用いた地理空間データベース入門(仮)」

参考サイト

• 自己紹介
  • ミーちゃんさん
  • 仕事ではGolang/GIS（地理空間システム）のアプリ開発
• 地理空間データベースとは
  • ざっくり言えば、地図が絡んだデータベース
  • 経度緯度を普通のDBに入れてもNG
    • いい感じでチューニングさせる必要がある
  • 利点として位置の比較・演算を行うことが可能
• Dockerでの構築
  • Docker Pull⇒テーブル作成の流れ
  • 座標生成時にユニークなIDが生成される
• まとめ
  • MySQL・Oracle DBでも地理空間DBは開発しているが、一番利用されているのはPostGIS

「【PostgreSQL】JSON データを SQL クエリで絞り込みする方法」

• 自己紹介
  • HRBrain所属の方
  • 人事評価サービスの開発・バックエンドエンジニアのロール
  • 最近はPodcastを聞いている
• 伝えたいこと
  • JSONデータでもSQLデータの絞り込みが可能
  • 過去に開発された機能が廃止されているが、レコードに残っているといった疑惑
  • いったん、データベース設計はスコープ外とする
• JSON型 vs JSONB型
  • JSON型：テキストベースの処理に向いている
  • JSONB型：バイナリベースの処理に向いている
  • 今回はJSONB型を採用
• JSONBでの操作
  • 特定キーの絞り込み、数値条件で絞り込み
  • 使用可能な演算子が多数ある
• まとめ
  • 真偽値処理など幅広く処理できるので広く行うことが出来る
  • JSONに入っているデータでもPostgreSQLなら簡単に絞り込み可能

「Google Cloud の CloudSQL から AlloyDB へ移行した話」

参考サイト

• 自己紹介
  • HRBrain所属の方
  • ドイツ出身の方
  • SurveyチームのBEエンジニアの方
  • 謎解きが趣味だが4連敗中の方
• 移行する理由
  • CloudSQLのHDDをSSDに変えたい
    • 変えるのであればAlloyDBに変えてもいいのでは
    • 社内でも初チャレンジの案件
• 検討した移行方法
  • ファイル利用、CloudSQLのバックアップ、DMSを導入
    • 学習コストを考慮してファイル利用を選択した
• 検証したこと
  • PostgreSQLのバージョンによる互換性確認
  • AlooyDBでのアプリケーション動作検証
  • 切り戻し確認（どのくらい時間が掛かったのかなど）
  • 結果的に無事移行完了した
• まとめ
  • 様々な点で検討・検証を行った
  • データベース移行を完遂したことによる自信が付いた
  • 移行後もDBに関する負荷対応が残っている

「PostgreSQLのVACUUMとは」

参考サイト

• 自己紹介
  • ウォンテッドリー社所属のインフラエンジニア
• VACUUMあれこれ
  • VACUUM=PostgreSQLのイメージ
  • 語源は掃除機
• 追記型アーキテクチャと更新型アーキテクチャ
  • 追記型：削除対象のデータに削除フラグをつけ、追加していく
  • 更新型：削除対象のデータに削除フラグをつけ、そのデータを更新していく
    • VACUUMを実行することで削除フラグデータを整理出来る
    • 基本は自動実行だが、たまに上手くいかない
• 不要データが削除されない場合
  • 大体ロングトランザクションが原因
  • その場合は手動対応を行っていく
• まとめ
  • 自動削除が上手く出来なかったときはロングトランザクションを疑え

「AI × A5M2で見える化！～混沌の設計書から奇跡の共有へ～」

参考サイト

• 開発で一番無駄な時間
  • 設計時の用語すりあわせ
  • 同じ意味を持つ用語が統一されていない
    • 電話番号一つとってもTELL NUMBERなど違いがある
  • 設計書やめないと言う世界
• 自己紹介
  • ジャスミン茶さん
  • 最近はセキュリティに興味関心がある
• 設計書のある世界
  • データベースを生成するために複数の設計書が必要
  • 生成AIを活用したらDDLもいい感じになる
• 実践ポイント
  • フォーマットと命名規則の統一
  • 項目統一にも役立つ
• まとめ
  • 生成AIを活用してデータベースをより楽に作っていく

「モバイルアプリ開発におけるDBの進化を振り返る」

参考サイト

• 自己紹介
  • ソフトウェアエンジニアの方
  • バックエンドはあまり触れていない
  • 趣味はスキー・旅行
• モバイルアプリ開発の進化
  • スマホ初期は省スペック性が重視されていた
  • スマホ中期になってリッチになっていった
• サーバで動かすときとの違い
  • 基本的にデータはローカルで処理しない
  • データ量は多くなく、スケールも必要ない
  • GoogleやAppleの既存システムを利用
• 初期の主流データベース
  • iOS：Core Data
  • （個人的考察）ざっくり言えば軽いデータベース
• モバイルアプリのトレンド
  • 機能性・美しさは強く求められ、開発コストが高くなっていく
  • Worker Threadに順応したデータベースがトレンド
  • iOSであればSwiftData、AndroidはRoom
    • SQLiteの抽象レイヤが利用可能
• まとめ
  • モバイルアプリのデータベースも進化している

まとめ

飛び入りでLT登壇しましたが、楽しかったです。
最後まで、記事を読んで頂きありがとうございました！！