こんにちは、 @kz_morita です。 今回は、『 達人に学ぶDB設計 徹底指南書 ～初級者で終わりたくないあなたへ 』という本を読んだのでその感想などを書いていきます。 書籍について 『 達人に学ぶDB設計 徹底指南書 ～初級者で終わりたくないあなたへ 』という名前の本で、翔泳社から出版されています。 https://www.shoeisha.co.jp/book/detail/9784798124704 目次は以下のようになっています。 第1章　データベースを制する者はシステムを制す 1-1　システムとデータベース 1-2　データベースあれこれ 1-3　システム開発の工程と設計 1-4　設計工程とデータベース 第2章　論理設計と物理設計 2-1　概念スキーマと論理設計 2-2　内部スキーマと物理設計 2-3　バックアップ設計 2-4　リカバリ設計 第3章　論理設計と正規化 ～なぜテーブルは分割する必要があるのか？ 3-1　テーブルとは何か？ 3-2　テーブルの構成要素 3-3　正規化とは何か？ 3-4　第1正規形 3-5　第2正規形 ～部分関数従属 3-6　第3正規形 ～推移的関数従属 3-7　ボイス－コッド正規形 3-8　第4正規形 3-9　第5正規形 3-10　正規化についてのまとめ 第4章　ER図 ～複数のテーブルの関係を表現する 4-1　テーブルが多すぎる！ 4-2　テーブル同士の関連を見抜く 4-3　ER図の描き方 4-4　「多対多」と関連実体 第5章　論理設計とパフォーマンス ～正規化の欠点と非正規化 5-1　正規化の功罪 5-2　非正規化とパフォーマンス 5-3　冗長性とパフォーマンスのトレードオフ 第6章　データベースとパフォーマンス 6-1　データベースのパフォーマンスを決める要因 6-2　インデックス設計 6-3　B-treeインデックスの設計方針 6-4　統計情報 第7章　論理設計のバッドノウハウ 7-1　論理設計の「やってはいけない」 7-2　非スカラ値（第1正規形未満） 7-3　ダブルミーニング 7-4　単一参照テーブル 7-5　テーブル分割 7-6　不適切なキー 7-7　ダブルマスタ 第8章　論理設計のグレーノウハウ 8-1　違法すれすれの「ライン上」に位置する設計 8-2　代理キー ～主キーが役に立たないとき 8-3　列持ちテーブル 8-4　アドホックな集計キー 8-5　多段ビュー 8-6　データクレンジングの重要性 第9章　一歩進んだ論理設計 ～SQLで木構造を扱う 9-1　リレーショナルデータベースのアキレス腱 9-2　伝統的な解法 ～隣接リストモデル 9-3　新しい解法 ～入れ子集合モデル 9-4　もしも無限の資源があったなら ～入れ子区間モデル 9-5　ノードをフォルダだと思え ～経路列挙モデル 9-6　各モデルのまとめ 付録　演習問題の解答 索引 感想など まず、この本を読もうと思ったモチベーションはテーブル設計 (主にマスターテーブル) を行ったときに、うまく言語化できないが使いづらい設計になったためどのあたりに問題があるのか？といった点を明確にしたいという点にありました。

こんにちは、 @kz_morita です。 トランザクション分離レベルについてまとめます。 分離レベルについて 以前の記事 で ACID 特性についてまとめましたが、トランザクション分離レベルは分離性についての概念です。 以下のような種類があります。 直列化可能 (Serializable) スナップショット分離 (Repeatable Read) Read Committed Read Uncommitted 上から順に分離レベルが高いものになっています。分離レベルの高さとパフォーマンスはトレードオフの関係にあります。 また、分離レベルにより以下の問題が発生したりしなかったりします。 Dirty Read Non-Repeatable Read Phantom Read 直列化可能 (Serializable) 直列化可能は、複数のトランザクションが並行で実行されたときでも直列で実行したときと同様の振る舞いになることを保証する分離レベルです。 一番制約が厳しいものですが、パフォーマンスは劣化します。 MySQL の公式には以下のように記載されています。 https://dev.mysql.com/doc/refman/8.0/ja/glossary.html#glos_serializable これは、SQL 標準で指定されるデフォルト分離レベルです。 実際には、この強度が必要になることはほとんどないため、InnoDB のデフォルトの分離レベルは次に厳しい REPEATABLE READ です。 スナップショット分離 (Repeatable Read) Phantom Read は起きるが Non-Repeatable Read と Dirty Read は起きないという分離レベルです。 Nonrepeatable Read (Fuzzy Read) が起きないように、複数バージョンのスナップショットを並行で管理するような仕組みが実装されていて、MVCC (multi-version concurrency control: マルチバージョンへ移行制御) と呼ばれる手法が用いられています。

