Database

In this post, we’ll walk through how Amazon Aurora works under the hood, based on the paper Amazon Aurora: Design Considerations for High Throughput Cloud-Native Relational Databases. Amazon Aurora TL;DR In the cloud era, OLTP databases need both high performance and resilience to failures. Aurora pushes the separation of compute and storage further by introducing a distributed storage service responsible for redo processing and page materialization. Aurora addresses the network I/O bottleneck between compute and storage by sending only redo logs describing changes, instead of writing full pages over the network. How Aurora Achieves Durability In a distributed environment, failures are always happening somewhere, ranging from temporary issues such as slow disk reads or network congestion to permanent failures of disks, nodes, or even an entire data center. A cloud database needs to remain available despite these failures. ...

In this post, I’ll share what I learned from the book Database Design and Implementation by Edward Sciore, which explains how a relational database (RDB) works by guiding the reader through building a simple RDBMS called SimpleDB. My goal is to give an intuitive, top-down understanding of how RDBs work internally. I also hope this post serves as a high-level summary of the book, helping readers grasp the core ideas before diving deeper. ...

『達人に学ぶ DB 設計 徹底指南書』 はリレーショナルデータベース (RDB) の設計についての解説書です. 『達人に学ぶ SQL 徹底指南書』 の続編という位置づけのようなので, 本書に登場する SQL が難しいと思ったり, より SQL のことを学びたいと思ったら前作を読むと良いでしょう. 本書ではデータベースの設計を, エンティティの定義や正規化などを行う論理設計と, データ格納の方法や場所を考える物理設計の二段階に分けて説明します. 設計についての基本的な考え方や知識を抑えつつ, やってしまいがちなバッドノウハウや, 論理設計と物理設計のトレードオフと言った実践的な内容にも踏み込みます. 正規化 データベース設計は大きく論理設計と物理設計という二段階に分かれる. 最初に行う論理設計では, 特定の DBMS(Database Management System) や SQL のことは考えずに, プログラムが扱う対象となる物事の属性や物事同士の関係をモデル化する. 論理設計をするに当たって役に立つのが, データの冗長性や非一貫性を排除するための正規化という方法だ. 正規化を理解するには正規化されていないデータを題材にすると分かりやすい. 例えば以下のテーブルは, 都道府県, 市町村, 市町村の規模を表している. このように分割しておけば先に挙げた問題は起きない. 1 2 3 4 5 6 7 8 9 10 +-----------+-----------+-----------+-----------+-----------+--------+ | pref_code | pref | city_code | city | area_code | area | +-----------+-----------+-----------+-----------+-----------+--------+ | 01 | Aomori | 01 | Hirosaki | 01 | Large | | 01 | Aomori | 02 | Hatinohe | 01 | Large | | 01 | Aomori | 03 | Misawa | 03 | Small | | 02 | Yamaguchi | 04 | Ube | 01 | Large | | 02 | Yamaguchi | 05 | Kudamatsu | 02 | Middle | | 02 | Yamaguchi | 06 | Mine | 03 | Small | +-----------+-----------+-----------+-----------+-----------+--------+ このテーブルには 01 Aomori のように何度も登場するデータがあって冗長だ. さらに, データの整合性が取れなくなる場合があるのが大きな問題だ. 例えば 02 Aomori というレコードがあったら, 県コードと県名のどちらを信用すればよいのか. こういった冗長性や非一貫性を排除するためには, テーブルを分割するのが有効だ. ...