第六届字节跳动青训营第五课｜ 青训营

学习改变未来
125 阅读5分钟

存储&数据库的相关知识

本文将从存储与数据库简介、主流存储产品剖析、存储与数据库的新技术演进三个方面进行总结。

一条数据从产生，到数据流动，最后持久化的全生命周期。

  1. 经典案例——数据的产生

某天，小明同学下载了一个新的APP。因为第一次登陆， 所以进入APP后需要注册一个新的账号

  • 用户名:小明
  • 密码: helloworld
  • 密码提示问题: coding
  • .....

于是小明同学三下五除二地填好了资料，按下了「注册」按钮

就这样，数据就从无到有地产生了，并且在数十/数百毫秒内向APP的后端服务器飞奔而去 .....

  1. 经典案例——数据的流动

一条用户注册数据

"user name" : "小明" ,
"password" : "helloworld" ,
"password hint" : "coding" ,
......

传到后端服务器，最终传到数据库里

  1. 经典案例——数据的持久性
  • 校验数据的合法性（"小明"是否已经存在？）
  • 修改内存（用高效的数据结构组织数据）
  • 写入存储介质（以寿命&性能友好的方式写入硬件）
  1. 经典案例——潜在问题
  • 数据库怎么保证数据不丢?
  • 数据库怎么处理多人同时修改的问题?
  • 为什么用数据库，除了数据库还能存到别的存储系统吗?
  • 数据库只能处理结构化数据吗?
  • 有哪些操作数据库的方式，要用什么编程语言?

1 存储与数据库简介

1.1 存储系统

1.1.1 系统概览

  • 什么是存储系统?

一个提供了读写、控制类接口，能够安全有效地把数据持久化的软件，就可以称为存储系统。

涉及用户、媒介、内存、网络编程（单机上的存储有限）

1.1.2 系统特点

  • 作为后端软件的底座，性能敏感
  • 存储系统软件架构，容易受硬件影响（硬件发生变革就需要针对新型硬件从0开始写软件代码）
  • 存储系统代码，既“简单”（避免分支太多，避免系统性能差）又“复杂”（假设软件出错，硬件会坏的多种情况）

1.1.3 存储器层级结构（硬件）

类似于一个金字塔，塔尖代表一类容量极小的存储设备，容量极小但能支撑超高性能的访问，金字塔底部对应容量很大，访问读写速度很慢，访问方式也极其不友好。兼顾容量和性能的存储器就是金字塔中间的Persistent Memory

1.1.4 数据怎么从应用到存储介质

存储.png

  • 在存储软件站的链路上，「缓存」很重要，贯穿整个存储体系
  • 从用户到各态很可能会经历多次数据拷贝，拷贝也算是消耗CPU的操作，「拷贝」很昂贵，应该尽量减少
  • Disk从本质上可以代指任何介质，硬件设备五花八门，需要有抽象统一的软件接入层，万一系统依赖的硬件设备变化了，那软件也会重写

1.1.5 RAID技术

单机存储系统怎么做到高性能/高性价比/高可靠性?

  • R(edundant) A(rray) of I(nexpensive) D(isks)

RAID出现的背景:

  • 单块大容量磁盘的价格>多块小容量磁盘
  • 单块磁盘的写入性能<多块磁盘的并发写入性能
  • 单块磁盘的容错能力有限，不够安全

经典的RAID组合：

  1. RAID 0
  • 多块磁盘简单组合
  • 数据条带化存储，提高磁盘带宽
  • 没有额外的容错设计
  1. RAID 1
  • 一块磁盘对应块额外镜像盘
  • 真实空间利用率仅50%
  • 容错能力强
  1. RAID 0+1
  • 结合了RAID0和RAID1
  • 真实空间利用率仅50%
  • 容错能力强，写入带宽好

1.2 数据库

数据库与存储系统不一样，数据库分为关系型数据库和非关系型数据库。

