Database and Cache

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