[System Design] 系統設計 (2) -- 數據庫設計

Database

Intermediary:

Memory -- In-memory DB(H2)
SSD (Flash)
Disk

Param:

IOPS
Latency
Throughput
Capacity -- persistence

Utilization: Search, Retrieval,

WHY NoSQL: Large Data → Large Box/Server → More small boxes

Distributed DB: sharding (DB) → Read: Replication/Caching → Write: LSM Tree

Solved: Scalability
Not Solved:

Query Language
Secondary Index: Primary Index is global, and Secondary Index in local(need to be created);
ACID transaction
Trust and Confidence

Database Categories:

Relational DB

NoSQL -- Twitter 2009 accidentally created a tag #nosql for event

Key-value style approach: Redis, Dynamo

Impl: persistent HashMap
Aggregate: value

Document style approach: MongoDB, CouchDB

JSON format Document → Document ID → Transparent
Aggregate: document

Column-family: Google Bigtable, HBase, Cassandra

Row-key → column family
Column family = key + value
Aggregate: column family

Graph style approach: Neo4j //different from a,b,c

Aggregate-Oriented DB

You can easily pull individual column/document/value back and forth about the case
Store the whole thing -- Atomicity
You can distribute the data by placing different aggregates on different nodes
Design Trade-off

CAP Theorem, which comes from ACID(Relational DB)

Consistency: Single Threading + Async
Availability: Every request must be processed
Partition
What we want: shortest latency and highest consistency

Choice

Only one search type: AODB (same aggregate)
Solution: Map-reduce
More searches: RDB

http://www.cnblogs.com/fxjwin...

--	IOPS	Latency	Throughput	Capacity
Memory	10M	100ns	10GB/s	100GB
Flash	100K	10us	1GB/s	1TB
Hard Drive	100	10ms	100MB/s	1TB

Flash - lifetime IO limitation
Hard Drive - Mechanical seeking

延時: Latency = 1 second / IOPS
頻率: IOPS

IOPS和Throughput並無直接的關係，通常而言，Throughput不會限制IOPS。
IOPS是操做次數的頻率，Throughput是吞吐量。

ACID

ACID，是指數據庫管理系統（DBMS）在寫入/更新資料的過程中，為保證事務（transaction）是正確可靠的，所必須具備的四個特性：原子性（atomicity，或稱不可分割性）、一致性（consistency）、隔離性（isolation，又稱獨立性）、持久性（durability）。

四大特性

原子性：一個事務（transaction）中的全部操做，要麼所有完成，要麼所有不完成，不會結束在中間某個環節。事務在執行過程當中發生錯誤，會被回滾（Rollback）到事務開始前的狀態，就像這個事務歷來沒有執行過同樣。
一致性：在事務開始以前和事務結束之後，數據庫的完整性沒有被破壞。這表示寫入的資料必須徹底符合全部的預設規則，這包含資料的精確度、串聯性以及後續數據庫能夠自發性地完成預約的工做。
隔離性：數據庫容許多個併發事務同時對齊數據進行讀寫和修改的能力，隔離性能夠防止多個事務併發執行時因爲交叉執行而致使數據的不一致。事務隔離分爲不一樣級別，包括讀未提交（Read uncommitted）、讀提交（read committed）、可重複讀（repeatable read）和串行化（Serializable）。
持久性：事務處理結束後，對數據的修改就是永久的，即使系統故障也不會丟失。

設計用戶系統 - 需求

S 支持哪些操做：註冊，登陸，查看信息

N

讀寫頻率：

• DAU = 1M, 每秒平均登陸數 = 1M * 2 queries per day / 86400seconds = 25 QPS

• Peak = 25 * 2 = 50 QPS
  數據量：

• 1M * 10KB = 10GB

A 獨立小系統：Web-DB 2-tier setup

K 存哪些數據：密碼，基本信息；單機SQL

數據模型

Data Model - Basic Objects

Tweet Table
post_id	content	user_id

Relations & Foreign Key

誰讚了個人貼？
Add user list column in post table?（幼稚的作法）
Implementation:

Select users.user_id, users.name
From likes
Join users
On likes.user_id = users.user_id
Where likes.photo_id = 9

我讚了哪些貼？在user table也加post list column？
Scalability: 1M用戶讚了一個貼以後，每一個新贊都得把整個list讀出再寫回去。

