22新卒技術研修で実施したデータベース研修（データベース基礎編）の講義資料です。 動画：https://youtu.be/dseGQ2MZF1U
SQL演習編 https://speakerdeck.com/mixi_engineers/2022-sql-training
22新卒研修データベース研修2022.04.211
View Slide
本日のお品書き• 10:40~11:27 座学-データベース基礎 (講師: 渡辺)• 11:40~12:50 SQL演習 前半 (講師: 北島)• 12:50~13:50 昼休憩• 13:50~14:35 SQL演習 後半 (講師: 北島)• 14:35~14:45 小休憩• 14:45~17:00 分析チャレンジ演習 (講師: 渡辺・北島)2
講師紹介• 渡辺 大貴 (Taiki Watanabe)• 20新卒 モンスト事業本部ゲーム運営部解析G• 北島 祥伍 (Shogo Kitajima)• 19新卒 モンスト事業本部ゲーム運営部解析G3
座学 - データベース基礎4
データベース基礎 目次I. データシステム基礎1. なぜデータベースを学ぶのか2. データシステム3. データモデル4. データベース管理システム5. エンコーディングと進化Ⅱ. 分散データの取り扱い6. レプリケーション7. パーティショニング8. トランザクション5
I. データシステム基礎6
1. なぜデータベースを学ぶのか• 演算指向からデータ指向へシフト• CPU処理能力ではなく、データの量や複雑さ、変化がボトルネックになる時代• データベースはアプリケーションに比べて後から変更しにくい• 安易なデータモデル・DBMSの選定はビジネス要件とのミスマッチにより開発、運用段階で苦労するリスク大=> トレードオフを理解したデータシステムの適切な技術選定の必要性7
2. データシステムデータシステム設計の機能要件と非機能要件8
2. データシステムアプリケーションを”良く”保つためには機能要件と非機能要件どちらも欠かせない機能要件• データの保存・検索（DB)• よく参照されるデータの記憶（キャッシュ）• キーワード検索非機能要件• 障害発生時もデータが正しいことを保証したい（信頼性）• 負荷増大に対応したい（スケーラビリティ）• 安定したパフォーマンスを提供したい（メンテナンス性）9
2.1 信頼性「何か問題が生じたとしても正しく動作し続けること」• 問題を起こしうるもの : フォールト(fault)• フォールトを見越してこれに対処できるシステムは耐障害性を持つ(fault tolerant)という• フォールトに耐性がないと障害につながる• 意図的にフォールトを発生させて耐障害性の仕組みを継続的にテストする => カオスエンジニアリング10
2.2 スケーラビリティ「負荷の増大に対してシステムが対応できる能力」• スケールアップ: マシンを強力に• 垂直スケーリング• スケールアウト: 負荷分散• 水平スケーリング• one-size-fits-all なアーキテクチャは存在しない11１TB 3TB スケールアップ１TB １TB x ３ スケールアウト
2.3 メンテナンス性「メンテナンスのしやすさ」メンテナンス性を高めるための設計原則1. 運用性• 健全性を可視して効率的な管理方法で運用しよう2. 単純性• 複雑なシステムはメンテナンスのコストを増大• 抽象化でクリーンなアーキテクチャを保とう3. 進化性• システムの修正容易性• 単純性の高さだけでなく, 開発技法も影響12
3. データモデル実世界を抽象化する手段13
3. データモデル「実世界を抽象化するための手段」• データベース世界の汎用的なデータモデル• リレーショナルデータモデル• オブジェクト指向(ドキュメント)モデル• ネットワークデータ(グラフ)モデル• ソフトウェアのできること/できないことに大きな影響を及ぼす• アプリケーションに適したデータモデルを選択することは重要14
3.1 リレーショナルデータモデル「SQL≠リレーショナルモデル」• 数学的で徹底的にフォーマルなデータモデル• 集合論に基づいてデータを表現• 高度に抽象的(実装に無関心) => データ独立性• データモデルは原理• 原理：根源、本質的な性質、基礎• 製品や技術は変化するが原理は持続力がある• リレーショナルモデルの３要素• 構造：リレーション、順序なしタプルの集合• 操作：集合操作と論理述語• 整合性：常に満たしていなければならない式15
3.1.1 クエリ言語• データの問い合わせ(Query)の手段 => クエリ言語• 宣言的なクエリ言語はDBエンジンの実装の詳細を隠蔽• クエリの書き換えなしにDBシステムのパフォーマンスを改善できる• クエリ言語：SQL, MapReduce, CypherなどSQL• リレーショナルモデルを設計基盤として開発された宣言型クエリ言語• 集合を基本のデータ構造とする• OOMとはデータ構造の違い(インピーダンスミスマッチ)が存在16
3.2 ドキュメントモデル「データをJSONとして保存」• スキーマを強制しない• ローカリティ(局所性)に優れている• 関連情報が一箇所に集まっている• 一対多のツリー構造では結合が必要がない• 結合のサポートは弱い• OSS: MongoDB, CouchDB, RethinkDB• Cloud: Firebase Firestore17MongoDBにおけるデータの挿入と抽出> db.users.find(){"_id" : ObjectId("60e..."),"name" : "22新卒くん","age" : 21}> db.users.insert({"name": "22新卒くん","age": 21})
3.2.1 Schemaスキーマオンリード• データベースがスキーマを強制しない• データ構造は暗黙 => 読み取り時に解釈スキーマオンライト• スキーマを明示• 書き込み時にスキーマに従っていることを保証• スキーマの変更にマイグレーションが必要18
4. データベース管理システムDBMS - DataBase Management System19
4. データベース管理システム(DBMS)「DBMSはクライアント/サーバーモデル」- 右図はDBMSのアーキテクチャの例- 製品によってはモジュールの付け替え可- 特にストレージエンジンは保証するトランザクションのレベルに大きく影響(後述)- 大きく分けて2種類の用途がある1. トランザクション処理用途(OLTP)2. 分析処理用途(OLAP)20クライアントリクエスト(Query)/レスポンスDBMSクエリプロセッサ実行エンジンストレージエンジン- クエリパーサ- クエリオプティマイザ(Output: クエリ実行計画)(実行計画を処理 )- トランザクションマネージャ- ロックマネージャ- アクセスメソッド- エンドユーザー- アプリケーションプログラムDBMS アーキテクチャの例
4.1 OLTP ( Online Transaction Processing )• エンドユーザーとやり取りするインタラクティブな用途で利用• ランダムアクセスと低レイテンシーな書き込みが求められる• 大量データから特定の値を効率的に見つけることが得意• => インデックス• OLTPで主流のストレージエンジンは2つ1. Bツリー系: update-in-place. 最も一般的.2. log-structured系: ファイルへの追記と削除のみ.21
4.2 OLAP ( Online Analytic Processing )「結果がビジネスインテリジェンス(BI)のために利用される」• 分析用途のクエリーは高負荷&データセットの大部分をスキャン• パフォーマンスへ大きく影響• 分析用途に特化した独立したDB：データウェアハウス• データウェアハウスはリードに最適化. データのスキャン範囲を抑える工夫.• => 列指向22
4.2.1 列指向「列に含まれるすべての値をまとめて保存」• データウェアハウスは列指向• 集計処理の際、必要な列のデータのみ取り出せる• SELECT AVG(age) が強い• SELECT * で全データスキャン• 圧縮しやすい• カーディナリティ(濃度)が低いならビットマップエンコーディングなどが有効• 書き込みは苦手23name ageMike 25Alice 23John 21列方向にデータを保存イメージ↓name file contents: Mike,Alice,Johnage file contents: 25,23,21
5. エンコーディングと進化24
5. エンコーディングと進化「アプリケーションの変化に伴い、データも変化する」エンコーディングによって互換性を担保• エンコーディング• 「インメモリの表現からバイトの並びへの変換」• メモリ内のデータの持ち方とメモリ外でのデータの持ち方は異なる• 後方互換性• 古いコードによって書かれたデータを新しいコードが読める• 前方互換性• 新しいコードによって書かれたデータを古いコードが読める• 難しい25
5.1 データエンコーディングフォーマットの種類1. プログラミング言語固有のフォーマット• java.io.Serializable, pythonのpickleなど• 他プログラミング言語との互換性が(ほぼ)ない2. 標準化されたフォーマット• 多くのプログラミング言語で読み書きできる• テキストフォーマット: JSON, XML, CSVなど• バイナリフォーマット: Thrift, Protocol Buffers, Avro26
5.1.1 テキストエンコーディングの種類• JSON, XML, CSVなど• テキストなのでデータサイズが大きくなりがち• スキーマは組み込まれていない• 好きなスキーマでデータを格納できる• 合意形成がなされていれば問題は発生しない• 「ただし、それが何であれ、何かについて複数の組織間が合意するのは難しい」27
5.1.2 バイナリエンコーディングの種類「テラバイト級のデータを扱うために開発されたデータエンコーディング」• Apache Thrift (Facebook), Protocol Buffers(Google), Apache Avroなど• スキーマを必要とするエンコーディング• スキーマ情報はドキュメントやコードの自動生成にも利用可能• JSON, XML用のバイナリエンコーディングもある• JSON用にはMessagePack, BSONなど• XML用にはWBXML, Fast Infosetなど28
Ⅱ. 分散データの取り扱いレプリケーション, パーティショニング, トランザクション29
6. レプリケーション「複数のマシンに同じデータのコピーを保持しておくこと」レプリケーションの目的1. レイテンシを下げる2. 障害があってもシステムを動作させる (可用性の向上)3. スケールアウトさせる (スループットの向上)大きく分けて3つのアプローチ- シングルリーダー(Leader), マルチリーダー, リーダーレスレプリケーションにおけるトレードオフ- 同期的か非同期か- 障害を起こしたレプリカの扱いをどうするか30Amazon RDSにおけるレプリケーションのイメージ引用：「Amazon RDS リードレプリカ | クラウドリレーショナルデータベース| アマゾン ウェブ サービス」https://aws.amazon.com/jp/rds/features/read-replicas/
7. パーティショニング (シャーディング)31「データを分割して保存」• スケーラビリティ向上が主な目的• クエリの負荷分散• “良い”パーティショニングはデータとクエリの負荷をノード間で均等に分散させる• 偏りがある状態：skew• 負荷集中しているパーティション：ホットスポットアルファベットでパーティショニングする例引用：「Data partitioning guidance - Best practices for cloud applications | Microsoft Docs」https://docs.microsoft.com/en-us/azure/architecture/best-practices/data-partitioning
8. トランザクション32「複数の読み書きを一つの論理的な単位としてまとめる方法」• 「プログラミングモデルをシンプルにする」という目的で生まれた• 全体として成功 or 失敗• 成功 (commit:コミット) , 失敗 (abord:中断, rollback:ロールバック)• 一部の操作だけ成功という状態は存在しない• トランザクションが保証する一貫性の強さとパフォーマンスはトレードオフの関係にある• =>トランザクション分離レベル
8.1 トランザクション分離レベルとは33「あなたのトランザクション分離性は何を保証しているか」• 理想は並列で実行しても直列で実行した時と同じ結果になること• しかし、パフォーマンスの問題からある種の並行性問題のみを対処する弱い分離性が提供されているa. Read Commitedb. Snapshot Isolation (Repeatable Read)c. Serializable
8.2 トランザクション分離レベルの種類34Read Commited• ダーティリード, ダーティーライトが発生しないことを保証a. ダーティーリード: コミットされていないデータが見れてしまうことb. ダーティーライト: コミットされていないデータを上書きすることSnapshot Isolation (Repeatable Read)• トランザクション中に他トランザクションによる変更を読み取らないことを保証.• nonrepeatable read (read skew) が発生しないSerializable• すべての更新不整合を回避. ただしパフォーマンスが悪い.
座学ENDお疲れさまでした！35
参考文献36• O'Reilly Japan - データ指向アプリケーションデザイン
mixi_engineers
disconinja
tomokusaba
ivargrimstad
hitsuji1991
nrslib
kamilahsantos
zerebom
aridlehoover
zakky21
kasacchiful
uhooi
techouse
paigeccino
mojombo
malarkey
hatefulcrawdad
dotmariusz
bkeepers
tanoku
jnunemaker
garrettdimon
lara
cassininazir
trishagee