1.2.1 关系（Relation）是什么

关系=集合=任意元素组成的若干有序偶对

  • 反应了事物间的关系

关系代数=对关系作运算的抽象查询语言

  • 交、并、笛卡尔....

SQL = 一种DSL =方便人类阅读的关系代数表达形式

1.2.2 关系型数据库特点

关系型数据库是存储系统，但是在存储之外，又发展出其他能力。

  • 结构化数据友好
  • 支持事务(ACID)
  • 支持复杂查询语言（比较流行就是SQL语言）

1.2.3 非关系型数据库特点

非关系型数据库也是存储系统，但是一般不要求严格的结构化。

  • 半结构化数据友好
  • 可能支持事务(ACID)
  • 可能支持复杂查询语言

1.3 数据库 vs 经典存储

1.3.1 结构化数据管理

一条用户注册数据，写入关系型数据库，以表形式管理；如果用经典的存储系统去解决结构化数据管理，例如要用文件去存数据，则要写入文件，自行定义，管理结构（要先做byte级别的运算）。

1.3.2 事务能力

凸显出数据库支持「事务」的优越性

事务具有：

  • A(tomicity)，事务内的操作要么全做，要么不做
  • C(onsistency)，事务执行前后，数据状态是一 致的
  • I(solation)，可以隔离多个并发事务，避免影响
  • D(urability)，事务一旦提交成功， 数据保证持久性

1.3.3 复杂查询能力

Q :写入数据之后，想做很复杂的查询怎么办? Example :请查询出名字以xiao开头，且密码提示问题小于10个字的人，并按性别分组统计人数 在经典存储里面一般会写for循环去做用户条件的查询以及过滤，再标记起来，再分组再统计

for each data {
  if (user name ......&& password hint ......){
    mark in list
  }
}
for each in marked. list {
  if (gender == ......){}
}

如果用关系型数据库，则可以写

Select gender, count(*) from user
where user. name like 'xiao%'
and len(password. hint) < 10
group by gender;

即可

1.4 数据库的使用方式

Everything is D(omain) S(pecific) L(anguage) -＞maybe SQL 以SQL为例，要操作数据时，支持以下操作:

  • Insert
  • Update
  • Select
  • Delete
  • Where子句
  • GroupBy
  • OrderBy

要对数据定义做修改时，支持以下操作:

  • Create user
  • Create database
  • Create table
  • Alter table
  • ......

2 主流存储产品剖析

2.1 单机存储

单机存储=单个计算机节点上的存储软件系统，一般不涉及网络交互

  1. 本地文件系统
  2. key-value存储

2.1.1 本地文件系统

Linux经典哲学：一切皆文件

文件系统的管理单元：文件

文件系统接口：文件系统繁多，如Ext2/3/4, sysfs, rootfs等，但都遵循VFS的统一抽象接口

Linux文件系统的两大数据结构： Index Node & Directory Entry

  • Index Node
    • 记录文件元数据，如id、大小、权限、磁盘位置等
    • inode是一个文件的唯一标识，会被存储到磁盘上
    • inode的总数在格式化文件系统时就固定了
  • Directory Entry
    • 记录文件名、inode指针，层级关系(parent)等
    • dentry是内存结构，与inode的关系是N:1(hardlink的实现)

2.1.2 key-value存储

世间一切皆key-value

  • key是你身份证，value是你的内涵。
    • 常见使用方式: put(k,v) & get(k)
    • 常见数据结构: LSM-Tree,某种程度上牺牲读性能，追求写入性能
    • 拳头产品: RocksDB

2.2 分布式存储

分布式存储=在单机存储基础上实现了分布式协议，涉及大量网络交互

  • 分布式文件系统
  • 分布式对象存储

2.2.1 HDFS

HDFS ：堪称大数据时代的基石

时代背景：专用的高级硬件很贵，同时数据存量很大，要求超高吞吐

