Database and Cache
User System
用户系统特点： 读非常多，写非常少
一个读多写少的系统，一定要使用 Cache 进行优化
哪些常用的 Cache 系统/软件？
Memcached（不支持数据持久化）
Redis（支持数据持久化）
对于 User System 而言
写很少
读很多
写操作很少，意味着
从QPS的角度来说，一台 MySQL 就可以搞定了
读操作很多，意味着
可以使用 Memcached 进行读操作优化
如果读写操作都很多，怎么办？
方法一：使用更多的数据库服务器分摊流量
方法二：使用像 Redis 这样的读写操作都很快的 Cache-through 型 Database
Memcached 是一个 Cache-aside 型的 Database，Client 需要自己负责管理 Cache-miss 时数据的 loading
Cache Aside
服务器分别与 DB 和 Cache 进行沟通
DB 和 Cache之间不直接沟通
业界典型代表：Memcached + MySQL
Cache Through
服务器只和 Cache 沟通
Cache 负责去 DB 沟通，把数据持久化
业界典型代表：Redis（可以理解为 Redis 里包含了一个 Cache 和一个 DB）
User System 里程碑
使用 Cache 优化数据库的读操作
Session (存在服务器端）/ Cookie（存在浏览器端）
SQL vs NoSQL的一些基本原则
Friendship 在 Cassandra (NoSQL) 中如何存储
SQL vs NoSQL Performance 性能对比
经验值：
MySQL / PosgreSQL 等 SQL 数据库 的性能
约 1k QPS 这个级别
MongoDB / Cassandra 等 硬盘型NoSQ数据库 的性能
约 10k QPS 这个级别
Redis / Memcached 等 内存型NoSQL数据库 的性能
100k ~ 1m QPS 这个级别
以上数据根据机器性能和硬盘数量及硬盘读写
SQL 和 NoSQL 的选择标准是什么？
数据库选择原则1:
大部分的情况，用SQL也好，用NoSQL也好，都是可以的
数据库选择原则2:
需要支持 Transaction 的话不能选 NoSQL
数据库选择原则3
你想不想偷懒很大程度决定了选什么数据库
SQL更成熟帮你做了很多事儿
NoSQL很多事儿都要亲力亲为(Serialization, Secondary Index)
数据库选择原则4
如果想省点服务器获得更高的性能，NoSQL就更好
硬盘型的NoSQL比SQL一般都要快10倍以上
Interviewer: How to scale?
除了QPS，还有什么需要考虑的？单点失效 Single Point Failure
万一这一台数据库挂了 短暂的挂：网站就不可用了 彻底的挂：数据就全丢了
所以你需要做两件事情 1. Sharding 2. Replica
Sharding / Replica Concepts
数据拆分 Sharding
按照一定的规则，将数据拆分成不同的部分，保存在不同的机器上
这样就算挂也不会导致网站 100% 不可用
数据备份 Replica
通常的做法是一式三份（重要的事情“写”三遍）
Replica 同时还能分摊读请求
数据拆分 Sharding
Vertical Sharding
根据数据本身不同的类别存储在不同的数据库服务器，比如
User Table 放一台数据库
Friendship Table 放一台数据库
Message Table 放一台数据库
比如拆分email, username, password和status_text, avatar为User Table和User Profile Table，分别放在两台机器
缺点是如果数据太多，一台机器放不下
Horizontal Sharding
核心部分！ Scale 的核心考点！
假如我们来拆分 Friendship Table
我们有10台数据库的机器 于是想到按照 from_user_id % 10 进行拆分 这样做的问题是啥？
假如10台机器不够用了 我现在新买了1台机器 原来的%10，就变成了%11 几乎所有的数据都要进行位置大迁移
过多的数据迁移会造成的问题 1. 慢，牵一发动全身 2. 迁移期间，服务器压力增大，容易挂 3. 容易㐀成数据的不一致性
因此需要一致性Hash算法 - Consistent Hashing
============
对于哪一个ID进行拆分sharding也有讲究，对于Instagram这种类型的应用，拆分UserID可能会有hot user follower众多/active user上传数量大，带来数据读取/写入的不均衡，如果按照PhotoID进行sharding，则合理得多。并且PhotoID will itself be unique throughout the system.
通过PhotoID找sharding id，就说明PhotoID不能通过每个sharding自己生成，需一个另外的database去生成 auto-incrementing IDs。但是这个key generating DB 会成为 single point of failure。一个workaround就是定义两个such databases， 一个生成奇数id，一个生成偶数id。
============
Sharding in SQL vs NoSQL
SQL自身不带 Sharding 功能，需要码农亲自上手
Cassandra为例的NoSQL大多数都自带 Sharding
这就是为什么程序员要发明 NoSQL ---- 可以偷懒！
数据备份 Backup vs Replica
Backup
一般是周期性的，比如每天晚上进行一次备份
当数据丢失的时候，通常只能恢复到之前的某个时间点
Backup不用作在线的数据服务，不分摊读
Replica
是实时的， 在数据写入的时候，就会以复制品的形式存为多份
当数据丢失的时候，可以马上通过其他的复制品恢复
Replica用作在线的数据服务，分摊读
Reliability and Redundancy
Creating redundancy in a system can remove single points of failure and provide a backup or spare functionality if needed in a crisis.
If only one instance of a service is required to run at any point, we can run a redundant secondary copy of the service that is not serving any traffic, but it can take control after the failover when primary has a problem.
For example, if there are two instances of the same service running in production and one fails or degrades, the system can failover to the healthy copy. Failover can happen automatically or require manual intervention.
SQL Replica
以MySQL为代表SQL型数据库，通常“自带” Master-Slave的Replica方法
原理 Write Ahead Log
SQL数据库的任何操作，都会以Log的形式做一份记录
比如数据A在B时刻从C改到了D
Slave被激活后，告诉master我在了
Master每次有任何操作就通知slave来读log
因此Slave上的数据是有“延迟”的
Master挂了怎么办?
将一台Slave升级(promote)为Master，接受读+写
可能会成一定程度的数据丢失和不一致
NoSQL Replica
以Cassandra为代表的NoSQL数据库通常将数据“顺时针”存储在Consistent hashing环上的三个virtual nodes中
SQL vs NoSQL in Replica
SQL
“自带”的Replica方式是Master Slave “手动”的Replica方式也可以在Consistent Hashing环上顺时针存三份
NoSQL
“自带”的Replica方式就是Consistent Hashing环上顺时针存三份 “手动”的Replica方式:就不需要手动了，NoSQL就是在Sharding和Replica上帮你偷懒用的!
In computer science, write-ahead logging (WAL) is a family of techniques for providing atomicity and durability (two of the ACID properties) in database systems. The changes are first recorded in the log, which must be written to stable storage, before the changes are written to the database.
Last updated