こんにちは、 @kz_morita です。 トランザクションの ACID 特性についてまとめます。 ACID 特性とは 以下の頭文字を取ったトランザクションの安全性を保証する特性のことです。 Atomicity (原子性) Consistency (一貫性) Isolation (分離性) Durability (永続性) 一つずつ説明していきます。 Atomicity トランザクションが原子 (Atomic) のようにそれ以上分割できない単位になっていることを指します。 トランザクションは、開始されたら commit され正常に終了するか、rollback され中断、破棄されるかのどちらかのみとします。 トランザクションが実行前か実行が完了している状態のどちらかのみのため、アプリケーションは失敗したらリトライすればよくシンプルになります。 SQL でいう、BEGIN ~ COMMIT, BEGIN ~ ROLLBACK は Atomic な単位を宣言するために使われる構文ということになります。 Consistency データが満たすべき制約や整合性が、トランザクションの実行中でも満たされているような性質です。 制約や整合性は、定義されたスキーマ通りのデータであったり、外部キーなどの制約、論理的な制約などになります。 一貫性は、データベースが保証できるものではなく、トランザクションを開始するアプリケーションが保証するものになります。 Isolation 並行して実行されている別のトランザクションとお互いが分離されているような性質です。 分離性にはいろいろなレベルがあり、一番強いレベルの分離性を持つのが、直列化可能性 (Serializability) とよばれるものです。 これは、トランザクションを直列に実行した場合と同じ結果となるように振る舞うような分離レベルになります。 他にも スナップショット分離 や、Read Committed などの Serializability よりも弱い分離レベルがいくつかあります。 （別でまとめようと思います） Durability トランザクションがコミットされたら、データが失われずに永続化される性質です。 データベースが分散しているかどうかで若干意味が変わります。単一のDBの場合はディスクに書かれたこと（リカバリ用の write-ahead ログなども含む）が、分散されているストレージの場合は、一定数のノードにレプリケーションされているといった形です。 ACID 特性を満たさないものについて ACID 特性を満たさないシステムを BASE と呼ぶそうです。 BASE は以下の頭文字です。

こんにちは、 @kz_morita です。 今回は、データベース内のデータの保持の仕方として、行指向、列指向、ワイドカラムストアについてまとめます。 データレイアウトとは DBMS 内で一連のデータどのようなまとまりで保持するかについてです。 以下の3つに分類できます。 行指向データレイアウト 列指向データレイアウト ワイドカラムストア 行指向データレイアウト データを行・レコード単位で格納します。 ID, Name, Email, Type を持つようなデータの場合以下のような単位でデータが格納されます。 - User1: 1, "Hoge", "hoge@example.com", "ADMIN" - User2: 2, "Fuga", "fuga@example.com", "NORMAL" - User3: 3, "Piyo", "piyo@example.com", "NORMAL" 通常のWebサービスのユーザーテーブルのようにデータの1行ごとにアクセスするようなワークロードの場合、一緒に扱うデータがより近く保存されるため効率が良くなります。（空間的局所性） しかし、大量のデータから特定の列だけ抜き出して分析するようなワークロードの場合一度全ての列のデータをディスクから取得したのちにフィルタするため多少効率が悪くなります。 MySQL などが該当します。 列指向データレイアウト データを列・垂直方向の単位で格納します。 ID, Name, Email を持つようなデータの場合以下のような単位でデータが格納されます。 - ID: 1, 2, 3 - Name: "Hoge", "Fuga", "Piyo""" - Email: "hoge@example.com", "fuga@example.com", "piyo@example.com" - Type: "ADMIN", "NORMAL", "NORMAL" こちらは例えば Type = ADMIN のユーザー数を数えるなどといった多くのレコードに対して集計をするようなワークロードの場合に向いています。 Type がまとまってストレージに配置されるので空間的局所性が改善されます。

こんにちは、 @kz_morita です。 今回は、データベースについてざっくりとどんなものがあってどのように分類されているのかをまとめます。 データベースの分類方法 データベースには、調べた限りだといくつかの分類方法があります。 しかしそれらは完璧に分類できるわけではなくDBMS (Database Management System) によっては A という 要素 と B というを兼ね備えたものといった具合に境目が曖昧なものも存在します。 いくつかの分類を紹介します。 リレーショナル, NoSQL, NewSQL 最初の分類は、以下の３つによる分類です。 リレーショナル DB (RDB) NoSQL NewSQL RDB RDBは、一番広く普及されているデータベースです。 データは行と列で構成されたテーブルとして表されます。 テーブル同士の関係 (リレーション) に対して、SQL を用いて操作をおこなうのが特徴です。 RDB は、Schema on Write なので、書き込む際に特定のスキーマのみを受け付けることからデータが対象のスキーマを満たしていることが保証されます。 また、RDB には ACID 特性 (Atomicity: 原子性, Consistency: 一貫性, Isolation: 独立性, Durability: 耐久性) があります。 Atomicity により、トランザクションは必ず完全な実行か実行されないかのいずれかになります。Consistency によりデータはデータベーススキーマに従うことが保証されます。Isolation により同時に発生したトランザクションは独立して実行されます。Durability によりシステムの予期せぬ障害でも異常の発生前の状態まで復旧できます。 RDBでは、上記の ACID 特性をもったトランザクションをサポートしているため、書き込みを分散させる (水平スケーリング) させることは難しいです。 代表的な DBMS に以下のようなものがあります。 MySQL MariaDB Amazon Aurora Oracle SQL Server PostgreSQL Amazon Redshift IBM DB2 NoSQL NoSQL (Not only SQL) は、RDBのような表形式で関連を扱うデータモデルではなく、主に単一のキーと値、もしくは JSON ドキュメントとして保存されるものです。