HDFS核心特点：

  • 支持海量数据存储（以文件的形式提供给用户进行读和写）
  • 高容错性（比较便宜的通用硬件故障率很高，软件架构要高容错）
  • 弱POSIX语义
  • 使用普通x86服务器，性价比高

2.2.2 Ceph

Ceph ：开源分布式存储系统里的「万金油」

Ceph的核心特点:

  • 一套系统支持对象接口、块接口、文件接口，但是一切皆对象
  • 数据写入采用主备复制模型
  • 数据分布模型采用CRUSH算法（HASH+权重+随机抽签）

2.3 单机关系型数据库

单机数据库=单个计算机节点上的数据库系统

事务在单机内执行，也可能通过网络交互实现分布式事务

  • 关系型数据库
  • 非关系型数据库

商业产品 Oracle 称王，开源产品 MySQL & PostgreSQL 称霸

2.3.1 MySQL

关系型数据库的通用组件：

  • Query Engine——负责解析query,生成查询计划
  • Txn Manager——负责事务并发管理
  • Lock Manager——负责锁相关的策略
  • Storage Engine——负责组织内存/磁盘数据结构
  • Replication——负责主备同步

2.3.2 PostgreSQL

  • 关键内存数据结构: B-Tree、B+-Tree、 LRU List等
  • 关键磁盘数据结构: WriteAheadLog (RedoLog)、Page

关系型数据库里如果内存插入新的page分支，磁盘里就会有一个log来记录修改。磁盘里有page files（对应内存结构里数里面的page），redo log files（存储事务执行过程中各种的redo log），others（一般存临时数据文件）。内存不够用的时候先把临时的数据写到磁盘上，内存够用再重新将数据进行整合。

2.4 单机非关系型数据库

MongoDB、Redis、Elasticsearch三足鼎立

  • 关系型数据库一般直接使用SQL交互，而非关系型数据库交互方式各不相同
  • 非关系型数据库的数据结构千奇百怪，没有关系约束后，schema相对灵活
  • 不管是否关系型数据库，大家都在尝试支持SQL(子集)和“事务”

2.4.1 Elasticsearch

  • 面向「文档」存储
  • 文档可序列化成JSON,支持嵌套
  • 存在「index」 ，index= 文档的集合
  • 存储和构建索引能力依赖Lucene引擎
  • 实现了大量搜索数据结构&算法
  • 支持RESTFUL API,也支持弱SQL交互

例如：某天，小明在新注册的APP上发了一个贴子，帖子里面提到“c+ +编程有点难

则结构化数据大概就这样：

{
  "user name" : "xiaoming" ,
  "content" : "C++编程有点难" ,
  "created_at" ; 2022-05-01 14:30:00,
  ......
}

这个结构化的数据就会写入到Elasticsearch里面，过了几天，小李在APP上搜索“编程语言哪个好，哪个难度大?"

则需要对这句话做一个模糊匹配，Elasticsearch最擅长模糊匹配

{
  "query" :{
    "match" :{
      "content" : "编程语言，好，难度"
    }
  },
  ......
}

这时就可以发起一个query，对关键词做模糊的match，发送给Elasticsearch做查询搜索，模糊匹配出来返回给小李，

2.4.2 MongoDB

  • 面向「文档」存储
  • 文档可序列化成ISON/BSON,支持嵌套
  • 存在collection，collection =文档的集合
  • 存储和构建索引能力依赖wiredTiger引擎
  • 4.0后开始支持事务(多文档、跨分片多文档等)
  • 常用client/SDK交互，可通过插件转译支持弱SQL

2.4.3 Redis

  • 数据结构丰富(hash表、set、zset、list)
  • C语言实现，超高性能
  • 主要基于内存，但支持AOF/RDB持久化
  • 常用redis-cil/多语言SDK交互

2.5 分布式数据库

单机数据库遇到了哪些问题&挑战，需要我们引入分布式架构来解决?

  • 容量
  • 弹性
  • 性价比