索引 Index

實現快速查找。例如，用users.user_id或者users.email查找用戶。
常看法法：

• B+ Tree

  • Block based & Sequential Read -- 適合硬盤 -- Disk的sequential讀寫很快

  • 例如1M個nodes，用二叉樹存，須要21層；若是用1024叉樹，須要3層；

  • check memory的話，搜索一個node，二叉樹要搜索21 1 = 21次，1024叉樹須要3 1023 = 3K次

  • check Hard Drive的話，二叉樹須要21次，1024叉樹層數少，因此只須要3次（延時遠大於check memory）；其次，B+ Tree內容都在葉子結點，一大塊一大塊連續存儲，硬盤讀取更快。（使用sequential read，利於在同一個level的順序查找）

• Hash: 更費空間一點

Transaction 交易

Scenario 場景: A付款給B，中途死機，沒法完成transaction

Solution 解法:

Begin Transaction;
change userA.money;
change userB.money;
Commit Transaction;

Detail 實現細節: Log based Rollback

Write Ahead Log:

Begin Transaction;
//LOG: change userA.money from 10 to 0
change userA.money;
//LOG: change userB.money from 5 to 15
change userB.money;
/LOG: Success
Commit Transaction;

if you cannot find the log, roll back.
Trick: Save Logs on SSD(faster).

Will transaction and logs have race condition?
待續。

Evolution

More data

例如，100M用戶，100TB數據。

• 拆數據庫

  • 根據應用把不一樣類型的數據放在不一樣的Database機器上

• Tradeoffs

  • Relations再也不存在

  • Transaction沒法保證

• 瓶頸：一張表都放不下了、或者Latency要求很高（須要存在Memory中）

  • Database sharding 拆表 (sharding key = primary key)

    • Transaction怎麼辦

    • Range Query或non-sharding key query須要查詢多臺機器

      • Latency ^

      • Reliability v

• 數據繼續增大，怎麼辦

  • 方案一：基於重建數據庫的data migration（Function: % N）

    • 開N+1臺新機器

    • Double Write(既寫入老機器，也寫入新機器）

    • 寫一個小腳本

      • 從以前的機器讀出全部數據

      • 依次寫入新機器

      • Verification 看一致性

    • kill老機器

  • 方案二：Consistent Hashing

    • 把數據map到一個圓上

    • N臺機器按360/N的比例分配數據段

    • 問題：Web server怎麼知道誰負責哪一段？從相交數據段的兩臺機器上migrate數據

      • High Volume Read

      • Data size imbalance 不必定要分配的數據量均勻

    • Consistent Hashing的缺點：和%N的Hashing相比，function比較複雜，維護更難一些

  • 方案三：現實系統中通常採用Micro Shards (Virtual Nodes)

More reads

方案一：Replication (Load Balancer)

• 例如網站每秒幾萬次的訪問量

• 方案：多開幾臺機器，存儲相同的data，這樣在不少read的時候，分擔壓力

• Tradeoff：帶來replicate多臺機器的write問題

  • 方案：先寫入Master Server，再由Master機器寫入其它的Slave機器，可是，會有延遲，帶來data consistency的問題

    • 問題：Master crashed? 解決：replace by a slave, or double master.

  • 方案：Zookeeper，quorum write，保證全部機器同時獲得更新，見Paxos，raft的介紹

方案二：Caching

• Everywhere

  • Client, Edge/CDN, Datacenter, L1/L2/L3

• Problem: Hot Post（明星發推）

  • Tool: Memcache 在Memory裏作的Cache 減小對DB的queries

  • Memcache Simple API: get(key)-->value, set(key, value, time-to-live)

  • Million Level QPS per box

More writes

k-v pair data -->	Memtable(skiplist) -->	SS Table(key-sorted --> merge)
write to	batching	key-sorted
also write to Write Ahead Log

Tiered Write

Big Table

LSM Tree: Log Structured Merge Tree

分佈式數據庫小結

• 數據量增大

  • 拆數據庫

  • Sharding

• 讀操做增多

  • Replication

  • Caching

• 寫操做增多

  • LSM Tree Based Index

SQL vs. NoSQL

分佈式數據庫解決的問題

• Scalability

分佈式數據庫還沒解決的問題

• Query Language

• Secondary Index

• ACID Transactions

• Trust and confidence