データベース研修【MIXI 26新卒技術研修】

本スライドは、MIXIの2026年度新卒向け技術研修で使用された資料です。
　
MIXI 2026新卒技術研修
『データベース研修』
　
───────────────────────────────
※皆様へのお願い※ 資料・動画・リポジトリのご利用について
───────────────────────────────
公開している資料や動画は、是非、勉強会や社内の研修などにご自由にお使いいただければと思いますが、以下のような場でのご利用はご遠慮ください。
- 受講者から参加費や授業料など金銭を集めるような場での利用
（会場費や飲食費など勉強会の運営に必要な実費を集める場合は問題ありません）
- 出典を削除または改変しての利用

Transcript

1. 26新卒技術研修 データベース研修 DB基礎 ©MIXI
2. 本講義の⽬的 ▪ ⽬的 正式配属後の開発タスクを担当するにあたり、 データベース（DB） に関する必要最低限の知識習得を⽬的とします。 複数ある DB 種類のそれぞれの特性を知り、 最適な DB を選択‧利⽤できる初期段階まで到達することを⽬的とします。 ▪ 背景 あらゆるプロダクト開発で DB は必須といってよいスキルです。 クラウドと相性が良い DB がサービス化しており、モダンなシステム開発には 基本的かつ広い知識が必要となっています。 ©MIXI 2
3. 本⽇の内容 第1章: データベースの基本概念 第2章: 様々なデータベース 第3章: クラウド上のデータベースサービス 第4章: データベースの選定とアーキテクチャ 第5章: セキュリティとデータガバナンス 第6章: データベースとAI 第7章: データベース設計の勘所 ©MIXI 3
4. 時間割 10:30〜11:50 導⼊, 1〜3章 11:50〜12:00 休憩 12:00〜13:30 4〜7章 ©MIXI 4
5. 講義中のふるまい • スマホは⾳が出ないモードでお願いします。 • 急なトイレ等は遠慮なくどうぞ。断る必要はありません。 • 質問したい場合は挙⼿してください。 • 相槌とか感嘆とかのリアクション歓迎です。 • 飲⾷ OK です。ただ、周囲への配慮はお願いします。 ©MIXI 5
6. 自己紹介タイム
7. ⾃⼰紹介 種村尚大（たねむら しょうた） Romi事業部 組み込み/サーバーサイドエンジニア 【学生時代】 • • • • 中東の国際安全保障 (特に情報技術戦略) について学ぶ エルサレムへの留学 42 TokyoでCS / SEについて学ぶ 受託開発 -> 社内情シス -> MIXI内定者インターン 【経歴】 • • • • • • 2019年: 大学入学 2022年: 42 Tokyo 入学 2023年: 大学休学 2024年11月: MIXI内定者インターン 2025年3月: 大学卒業 2025年4月: MIXI入社 【現在】 組み込みソフト, AIモデルの活用における実装, サーバーサイド, インフ ラや最近はロボットのイメージ開発などにも取り組む ©MIXI 7
8. 3つ選んで⾃⼰紹介をお願いします ©MIXI お名前 （必須） 出⾝地 最近⾏った 旅⾏ 私の宝物 趣味 休みにすること 好きな⾷べ物 ペットの話 好きなテック 気になる 出来事 MIXI で やりたいこと 将来の夢 8
9. 第1章: データベースの基本概念 ©MIXI
10. データベースとは データベースは構造化された情報の集合体であり、膨⼤なデータを体系的に格納、検索、 更新ができるように設計されたシステムです。 データベースを操作するためには、専⽤のソフトウェアである データベース管理システム（DBMS）を使⽤します。 DBMS はデータの整合性を維持するための機能を提供し、 複数ユーザーが同時にデータにアクセスしたり、 データを安全に保持するためのセキュリティ機能も備えています。 1980年代にリレーショナルデータベース（RDB）が普及しました。 これは SQL を使って DB へアクセス‧管理‧操作をします。 近年ではニーズの多様化により NoSQL や NewSQL データベースが台頭しています。 ©MIXI 10
11. DBMS の役割 データの格納: データを効率的に格納します。 データの検索: クエリ⾔語を使⽤して、ユーザーが要求するデータを検索します。 データの更新: データの挿⼊、削除、編集を⾏います。 バックアップとリカバリ: データ損失防⽌のためのバックアップ機能と、障害からの復旧を ⽀援するリカバリ機能を提供します。 セキュリティ: データへのアクセスを制御し、不正アクセスや機密情報の漏洩を防ぎます。 マルチユーザーサポート: 複数のユーザーが同時にデータベースにアクセスし作業できるよ うに、競合と整合性の問題を管理します。 ©MIXI 11
12. DBMS の役割 パフォーマンス監視: DB のパフォーマンスを最適化し、効率的な運⽤ができるように⽀援 します。 データの整合性保持: 変更が DB 全体にわたる⼀貫した状態を保つように、制約とルールを 適⽤します。 トランザクション管理: 複数の DB 操作を⼀つの単位として管理し、ACID特性を適⽤して データの整合性を確保します。 データの抽象化: 複雑な内部構造を隠蔽し、ユーザーがより簡単にデータベースと対話でき るようにします。 ©MIXI 12
13. トランザクション データベースのトランザクションとは、データベースに対する⼀つ以上の変更 （データの挿⼊、更新、削除など）を含む⼀連の操作をまとめた単位です。 トランザクションの流れは以下の通りです。 1. 2. 3. 開始: このステップでトランザクションが開始されます。 実⾏: データに対する⼀連の変更が⾏われます。 コミットまたはロールバック: 全ての操作が成功した場合、変更がデータベースに保存されます。（コミット） 操作が失敗した場合は、トランザクション開始前の状態に戻ります。（ロールバック） トランザクションはデータベースの信頼性と整合性を守るために不可⽋であり、 データベースを利⽤する様々な⽤途で重要な役割を担います。 ©MIXI 13
14. ACID 特性 トランザクションは、ACID 特性に従います。 原⼦性（Atomicity）: トランザクション内の全操作は、ひとつの単位として扱われます。 すべて成功するか、あるいはすべて無かったことにするか、です。 部分的な完了は認められません。 ⼀貫性（Consistency）: トランザクションは、データベースのルールに従い、 正しいデータの状態でのみ変更を適⽤します。 独⽴性（Isolation）: 同時に複数実⾏されるトランザクションは、互いに独⽴しており、 他のトランザクションの途中の操作結果に影響を受けません。 耐久性（Durability）: トランザクションが完了し、コミットが⾏われると、その結果は 永続的にデータベースに記録され、システム障害が発⽣しても保持されます。 ©MIXI 14
15. トランザクションの具体例 SNSのプロフィール情報 ユーザーが⾃⾝のプロフィール情報をアプリから更新する。他ユーザーは変更されたプロフィールを⾒る。 はトランザクションスコープ, 書き込み はクエリを表す 読み込み プロフィール プロフィール 閲覧 プロフィール 変更 ©MIXI 15
16. トランザクションの具体例 ECサイトにおける注⽂詳細と注⽂⼀覧 ユーザーが新たに注⽂を追加した際に、システムは新たに注⽂詳細のレコードを作成し、他の注⽂と合わせて今回の注⽂⼀覧と して扱えるように注⽂IDと注⽂詳細IDとを関連づけるレコードを中間テーブルに追加する。 注文詳細テーブル書 き込み 注文一覧テーブル書き込み DB サーバー 注文 ©MIXI 16
17. トランザクションの具体例 ECサイトにおける注⽂詳細と注⽂⼀覧 注⽂詳細の内容を表すデータが追加時にエラーが起きてしまう場合は？ → 原⼦性に従って注⽂詳細の追加失敗時点で処理がロールバックされるべき ？ ©MIXI 17
18. トランザクションの具体例 銀⾏⼝座間の送⾦ 2つの⼝座を持つAさんが⼝座Xから⼝座Yへ100円の送⾦をする。 Xの口座か ら-100 DB Yの口座に +100 サーバー 送金 ©MIXI 18
19. トランザクションの具体例 会議室の予約システム 会議室の予約状況を確認して、空いていれば予約を⼊れる。 空？ 会議室 Y 予約作成 サーバー 予約 ©MIXI 19
20. CAP 定理（ブリュワーの定理） データを格納する複数のノードで構成される分散システムでは、 次の 3 つ全てを同時に提供することはできない（1つ諦める）という考え⽅です。 • • • Consistency（⼀貫性） ◦ どのノードに接続しても、最新のデータ、もしくは、エラーが返る Availability（可⽤性） ◦ 1つ以上のノードがダウンしても、他のノードが応答を返す Partition-tolerance（分断耐性） ◦ ノード間の通信が切断されても動作し続ける OLTP → CA 型（⼀貫性と多様性）が多い OLAP → AP 型（可⽤性と分断耐性）が多い ©MIXI 20
21. インデックス、索引 インデックスは、書籍の⽬次や付箋、ドッグイヤーのようなものです。 データベース内の⼤量データから⽬的のレコードを効率よく取得するための仕組みです。 インデックスの無いテーブル ⾏No. 名前 1 Alice インデックスのあるテーブル A-M N-Z (100万⾏) A-C D-F G-I J-M 100万⾏を総取得して John を探す 100万 N-P Q-S T-V W-Z Bob Alice (more) ©MIXI J-M のなかから John を探すだけで済む David (more) George (more) John (more) Portman (more) Smith (more) Tyler (more) Yoshii (more) 21
22. インデックスの⽋点 インデックスは検索時に有効な機能ですが、インデックスを作り過ぎると DBMS にとって負荷になります。 インデックスはテーブルとは別の特殊なテーブルに索引情報を格納しています。 テーブル内のレコードを追加‧削除するたびにインデックスを最新化しています。 インデックス最新化はコンピュートリソースを使うので、DBMS 全体のパフォーマンスに 影響を与える可能性があります。 また、インデックスもディスクスペースを消費することになります。 必要なインデックスだけを作る、使わなくなったインデックスは削除する、 ⽉に1度、半年に1度しか使わないインデックスなら使う前に作成、終わったら削除などの ⼯夫をすることをお勧めします。 ©MIXI 22
23. データベースのスキーマ設計 データベース全体の構造をどう定義するかを決める設計を、スキーマ設計と⾔います。 具体的には、以下の事柄を決めます。 • • • • • • • ©MIXI どのようなテーブルが必要か 各テーブルにどのようなカラム（列）があるか “主キー”や“外部キー”は何か テーブル同⼠のリレーションは？ 制約（⾮NULL、UNIQUE、外部キー制約など）は？ インデックスは？ その他（namespace分離など） 23
24. スキーマ設計演習 ©MIXI
25. 演習問題 あなたは、メモ帳アプリを開発しています。 要件は以下の通りです。 • • • ユーザーはアプリ上にメモを記録できる ユーザーは⾃⾝のメモを好きな時に参照できる ユーザーは⽬的のメモを探し出すために検索‧並べ替えができる 必要なカラムなどをイメージして、データベースのスキーマ設計をしてください。 なお、データベースにはRDBを使うこととします。 ©MIXI 25
26. 第2章: 様々なデータベース ©MIXI
27. 前提知識 〜 スケールアップとスケールアウト 第2章に⼊る前に「スケール」という⾔葉だけ頭の⽚隅に置いてください。 以下はデータベースでの例です。 スケールアップ（垂直スケール） スケールアウト（水平スケール） 4 vCPU 16 GiB Mem 4 vCPU 16 GiB Mem 4 vCPU 16 GiB Mem 4 vCPU 16 GiB Mem 4 vCPU 16 GiB Mem 8 vCPU 32 GiB Mem Disk Disk Disk インスタンススペックを増やす（大きくする）こと。 リソースが余っていれば比較的容易にアップ可能。 DBMS のパラメータも一緒に変える必要あり。 インスタンス自体を増やすこと。 仕組みができていれば、インスタンス追加だけでスケールするので急激な アクセス増に対応可能。 動的な変更が難しい。システム停止を伴うのが基本。 （工夫して停止時間を最小にする） インスタンス間の同期や整合性が必要。 ©MIXI 27
28. リレーショナルデータベース (RDBMS) RDBMSは1970年代に登場して以来、企業や組織のデータ管理基盤として 広く利⽤されています。 データは⾏と列で構成されるテーブルとして管理され、テーブル間の関連付けにより、 データの重複を避け、⼀貫性のあるデータ管理が可能です。 標準化されたデータベース⾔語 SQL を使⽤して、データの検索‧追加‧削除‧保存を ⾏います。 リレーショナルデータベースの歴史は古く、昔から多くのシステムで利⽤されています。 現代の Web アプリケーションではそれ以外のデータベースの利⽤が増えていますが、 それでもリレーショナルデータベースが完全に無くなる可能性は低いと考えます。 ©MIXI 28
29. RDBMS ACID 特性によりデータの信頼性と⼀貫性を提供していることが RDBMS の特徴です。 ⻑所 • • • ACID 特性をサポート ◦ 信頼性が⾼いトランザクション 複数ユーザーアクセスが可能 ◦ ロック機構により整合性を保つ データ冗⻑の防⽌ ◦ 適切なテーブル設計が前提 ◦ ストレージスペースの節約 短所 • スケーラビリティに難しさ ◦ スケールアップに依存 • データベース構造が複雑になりがち ◦ スキーマ変更が柔軟ではない • メンテナンスの難易度 ◦ データ量に⽐例して難易度も上がる ユースケース オンライン決済、銀⾏取引、在庫管理、CRM、⼈事給与、ECサイト、旅⾏予約サイト、医療システムなど多数 代表的な製品 Amazon Aurora, Cloud SQL, MySQL, PostgreSQL, Oracle Database, Microsoft SQL Server ©MIXI 29
30. NoSQL IoT や AI の急速な進歩によるビックデータ需要の⾼まり、SNS によるよりリアルタイムな データ処理などを受け、NoSQL の利⽤が広まっています。 ⾮リレーショナルなデータベースを NoSQL と呼んでいます。 テーブル同⼠の関係をもって整合性などの優位点を発揮していた RDB と違い、 NoSQL の柔軟なスキーマは迅速で反復的な開発を可能とします。 NoSQL は⽔平⽅向へのスケールアウトが可能で、スパイクアクセスに対応しやすい設計に なっています。 NoSQL製品の多くはこのスケーラビリティを確保するために「結果整合性」を受け⼊れて いるものが多く⾒受けられる。 ©MIXI 30
31. 結果整合性 「強整合性」と対になる概念。 レプリカ間において、データベースに対する新しい書き込みが⽌まった後、⼀定時間後に は全てのレプリカが同じ状態に追いつき、どのレプリカに問い合わせても同じ値が返され るようになるという保証のこと。 ©MIXI 31
32. キーバリューストア キーとバリューのペアでデータが格納されるスキーマレスなデータベースです。 キーに直接アクセスすることで⾼速な読み書きを実現しています。 ⻑所 • • • • シンプルな操作 ◦ API がシンプルで扱いやすい パフォーマンス ◦ ⾼速なデータ構造 柔軟性 ◦ データモデルの変更が容易 拡張性 ◦ 分散アーキテクチャで⾼拡張性 短所 • 複雑なクエリが苦⼿ ◦ 複雑なクエリや JOIN は避ける • 弱い⼀貫性 ◦ 分散アーキテクチャのトレードオフ • トランザクション管理 ◦ 複雑なトランザクションなら RDB ユースケース セッション管理、キャッシュ、ショッピングカート、チャットなどのリアルタイム処理、など 代表的な製品 Redis, Memcached, etcd, Amazon DynamoDB, Cloud Datastore ©MIXI 32
33. ドキュメント データはドキュメント（JSON、XML など）として格納されます。 ドキュメントが⼀纏めに格納されているため、⾼速な読み書きを実現します。 ⻑所 • • • • 開発の効率化 ◦ アプリケーションのオブジェクトと似た データ構造 スケーラビリティ ◦ 分散アーキテクチャで拡張性が⾼い データ表現の豊かさ ◦ 複雑なデータ型やネスト構成が可能 スキーマ変更の容易さ ◦ スキーマフリー 短所 • 集約操作が苦⼿ ◦ JOIN するような⽤途には向かない • トランザクションが限定的 ◦ トランザクション前提な⽤途ではない • 弱い⼀貫性 ◦ 分散アーキテクチャのトレードオフ ユースケース CMS、商品カタログ、ユーザープロファイル、多様なデバイスから多様なデータを受信するケース 代表的な製品 MongoDB, Couchbase, Amazon DocumentDB, Cloud Firestore ©MIXI 33
34. ワイドカラム データはカラムファミリーまたはスーパーカラムと呼ばれる列の集合として格納されます。 カラムへの効率的なアクセスが可能で、⼤量のデータ書き込みと分析が得意です。 ⻑所 • • • • ⼤規模データ運⽤ ◦ ペタバイト規模の分散処理 柔軟なデータモデル ◦ 動的なスキーマ変更が可能 能率的なストレージ活⽤ ◦ 使⽤されるカラムのみ保存される ⾼速なクエリ ◦ カラムへのアクセスや集計が⾼速 短所 • 設計が複雑になりがち ◦ RDB とは異なるアプローチが必要 • 整合性が苦⼿ ◦ ⼀貫性はアプリで保証（したほうが良い） • 独⾃のクエリ ◦ 複雑なクエリや JOIN は苦⼿ ユースケース ビッグデータのリアルタイム処理、リコメンデーションエンジン、⼤量のイベントログ管理 代表的な製品 Cassandra, Google Bigtable, Amazon Keyspaces, ScyllaDB ©MIXI 34
35. インメモリ データをメモリ上に配置し⾼速な読み書きを提供します。 ⻑所 • • 処理速度の向上 ◦ ⾼スループット、低レイテンシー スケーラビリティ ◦ ⽔平スケーリングに対応 短所 • コスト ◦ RAM はディスクに⽐べて⾼額 • データの揮発性 ◦ 電源喪失でデータは消える ◦ データ永続化処理が別途必要 • リソース制約 ◦ ディスクに⽐べるとリソース増が難しい ユースケース キャッシュ、セッションストア、ゲームバックエンド、チャット 代表的な製品 Redis, Memcached, SAP HANA, Apache Ignite ©MIXI 35
36. タイムシリーズ 時系列データの扱いに特化したデータベースです。 時系列クエリの⾼速処理やリアルタイム分析を⾏います。 ⻑所 • • • 時系列処理のパフォーマンス ◦ 時系列の収集‧保存‧分析に特化 データの洞察⼒ ◦ ⾼度な分析機能を有していることがほとんど スケーラビリティ ◦ 分散アーキテクチャの利点 短所 • 汎⽤性は無い ◦ ⾮時系列データには向かない • クエリの制限 ◦ JOIN などの複雑なクエリは不向き • 特殊性 ◦ ニーズを満たすには条件がある ユースケース IoT デバイスデータの収集、⾦融マーケット、メトリクス、ログ 代表的な製品 InfluxDB, TimescaleDB, Amazon Timestream, Google Bigtable ©MIXI 36
37. グラフ データエンティティがネットワーク状の関係を持ったデータの集まりです。 A は B の友達、B は C の友達、C は A の友達の友達、のようなイメージです。 ⻑所 • • • 関係性の深掘り ◦ ネットワーク状関係の探索が速い ◦ 深い関係でも把握しやすい クエリの最適化 ◦ RDB の JOIN に⽐べてパフォーマンスが良い 柔軟性と拡張性 ◦ 関係の追加が容易 短所 • ユースケースが限定的 • 運⽤の難易度 ◦ グラフが⼤きくなると維持管理が⼤変 • 学習の難易度 ◦ 専⾨的な知識が必要なことも ユースケース ソーシャルネットワーク、リコメンデーションエンジン、ナレッジマネジメント、⽣物学的ネットワークモデル 代表的な製品 Neo4j, Amazon Neptune, OrientDB ©MIXI 37
38. NewSQL 古くから広く使われてきた RDB ですが、⽔平スケールに難点がありました。 モダンなアプリケーションは、短時間でアクセスが増えることが当たり前に発⽣し、 スケーラビリティの問題が頭痛の種でした。 Google が RDBMS の特性を維持しつつ、スケーラビリティも兼ね備える Google Spanner をリリースしました。 これに影響‧刺激を受けるように TiDB、CockroachDB などの製品がリリースされまし た。 ©MIXI 38
39. NewSQL NewSQLは、リレーショナルデータベースの利点を維持しつつ、モダンな分散システムアーキテクチャ のスケーラビリティとパフォーマンスを兼ね備えたソリューションです。 ⻑所 • • • • スケーラビリティ ◦ 分散アーキテクチャの利点 ⾼いトランザクション性能 ◦ トランザクション処理の実現 強⼒なデータ整合性 ◦ ACID 特性の維持 リレーショナルデータモデル ◦ 既存データモデルの活⽤ 短所 • 複雑性 ◦ DBMS の管理が難しくなりがち • 成熟度 ◦ まだ新しい技術 • 既存からの移⾏ ◦ 移⾏にかかるコストは無視できない ユースケース ⾦融取引、eコマース、ゲーム、ソーシャルネットワーク 代表的な製品 Google Spanner, TiDB, CockroachDB ©MIXI 39
40. なぜNewSQLが必要なのか RDB 読み込みは分散可能だが、書き込みは1台のマスターノードに集中してしまう。書き込み ノードを増やすと、「どの更新が最新か」、「どのノードを正とするか」決める必要があ り、整合性を担保する仕組みが複雑になる。 NoSQL スケールアウトするが、強整合性を保つには設計が複雑になってしまう 例：リトライ制御、分散ロック、補償トランザクション 強整合性が必要なケース：⾦融（残⾼ズレNG）、ゲーム（課⾦データ）... アプリ側で整合性を頑張るのはつらい → ©MIXI → DB側でスケールまで解決してほしい（隠蔽） NewSQL 40
41. NewSQLが可能にすること NewSQLは以下の組み合わせで実現されている • • • データ分割（シャーディング） ◦ データをキー範囲で分割して並列処理 レプリケーション + 合意形成 ◦ 複数ノードで合意して書き込み（Paxosなど） グローバルな時間管理 ◦ 全ノードで⼀貫した順序を保証（TrueTimeなど） スケーラブルな書き込みが可能 → ノードを増やすことでスループットを伸ばせる（理論上） 強整合性が保証される → 分散合意のもと、⼀貫したデータが保証される ©MIXI 41
42. NewSQL（ざっくりCloud Spannerの場合） イメージ 1つのデータ更新を複数ノードで合意して確定している UPDATE singers SET FirstName = “xxx” WHERE singer_id = 1 Zone X Node-1 Split A Key(1-3) 1. 2. 3. 4. Leader が対象キー範囲にロックを取得 Leader が更新を followerにブロードキャスト follower はロックを取得できたかをリーダーに返す 全体で過半数のロックが取得できた場合、Leader がコミット可能と判断 Zone Y Node-2 Split A Zone Z Node-3 Split A ©MIXI 参考：https://zenn.dev/facengineer/articles/bca8790087b0e4 42
43. NewSQL活⽤事例 TIPSTARではDBにCloud Spanner（Google Cloud）を採⽤しています TIPSTARの技術的特徴 • 競輪レースごとに⼤量の書き込みが発⽣（DBへのスパイクアクセスが頻出） ◦ 1レース毎で数万〜数⼗万件のデータ更新 ◦ ⼤きい賞レースだとレース合計で最⼤100万件以上の書き込み ◦ 朝のレースから深夜のレースまで10〜20分間隔でバースト これらに対し、Cloud Spannerを採⽤することで、、、 データ分割 + レプリケーションをSpannerが担う → 強整合性も維持しつつ⼤量書き込みでも安定して処理可能 複雑な分散処理を意識せずに⼤規模システムを構築できる ©MIXI 43
44. 第3章: クラウド上のデータベースサービス ©MIXI
45. 第3章: クラウド上のデータベースサービス 主要なクラウドベンダーはマネージドなデータベースサービスを提供しています。 今までに紹介したようなリレーショナル、NoSQL、NewSQL も使うことが可能です。 それらデータベースサービスを紹介しつつ、特性についても解説します。 ©MIXI 45
46. AWS が提供するクラウドデータベース データベースのタイプ 例 AWS のサービス リレーショナル 従来のアプリケーション、エンタープライズリソースプランニング (ERP)、カスタマーリレーショ ンシップマネジメント (CRM)、e コマース Amazon Aurora , Amazon RDS, Amazon Redshift Key-Value トラフィックの多いウェブアプリケーション、e コマースシステム、ゲームアプリケーション Amazon DynamoDB インメモリ キャッシュ、セッション管理、ゲームのリーダーボード、地理空間アプリケーション Amazon ElastiCache, Amazon MemoryDB ドキュメント コンテンツ管理、カタログ、ユーザープロファイル Amazon DocumentDB (MongoDB 互換) グラフ 不正検出、ソーシャルネットワーク、レコメンデーションエンジン Amazon Neptune ワイドカラム ⾼スケールの業界アプリケーション、設備のメンテナンス、多数の装置の管理、ルートの最適化 Amazon Keyspaces タイムシリーズ モノのインターネット (IoT) アプリケーション、DevOps、産業⽤テレメトリ Amazon Timestream 『AWS クラウドのデータベース』, 2026年4⽉18⽇, Amazon Web Service, url: https://aws.amazon.com/jp/products/databases/ ©MIXI 46
47. Google Cloud データベース データベースの種類 GOOGLE CLOUD サービス 説明 リレーショナル Cloud SQL 最も柔軟なフルマネージドデータベースサービス AlloyDB for PostgreSQL 優れたパフォーマンス、可⽤性、拡張性を提供する、100% PostgreSQL 互換のデータベース Spanner 常時稼働、グローバルに⼀貫性のある、マルチモデル、事実上無制限のスケールのデータベース Bigtable ⼤規模な⾼スループット、低レイテンシのアプリケーションに最適最も柔軟な NoSQL データベース Spanner Graph 事実上無制限にスケールする Graph データベース Memorystore 完全に管理されたインメモリ データベースサービス AlloyDB AI モデル推論⽤のVertex AIなどの AI ツールや、pgvectorや LangChain などのオープンな標準テクノロ ジーと統合 Cloud SQL モデル推論のためにVertex AIと統合され、gen AI アプリを迅速に構築するためのオープンソースの pgvectorをサポート Spanner 正確な最近傍 (KNN) 検索または近似最近傍 (ANN) 検索を使⽤した検索をサポート NoSQL ベクターデータベース 『Google Cloud データベース』, 2026年4月18日, Google Cloude, url: https://cloud.google.com/products/databases?hl=ja ©MIXI 47
48. マネージドサービスとは？ クラウドベンダーのデータベースサービスの最も分かりやすい特徴は マネージドサービスだということです。 ⼿間がかかる維持管理タスクをクラウドベンダーが実施してくれます。 ©MIXI 『Amazon Aurora アーキテクチャ概要』 , 2026年4月18日, Amazon Web Services, url: https://pages.awscloud.com/rs/112-TZM-766/images/01_Amazon%20Aurora%20%E3%82%A2%E3%83%BC%E3%82%AD%E3%83%86%E3%82%AF%E3%83%81% E3%83%A3%E6%A6%82%E8%A6%81.pdf 48
49. ⾼い拡張性、耐久性、可⽤性 インスタンスとストレージが分離していることで、⾼い拡張性/耐久性/可⽤性を 実現しています。 ©MIXI 『Amazon Aurora アーキテクチャ概要』 , 2026年4月18日, Amazon Web Services, url: https://pages.awscloud.com/rs/112-TZM-766/images/01_Amazon%20Aurora%20%E3%82%A2%E3%83%BC%E3%82%AD%E3%83%86%E3%82%AF%E3%83%81% E3%83%A3%E6%A6%82%E8%A6%81.pdf 49
50. グローバル展開 グローバル展開しやすいこともクラウドデータベースの特徴です。 グローバルスマホアプリの省略図 ⽇本のリージョン App ⽇本 DB DB のレプリケーションが必要 App と DB も 近いほうが パフォーマンスが良い スマホとサーバーは 距離的、NW 的に 近いほうが ユーザー体験が良い - マネージドサービスを使う ⾃前でレプリケーションする スキーマ設計を⼯夫する 北⽶のリージョン 世界中のユーザー 北⽶ App ※ 参考資料：『家族アルバム みてね』 AWSマルチリージョン構成における データベース運用 ©MIXI DB 50
51. スケーラビリティ 第2章で紹介したスケールアップ/スケールアウトでは、インスタンスのサイズや数を 増やすことで性能を向上させていました。 クラウドデータベースのなかには、スループットに応じて性能を変化するサービスがあります。 ユーザーアクセスを予測しにくい Web サービスに最適な⽅式です。 Amazon DynamoDB の場合 オンデマンドキャパシティモード プロビジョンドキャパシティモード テーブルへのリクエスト量に応じて性能が変わります。 次のようなケースで使います。 • リクエストの増減が予測できない • リクエスト量が流動的、波が激しい 性能を管理者が決めます。または、AutoScaling を使います。 次のようなケースで使います。 • リクエスト予測が可能、周期的 • リクエスト増減が限定的 『DynamoDB テーブルのキャパシティモードの評価』, 2026年4⽉18⽇, Amazon Web Service, url: https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/CostOptimizati ©MIXI on_TableCapacityMode.html 『DynamoDB テーブルのキャパシティモードの評価』, 2026年4⽉18⽇, Amazon Web Service, url: https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/CostOptimizati on_TableCapacityMode.html 51
52. 料⾦ 商⽤サービスを開発していくにあたり、”コストへの考慮” は避けて通れません。 パフォーマンスが悪いからといってスケールアウト/アップを単純に⾏うと請求で苦しむことになります。 クラウドデータベースの料⾦特性を理解して使うようにしましょう。 料⾦発⽣要素 例 (AWS) ▪ Aurora （リレーショナル） ▪ DynamoDB （Key-Value） ▪ ElastiCache （インメモリ） インスタンスサイズと台数 ストレージ容量 I/O 発⽣量 バックアップストレージ容量 データ転送量 その他オプションの選択 ※ オンデマンドモード 書き込みリクエスト量 読み込みリクエスト量 ストレージ容量 バックアップストレージ容量 リストアしたテーブル容量 データ転送量 その他オプションの選択 ※ オンデマンド ノードサイズと台数 バックアップ容量 データ転送量 その他オプションの選択 ©MIXI 52
53. クラウドデータベースサービスの注意点 モダンな開発ではクラウドデータベースの利⽤が当たり前ですが、注意点もあります。 • • • ©MIXI コントロールできないクラウドベンダーによるメンテナンス ◦ 機器⽼朽化の対応による再起動 ◦ セキュリティパッチの適⽤による再起動 ◦ マイナーバージョンアップによる再起動 DBMS バージョンのサポート ◦ 古いバージョンはサポートが終わると使えなくなる ◦ 新しいバージョンへのアップグレードを計画 何事も100%ではない ◦ 予期しないフェールオーバー（障害でインスタンスが切り替わること） ◦ 瞬間的なエラー ◦ トレンド⼊りするような⼤規模障害 53
54. ミニクイズ ©MIXI
55. ミニクイズ 1 ACID 特性の正しい組み合わせを選んでください。 ©MIXI 原⼦性（Atomicity） トランザクションはお互いに独⽴しており 同時並⾏実⾏される他のトランザクションの影響を受けない ⼀貫性（Consistency） トランザクション内の操作は⼀つの単位として扱われ ”全て成功” か ”全てなかったこと” の何れかです 独⽴性（Isolation） トランザクションは、データベースのルールに従い 正しいデータの状態でのみ変更を適⽤する 耐久性（Durability） コミットが⾏われるとトランザクションは 永続的に保存される 55
56. ミニクイズ2 ❏ CAP 定理に照らし合わせた場合、OLTP、OLAP それぞれで多く⾒られるパターンは 何でしょうか？ ❏ データの信頼性と⼀貫性を重視したアプリケーションを構築する計画があります。 データベースは何を選べば良いでしょうか？ ❏ 永続性が必要ではないデータに対して⾼速に読み書きをしたい要件があります。 データベースは何を選べば良いでしょうか？ ❏ 先輩社員が「クラウドのマネージドデータベースを使っていれば何もしなくていいか ら楽だよ」と⾔っていました。本当でしょうか？ 注意点があれば教えてください。 ©MIXI 56
57. 休憩 第1章: データベースの基本概念 第2章: 様々なデータベース 第3章: クラウド上のデータベースサービス 第4章: データベースの選定とアーキテクチャ 第5章: セキュリティとデータガバナンス 第6章: データベースとAI ©MIXI 57
58. 第4章: データベースの選定とアーキテクチャ ©MIXI
59. データベース選定⽅法 まず⼀番に考えるのは⽬的やビジネス要件に合致しているかどうかです。 第2章では NoSQL、NewSQL を紹介しました。第3章ではクラウドデータベースを 紹介しました。そこでユースケースや⻑所短所を解説しています。 振り返ってみて選定⽅法を考えてみましょう。 次のページには選択に役⽴つ質問を引⽤しました。選定に迷った際に参考になります。 それでも判断がつかない場合は、PoC を実施します。 本番以外の環境で候補のデータベースを構築し、実施にアプリケーションを動作しながら テストと計測を⾏います。 ©MIXI 59
60. 選択に役⽴つ質問 • • • • • • • • • • データはどのように構造化されていますか。 どのレベルの参照整合性が必要ですか。 ACID への準拠は必要ですか。 ストレージ要件は時間の経過とともにどのように変化しますか。 これにより、スケーラビリティにどのような影響があり ますか。 書き込みクエリに対する読み取りクエリの割合はどのくらいですか。 キャッシングによってパフォーマンスが向上する可 能性はありますか。 OLTP - オンライントランザクション処理 または OLAP - オンライン分析処理 のどちらが優先されますか。 データにはどのレベルの耐久性が必要ですか。 商⽤データベースエンジンやライセンスコストから離れたいという希望はありますか。 データベースには運⽤上どのようなことが期待されますか。 マネージドサービスへの移⾏は主な懸念事項ですか。 データベースへのアクセスは現在どのように⾏われていますか。 アプリケーションアクセスのみですか、それともビジネ スインテリジェンス (BI) ユーザーやその他の接続された既製アプリケーションが存在しますか。 『PERF03-BP01 データアクセスとストレージ要件に最適な専用データストアを使用する』, 2026年4月18日, Amazon Web Services, url: https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/framework/perf_data_use_purpose_built_data_store.html ©MIXI 60
61. データベース選定例 AWS 社が公開しているブログからデータベース選定例を学びます。 使⽤例1 キーバリュー: 製品カタログの使⽤例です。通常、製品には⼀意の識別⼦と 製品名、価格などの属性が含まれています。 ⼀意のキー検索に強い Amazon DynamoDB を選定しました。 使⽤例2 全⽂検索: 顧客が製品カタログを検索するシステムです。 キーワード検索を効率的に⾏える Amazon OpenSearch Service を選定します。（図中は Amazon Elasticsearch） 使⽤例1 の DynamoDB と同期しています。 使⽤例3 インメモリ: ユーザーが購⼊された書籍の「トップ 20」を確認できる ベストセラーリストです。 ユーザーに検索結果を素早く返すために Amazon ElastiCache を 使⽤します。注⽂が⼊るたびに注⽂テーブルからリアルタイムで 更新が⼊ります。 使⽤例4 グラフ: ソーシャルレコメンデーションです。Amazon Neptune を使って 友達が購⼊したものからオススメを⽣成します。 ©MIXI 『Build a Modern Application with Purpose-Built AWS Databases』, 2026年4月18日, Amazon Web Services, url: https://aws.amazon.com/jp/blogs/database/building-a-modern-application-with-purpose-built-aws-databases/?dbd_mod4 61
62. マイクロサービスとデータベース マイクロサービス毎にデータベースを持ちます。データベース製品はマイクロサービスに 合わせて選択します。サービス間の疎結合と独⽴性を確保します。 KVS ECサイトの省略図 Cart DB間のデータは API で取得 Cart DB Front UI ユーザー Inventory Inventory DB WideColumn Shipping Identity Shipping DB RDB BI/分析 DB Session BI/分析 InMemory KVS Identity DB ©MIXI その他たくさん 62
63. API 構成例 前のページで「DB間のデータは API で取得」と書きました。 API でデータを操作するアーキテクチャのシンプルな構成例を紹介します。 Container, Serverless # API仕様書 /user ## 概要 User Microservice User DB クエリを代⾏して レスポンスを返す ## メソッド GET /sales ## パラメータ API Gateway API リクエストを 受け付けるサービス。 URI ごとに捌く。 API キャッシュも可能。 Sales Microservice Sales DB ## レスポンス ### 成功時 ### 失敗時 ## リクエストサンプル ## レスポンスサンプル /order Order Microservice ©MIXI ## パス /user/v1/search Order DB 63
64. コネクションと RDS Proxy アプリケーションから RDB へクエリを発⾏するためにコネクションを張ります。 サーバーレスアプリケーションの場合、多数並列的に起動されるファンクション数だけコネクションが 必要となります。 DBMS 観点だとコネクションはリソースを消費します。過剰なコネクションはそれだけでDBMS の負荷と なり、全体的なレスポンスを遅くする可能性があります。 RDS Proxy はアプリケーションと DBMS の間に⼊り、コネクションプーリングの役割を果たします。 RDS Proxy 無し RDS Proxy 有り Proxy がコネクションを 肩代わりするイメージ ファンクション数の コネクションが必要 ファンクションは 多数並列的に起動 Many Functions ©MIXI DB Cluster プールしている コネクションのうち Available のものを使う DB Cluster Many Functions 64
65. Write と Read を使い分けよう クラウドデータベースサービスの多くは、Write と Read のインスタンスを分離可能です。 アプリケーションロジックで、更新処理は Writer インスタンスへ、 読み取り処理はReader インスタンスへと振り分けます。 インスタンスの負荷が分散‧軽減され、全体のスループットが改善します。 ©MIXI https://pages.awscloud.com/rs/112-TZM-766/images/01_Amazon%20Aurora%20%E3%82%A2%E3%83%BC%E3%82%AD%E3%83%86%E3%82%AF%E3%83%81%E3%83%A3%E6%A6%82%E8%A6%81.pdf より 65
66. シャーディング アーキテクチャの話を少しずれるかもしれませんが、⼤事なテクニックを紹介します。 シャーディングは、⼤規模なデータベースを⼩さな、扱いやすい部分に分割するプロセスです。 これにより、データベースのスケーラビリティとパフォーマンスが向上し、特に書き込みや読み込みの多い アプリケーションにおいて、データ管理の効率を⾼めます。 ▪ 主なシャーティングの種類 □ 範囲ベース 値の範囲に基づいて分割します。（左の例） ⾏No. 名前 1 Alice ‧‧‧ ‧‧‧ 100万 Bob 名前が A〜I 名前が J〜S 名前が T〜Z ©MIXI □ ハッシュ ハッシュ関数を使って⾏にシャードキーを付与 シャードキーで分割します。 □ ディレクトリ ルックアップテーブルを使⽤して、 どのシャードにデータが存在するかを追跡します。 66
67. 分散システムでのトランザクション 単⼀ DBMS のコミット‧ロールバックはそこまで難しくありません。 ただ、現在のシステムはほとんどが分散システムとなっています。 各マイクロサービスが他と連携しながらロールバックをするような実装にします。 トランザクション ECサイトで 買い物をする ©MIXI 在庫App 決済App ポイントApp 発送App 在庫DB 決済API ポイントDB 発送DB 67
68. 分散システムでのロールバック トランザクション ECサイトで 買い物をする 在庫App 在庫引当 在庫DB 補充 在庫App ©MIXI 決済App クレカ 決済 決済API クレカ 返⾦ 決済App ポイントApp ポイント 付与 ポイントDB ポイント 減算 発送App エラー！！ 発送DB ロールバック ポイントApp 68
69. 第5章: セキュリティとデータガバナンス ©MIXI
70. データベースのセキュリティ 第5章ではデータベース内のデータを不正アクセス、損傷、盗難、漏えいから保護するための 対策を紹介します。 ⼀般的にデータベースに格納しているデータの多くは機密性が⾼く、 個⼈情報や財務情報などのデータを含んでいることが多いので、 データベースのセキュリティは極めて重要です。 セキュリティは継続的なプロセスであり、全員参加です。 新たな脅威に対応するために定期的に⾒直しと強化が必要です。 また、データ保護規制や業界基準に準拠することも、データベースセキュリティの 重要な側⾯です。 ©MIXI 70
71. データベースセキュリティの主要概念 • • • • • • • ©MIXI 認証 ◦ ユーザーがデータベースにアクセスする前に、正しい認証資格を持っていることを 要求します。パスワード認証などが代表です。 認可 ◦ 認証されたユーザーに対して、特定リソースへのアクセスを許可‧拒否します。 アクセス制御 ◦ ユーザーが実⾏できる操作の種類（読み取り、書き込み、更新、削除など）を定義します。 暗号化 ◦ 通信時、保管時にデータを暗号化し、不正な盗聴⾏為を防⽌します。 監査 ◦ データベースのアクセスログや操作ログを監視し、不審な活動やポリシー違反を検知します。 データマスキング ◦ 本番環境以外でデータを使う際には、機密データを隠蔽（ダミーに変える）します。 バックアップ‧リストア ◦ データ損失やデータ損害時に早期の回復をするためにバックアップを取得します。 71
72. クラウドの認証 古くからデータベースの認証はパスワードが利⽤されてきました。 ただ、アプリケーションに何らかの形でパスワードを持たす⽅式は、漏洩の可能性を排除できません。 クラウドではシークレットストアを使ってパスワードを保管するようにしましょう。 (1) (2) (3) DB App (1) (3) App から Secrets Store にパスワード問い合わせ 許可された App から許可された操作だった場合、 Secrets Store はパスワードを返す App は返されたパスワードでデータベース認証を⾏う (2) ▪ メリット - 開発者がパスワードを知る必要が無い - パスワードの保護をクラウドの IAM で⼀元管理できる - 定期的なパスワード変更を容易に実装できる - パスワード管理をクラウドベンダーにオフロードできる Secrets Store ©MIXI 72
73. ネットワークの制限 データベースは機密データの集まりです。 データベースにアクセスできるアプリケーション、ユーザーをネットワーク的に制限します。 クラウド パブリックサブネット データベースサブネット クラウド外からのアクセスは拒否 App-A からのアクセスは許可 App-B からのアクセスは拒否 Management からのアクセスは許可 DB App-A 管理サブネット Management 社内管理者 App-B ©MIXI 73
74. 最⼩権限の原則 ネットワーク的な制限はかけました。次はデータベースの権限を制限します。 DBMS の権限では、どのテーブルに対してどの操作（INSERT、DELETE、UPDATE など）を 許可するか、という設定を⾏います。 この権限設定は少しだけ難しいので、アプリケーションユーザーに強い権限（全テーブルに全操作OK）を 付与してしまうことが残念ながら多くあります。それはアンチパターンです。 必要な権限だけを付与するようにしましょう。 App-A にはアプリケーションで使うテーブルに INSERT,UPDATE,DELETE,SELECT を付与 クラウド データベースサブネット パブリックサブネット アプリケーションに関係ないテーブルには アクセスさせない 管理者が強い権限を使う場合は 社内ワークフローで承認をもらう DB 作業時は複数⼈で⾏う App-A 管理サブネット Management ©MIXI 社内管理者 74
75. セキュリティパッチの適⽤ セキュリティパッチは、ソフトウェアやシステムのセキュリティ上の脆弱性を修正するアップデートです。 セキュリティパッチを定期的に適⽤することは、サイバーセキュリティ戦略の基本的かつ重要な部分であり、 攻撃者がシステムを侵害する⼿段を最⼩限に抑えるために必須の習慣です。 そのためには、セキュリティパッチがリリースされ次第、迅速に適⽤することが勧められます。 また、それらの適⽤を継続的に監視し、セキュリティ対策を最新の状態に保つためのパッチ管理ポリシーを 確⽴することが重要です。 クラウドベンダーのマネージドデータベースを使っている場合、セキュリティパッチはクラウドベンダーに よって管理されます。適⽤の内容やタイミングは事前に通知されます。 その通知を⾒て適⽤タイミングを決定し、決⾏します。 セキュリティパッチはデータベースクライアント（アプリケーションなど）にも提供されるケースがありま す。その際には、データベースクライアントにも同じ様に適⽤しましょう。 ©MIXI 75
76. SQL インジェクション SQL インジェクションは、アプリケーションの脆弱性をついて不正な SQL ⽂を混⼊させ、 本来アクセスできないはずのデータにアクセスし、内部侵⼊する攻撃⼿法です。 ▪ 本来の挙動 SELECT id FROM USER_TABLE WHERE id = $ID and password = $PW; id と password が⼀致すると TRUE になってログイン成功 ID ID に⼊⼒した値が $ID、 PW に⼊⼒した値が $PW の変数で SQL ⽂に渡される PW ▪ SQL インジェクション Web 画⾯の ID に 「1′ OR 1=1;」と⼊⼒すると、 Login SELECT id FROM USER_TABLE WHERE id = 1 OR 1=1; and password = $PW; 必ず TRUE になってしまいログインされてしまう ©MIXI 76
77. SQL インジェクションの対策 SQL インジェクションは対策⽅法が開⽰されています。 アプリケーションで必ず対策を⾏いましょう。 • • • • • SQL⽂の組み⽴ては全てプレースホルダで実装する。 SQL⽂の組み⽴てを⽂字列連結により⾏う場合は、 エスケープ処理等を⾏うデータベースエンジンのAPIを⽤いて、SQL⽂のリテラルを正しく構成する。 ウェブアプリケーションに渡されるパラメータにSQL⽂を直接指定しない。 SQL インジェクションに対応したフレームワークを使う。 前段のロードバランサー等に WAF を設置する。 『安全なウェブサイトの作り方- 1.1 SQLインジェクション』, 2026年4月18日, Amazon Web Services, url: https://www.ipa.go.jp/security/vuln/websecurity/sql.html ©MIXI 77
78. 第6章: データベースとAI ©MIXI
79. データベースとAI 第6章ではデータベースと AI の関わりについて話します。 データベースと AI の統合がもたらす可能性について理解を深めます。 世の中の IT システムには既に AI を活⽤したものが数多く存在します。 それらがデータベースをどのように使っているのかは、興味深い題材です。 また、DBMS（データベースマネジメントシステム）⾃体にも AI が組み込まています。 それらの製品を知り、今後のシステム開発に活かしてもらえれば嬉しいです。 ©MIXI 79
80. ベクトルデータベース ベクトルデータベースは、画像、テキスト、⾳声などの⾮構造化データを、 数値のベクトルとして保存‧検索することに特化したデータベースです。 ベクトルデータベースは、AI の進化に伴い、特に重要な役割を果たしています。 データはベクトルと呼ばれる数値の配列として表現されます。 このベクトルは、多次元空間におけるデータの位置を⽰し、意味的類似性を持つ データ同⼠が近くに配置されるように設計されています ベクトルデータベースの利⽤パターン 検索 / レスポンス ベクトルに変換 インデックス⽣成 ⾮構造化データ ©MIXI Embedding Model App Vector Store 80
81. ベクトルデータベースの実践的ユースケース ベクトルデータベースのユースケースを紹介します。 • • • • • ©MIXI パーソナライズされたレコメンデーション ◦ 顧客の閲覧履歴や購買データなどのデータをベクトル化し、リアルタイムで ユーザーに最適な商品を推薦します。 ⾼度なセマンティック検索： ◦ ⽂書データや画像をベクトル化し、意味的に類似した情報を検索します。 RAG（検索拡張⽣成） ◦ ドメイン固有の知識を活⽤し、ハルシネーションを減少させます。 リアルタイム分析 ◦ IoTセンサーデータのような複雑なデータをリアルタイムで分析し、異常検知や詐 欺防⽌に役⽴てます。 不正検知 ◦ データのつながりから⽭盾を発⾒し、不正リスクを軽減します。 81
82. NoSQLデータベースとAI NoSQLデータベースは、その設計思想と特性により、AI に特に適しています。 • • • • ©MIXI 柔軟なデータ構造とスキーマレス設計 ◦ スキーマレスの特性により、AI で必要な多様なデータを扱えます。 多様なデータ形式の処理能⼒ ◦ ⾮構造化、半構造化データに対応 優れたスケーラビリティと分散処理 ◦ ⼤量のリクエストを処理するために NoSQL のスケーラビリティが必須 ⾼速データ処理、リアルタイムデータ処理の対応 ◦ NoSQL の低レイテンシーと⾼スループットは AI と相性が良い 82
83. データベース管理の⾃動化とAI DBMS にも AI が組み込まれている製品があり、管理タスクの効率化を実現しています。 【例】 • • • ©MIXI データベースのプロビジョニング、パッチ適⽤、トラブルシューティングなどの 管理タスクに関するガイダンスをチャットボットで提供 データベースから SQL でデータを抽出、抽出されたデータを基に機械学習を実施、 ⽣成されたモデルを使った推論が可能 Text-to-SQL: ⾃然⾔語で表現されたクエリを SQL ⽂へ変換 「先⽉の◯◯と△△の売上を教えて」 → 「SELECT …」 83
84. ミニクイズ ©MIXI
85. ミニクイズ 3 次の問に答えてください。 1. データベースへの書き込みより読み込みが多いシステムがあります。 クラウドデータベースで実施できる対策を教えてください。 2. ゲーム内で当⽇の成績 Top10 を表⽰するスコアボードを作ろうとしています。 採⽤するデータベースとデータの更新⽅法を考えてください。 3. 新しいプロダクトの⽴ち上げに参加しました。アーキテクチャを検討した結果、 データベースの採⽤に2つの選択肢があります。 最終決定を下すためにすることは何でしょう？ ©MIXI 85
86. ミニクイズ 4 次の問に 正 or 誤 で答えてください。理由も説明してください。 1. ソースコードは厳重に管理しており安⼼なので、 データベースパスワードはコード内に書いた。 2. どうしても動かないロジックがあり、デバッグ⽬的で管理者権限を使って データベースを操作した。 3. セキュリティチェックはセキュリティチームの仕事なので、彼らを信頼し、 とにかく動くことを優先してコードを書いた。 4. プログラム開発で使っているツールに脆弱性が⾒つかりパッチが公開された。 セキュリティチームの案内に従ってツールにパッチを適⽤した。 ©MIXI 86
87. 中締め ©MIXI
88. 第7章: データベース設計の勘所 ©MIXI
89. データベース設計の勘所 明⽇の設計ハンズオン演習向けに、役⽴つ（かもしれない）トピッ クについて触れておきます。 ©MIXI 89
90. スキーマ設計：正規化 テーブルの設計の考え⽅の基本 正規化: 主にヒューマンエラーによるデータ不整合やデータ更新時の不都合などの諸問題を防ぐために⾏われる、データベースの ⼀貫性と効率性を保持することを⽬的とした、データの冗⻑性を排除する取り組みのこと 正規形: 第1から第5まで定義されている、正規化で⽬指すデータ形式のこと (実務ではほとんどの場合第3正規形までを⽬指す) ©MIXI 90
91. スキーマ設計：正規化 第⼀正規形 ⼀つのセルの中には⼀つの値しか含まない ©MIXI user_id name phone 001 test 080-xxxx-xxxx, 090-yyyy-yyyy user_id name user_id phone_id phone_id number 001 test 001 001 001 080-xxxx-xxxx 001 002 002 090-yyyy-yyyy 91
92. スキーマ設計：正規化 第⼆正規形 第⼀正規形 + 部分関数従属の排除 ( = 完全関数従属のみのテーブル) 部分関数従属 = 主キーが複数ある場合 (複合主キー) に、その⽚⽅にのみ依存するカラムが存在する状態 ©MIXI company_id company_name worker_id worker_name 001 com_a 001 test company_id company_name company_id worker_id worker_name 001 com_a 001 001 test 92
93. スキーマ設計：正規化 第三正規形 第⼆正規形 + 推移的関数従属の排除 推移的関数従属 = 主キー以外のカラムに従属するカラムが存在する状態 company_id company_name company_id worker_id worker_name dept_id dept_name 001 com_a 001 001 test 001 dept_a ©MIXI com_id com_name dept_id dept_name company_id worker_id worker_name dept_id 001 com_a 001 dept_a 001 001 test 001 93
94. スキーマ設計：主キー設計 主キーは永遠に不変な値 → ⼀度決めると (ほとんど) 変えられない 常にテーブル内で⼀意な値として扱えるようなデータ型‧形式を選択しなければならない • • • ©MIXI 整数値 ◦ レコードが整数値の限界以上増えた時どうなる？ ◦ AutoIncrementを使⽤する場合にIDを類推できてしまうが問題はないか？ UUIDv4 ◦ パフォーマンス (ソートやインデックスによる検索効率) の問題は？ ULID / UUIDv7 ◦ タイムスタンプを含むため逆算できてしまわないか？ 94
95. スキーマ設計：主キー設計 主キーは永遠に不変な値 → ⼀度決めると (ほとんど) 変えられない 常にテーブル内で⼀意な値として扱えるようなデータ型‧形式を選択しなければならない • ©MIXI 使⽤するDBのプライマリインデックス実装との相性 ◦ クラスタインデックス ▪ セカンダリインデックスからの検索コストは？ ▪ UUIDなどを⽤いた場合のインデックスサイズやINSERTの負荷は？ ◦ ヒープテーブル ▪ 範囲検索のコストは？ 95
96. スキーマ設計：カラムの設計 • • • ©MIXI NULL許容型はできるだけ避けたい ◦ アプリケーションコード側で使いづらいので出来るだけ避けたい ⽇時情報 ◦ できるだけ精度⾼く記録する、 deleted_at本当に必要？ 96
97. インデックス設計 インデックスは クエリ最適化のためのデータ構造 インデックスの本質 インデックスは「テーブル」ではなく「クエリ」に対して設計する • • 検索を⾼速化するためのデータ構造（主にB+Tree） データ量が増えるほど、検索性能の悪化を抑えられる ◦ フルスキャン：O(n), インデックス検索：O(log n) 万能ではない • 読み取りは速くなるが、書き込みは遅くなり、ストレージもインデックスの数だけ増 える とりあえず貼っておくか ©MIXI はアンチパターン 97
98. インデックス設計 インデックスはどんなクエリに効いてくるのか • インデックスが使⽤される可能性が⾼いクエリ ◦ WHERE句 ▪ ◦ 等価検索「=」や範囲検索「<, >, BETWEEN」, 前⽅⼀致検索「 hoge%」 JOIN / ORDER BY句 ▪ 都度ソートを回避できる 効かないパターン • • ©MIXI 後⽅⼀致「%hoge」 関数をかける「WHERE DATE(created_at) = ...」 ◦ 計算を含む条件 98
99. インデックス設計 カラムの並び順を意識する INDEX (A, B, C) WHERE A = ? → WHERE A = ? AND B = ? → WHERE B = ? → 左から順にしか使われない（左端Prefix Rule） 絞り込みが強い順に並べる ⾼カーディナリティ（例：user_id） → 前 低カーディナリティ（例：status） → 後 ©MIXI 99
100. インデックス設計 インデックスに向いているカラム ⼀意性が⾼い（⾼カーディナリティ） user_id, email WHEREで頻繁に使う、JOINに使う 向いていないカラム（低カーディナリティ） 「絞れない‧重い‧よく変わる」はNG status, gender 更新頻度が⾼い サイズが⼤きい TEXT, JSON ©MIXI 100
101. お疲れ様でした ご清聴ありがとうございました ©MIXI 101
102. ©MIXI