2.5.1 解决容量问题

单点容量有限，受硬件限制

  • 存储节点池化，动态扩缩容（有很多物理虚拟机组成，存储池和数据库之间通过网络进行交互，数据库本身不需要关心下面的内存够还是不够，只要存储池软件能在自己达到一定的阈值之后，添加新的存储节点进来，能把用户的写入分配到新的存储节点上，database可以不用感知存储池里的细节、容量等）

2.5.2 解决弹性问题

如果之前的CPU资源紧张不够用，就需要扩容，然后再搬迁全量数据，扩容成功访问新数据库。如果需要缩容，Disk问题难以解决。采用池化可完美解决扩缩容问题。

2.5.3 解决性价比问题

要写500GB数据，容量不够，但是cpu利用率仅20%，也可使用共享存储池不需要扩CPU。

目前的瓶颈

  • 单写vs多写
  • 从磁盘弹性到内存弹性
  • 分布式事务优化

3 存储与数据库的新技术演进

软件架构变更

  • Bypass OS kernel

AI增强

  • 智能存储格式转换

新硬件革命

  • 存储介质变更
  • 计算单元变更
  • 网络硬件变更

3.1 SPDK

Bypass OS kernel已经成为一种趋势

SPDK：Storage Performance Development Kit

Kernel Space -> User Space

  • 避免syscall带来的性能损耗，直接从用户态访问磁盘

中断->轮询

  • 磁盘性能提高后，中断次数随之上升，不利于I0性能
  • SPDK poller可以绑定特定的cpu核不断轮询，减少cs，提高性能

无锁数据结构

  • 使用Lock-free queue, 降低并发时的同步开销

3.2 AI & Storage

AI领域相关技术，如Machine Learning在很多领域：如推荐、风控、视觉领域证明了有效性 在Storage领域，AI能给我们带来什么改变?

  • storage里面有行存和列存，可以通过AI决策实现行列混存的存储结构。

3.3 高性能硬件

  1. RDMA网络
  • 传统的网络协议栈，需要基于多层网络协议处理数据包，存在用户态&内核态的切换，足够通用但性能不是最佳
  • RDMA是kernel bypass的流派，不经过传统的网络协议栈，可以把用户态虚拟内存映射给网卡，减少拷贝开销，减少cpu开销
  1. Persistent Memory
  • 在NVMe SSD和Main Memory间有-种全新的存储产品: Persistent Memory
    • I0时延介于SSD和Memory之间，约百纳秒量级
    • 可以用作易失性内存(memory mode)，也可以用作持久化介质(app . direct)

  1. 可编程交换机 P4 Switch, 配有编译器、计算单元、DRAM,可以在交换机层对网络包做计算逻辑。在数据库场最下，可以实现缓存一致性协议等

  2. CPU/GPU/DPU

  • CPU：从multi-core走向many-core
  • GPU：强大的算力&越来越大的显存空间
  • DPU：异构计算，减轻CPU的workload

最后总结一下本文：

存储系统

  • 块存储:存储软件栈里的底层系统，接口过于朴素
  • 文件存储:日常使用最广泛的存储系统，接口十分友好，实现五花八门
  • 对象存储:公有云上的王牌产品，immutable语义加持
  • key-value存储:形式最灵活，存在大量的开源/黑盒产品

数据库系统

  • 关系型数据库:基于关系和关系代数构建的，一般支持事务和SQL访问，使用体验友好的存储产品
  • 非关系型数据库:结构灵活，访问方式灵活，针对不同场景有不同的针对性产品

分布式架构

  • 数据分布策略:决定了数据怎么分布到集群里的多个物理节点，是否均匀，是否能做到高性能
  • 数据复制协议:影响I0路径的性能、机器故障场景的处理方式
  • 分布式事务算法:多个数据库节点协同保障一个事务的ACID特性的算法，通常基于2pc的思想设计
avatar
文章
阅读
粉丝