这是我参与「第五届青训营 」伴学笔记创作活动的第 14 天
经典案例
数据的产生
例:当注册用户时,会产生数据,并向后台发送
数据的流动
新增数据——>后端服务器——>存入数据库做持久化- - - →其后可能存在其它系统
数据的持久化
-
校验数据的合法性
用户名是否已经存在?输入合法吗
-
修改内存
用高效的数据结构组织数据
-
写入存储介质
以寿命&性能友好的方式写入硬件
潜在的问题
- 数据库怎么保证数据不丢?
- 数据库怎么处理多人同时修改的问题?
- 为什么用数据库,除了数据库还能存到别的存储系统吗?
- 数据库只能处理结构化数据吗?
- 有哪些操作数据库的方式,要用什么编程语言?
存储 & 数据库简介
存储系统
系统概览
Q:什么是存储系统
A:一个提供了读写、控制类接口,能够安全有效地把数据持久化的软件,就可以称为存储系统(多数情况下还离不开网络)
系统特点
- 作为后端软件的底座,性能敏感
- 存储系统软件架构,容易受硬件影响(软件受硬件影响大,可能会顺应新硬件编写新代码)
- 存储系统代码,既“简单”又“复杂”(为了保证性能,在读写 IO 路径上代码尽量简单,尽量避免多分支,复杂则是因为在错误处理上要尽可能严谨,尽可能考虑多种异常)
存储器层级结构
在《深入理解计算机系统》一书的开篇就有这么一张图,越往上的存储设备可存储量越小、越贵,但速度越快,越往下则相反,其中,CPU regiesters、CPU Caches 和 DRAM 都是易失性的(volatile),SSD、HDD、Tape 是非易失性的(non-volatile,现代计算机一般上层级的存储作为下层级存储的缓存。然而,内存和磁盘之间仍旧有着不可逾越的性能鸿沟,尽管内存具有易失性,但性能永远是一块不断引诱开发者们的香饽饽,因此之后出现了位于易失性内存和磁盘之间的介质——持久化内存
持久化内存(Persistent Memory,简称 PMEM),也叫非易失性内存(Non-Volatile Memory,简称 NVM),是指一类支持字节寻址(byte-addressable)、可以通过 CPU 指令直接进行操作、断电后数据不丢失的存储硬件。
数据怎么从应用到存储介质
-
【缓存】很重要
存储介质不一定对软件友好:比如当软件读入粒度与介质不一致时,或者软件与软件之间数据交互粒度不一致
-
【拷贝】很昂贵
拷贝会消耗你的 CPU,如果不加以限制会吃空你的可用资源
-
硬件设备五花八门,需要有抽象统一的接入层
RAID 技术
Q:单机存储系统怎么做到高性能/高性价比/高可靠性?
A:R(edundant) A(rray) of I(nexpensive) D(isks)
独立磁盘冗余阵列,简称为「磁盘阵列」
RAID出现的背景
- 单块大容量磁盘的 价格 > 多块小容量磁盘
- 单块磁盘的写入 性能 < 多块磁盘的并发写入性能
- 单块磁盘的 容错能力 有限,不够安全
几种常见组合
RAID 0
- 多块磁盘简单组合
- 数据条带化存储,提高磁盘带宽
- 没有额外的容错设计,只对数据做了简单切割
RAID 1
- 一块磁盘对应一块额外镜像盘,写入就会拷贝
- 真实空间利用率仅50%
- 容错能力强
RAID 0 只注重性能,RAID 1 只注重容错,疑似是有点儿太极端了.jpg
RAID 0 + 1
- 结合了 RAID 0 和 RAID 1
- 真实空间利用率仅50%
- 容错能力强,写入带宽好
比如我有四块磁盘,先将磁盘两两组成 RAID 1,再将两组磁盘并入到 RAID 0,或者反过来,都可以在保证容错的情况下也能兼顾一下性能
数据库
概览
关系是什么?
关系 = 集合 = 任意元素组成的若干有序偶对
反应了事物间的关系
关系代数 = 对关系作 运算的抽象查询语言
- 交、并、笛卡尔积…
SQL = 一种 DSL = 方便人类阅读 的关系代数表达形式
关系型数据库特点
关系型数据库是存储系统,但是在存储之外,又发展出 其他能力
- 结构化数据友好
- 支持事务(ACID)
- 支持复杂查询语言
非关系数据库特点
非关系型数据库也是存储系统,但是 一般不要求严格的结构化
- 半结构化数据友好
- 可能支持事务(ACID)
- 可能支持复杂查询语言
数据库 vs 经典存储
结构化数据管理
别想了,经典存储肯定不如数据库好用,至少要麻烦得多,光是不同类型的字长和数据处理都可以让人头疼很久了
事务能力
凸显出数据库支持「事务」的优越性
事务具有:
- A(tomicity),事务内的操作要么全做,要么不做
- C(onsistency),事务执行前后,数据状态是一致的
- l(solation),可以隔离多个并发事务,避免影响
- D(urability),事务一旦提交成功,数据保证持久性
复杂存储能力
写入数据之后,很多情况下业务要求是比较复杂的,而 SQL 本身就给你提供了很多现成实现和函数,经典存储那就得靠你自己手搓咯
数据库使用方式
使用 DSL,极可能是 SQL(在数据库 DSL 中占有统治地位)
主流产品剖析
单机存储
概览
单机存储=单个计算机节点上的存储软件系统,一般不涉及网络交互
本地文件系统
Linux经典哲学:一切皆文件
文件系统的管理单元:文件
文件系统接口:文件系统繁多,如 Ext2/3/4,sysfs,rootfs 等,但都遵循 VFS 的统一抽象接口
Linux 文件系统的两大数据结构:Index Node & Directory Entry
lndex Node
记录文件元数据,如id、大小、权限、磁盘位置等inode是一个文件的 唯一标识,会被存储到磁盘上inode的总数在格式化文件系统时就固定了
Directory Entry
记录文件名、inode指针,层级关系(parent)等 dentry是内存结构,与inode的关系是N:1(hardlink的实现)
key-value 存储
常见使用方式:put(k, v) & get(k)
常见数据结构:LSM-Tree,某种程度上牺牲读性能,追求写入性能
拳头产品:RocksDB
LSM-Tree 全称是 Log Structured Merge Tree,是一种分层,有序,面向磁盘的数据结构,其核心思想是充分了利用了,磁盘批量的顺序写要远比随机写性能高出很多
分布式存储
概览
分布式存储 = 在单机存储基础上实现了 分布式协议,涉及大量网络交互
- 分布式文件系统
- 分布式对象存储
分布式存储 - HDFS
HDFS:堪称大数据时代的 基石
时代背景:专用的高级硬件很贵,同时数据存量很大,要求超高吞吐
HDFS核心特点:
- 支持 海量数据存储
- 高容错性(便宜且非专业的硬件出故障的概率高得多,因此需要软件实现容错)
- 弱 POSIX 语义(子集,非全集)
- 使用普通x86服务器,性价比高
分布式存储 - Ceph
Ceph:开源分布式存储系统里的**「万金油」**
Ceph的核心特点:
- 一套系统支持对象接口、块接口、文件接口,但是 一切皆对象
- 数据写入采用 主备复制模型(写主,从进行同步)
- 数据分布模型采用 CRUSH 算法(HASH+权重+随机抽签)
数据分布模型:数据存入后有多个副本,这些副本该存入多个节点中的哪几个,需要分布模型和算法支持
单机数据库
概览
单机数据库 = 单个计算机节点上的数据库系统
事务在单机内执行,也可能通过网络交互实现分布式事务
- 关系型数据库
- 非关系型数据库
关系型数据库
商业产品 Oracle 称王,开源产品 MySQL & PostgreSQL 称霸
关系型数据库的通用组件
- Query Engine ——负责解析query,生成查询计划
- Txn Manager ——负责事务并发管理
- Lock Manager ——负责锁相关的策略
- Storage Engine——负责组织内存/磁盘数据结构
- Replication ——负责主备同步
- 关键内存数据结构:B-Tree、B+-Tree、LRU List等
- 关键磁盘数据结构:WriteAheadLog (RedoLog)、Page
非关系型数据库
MongoDB、Redis、Elasticsearch 三足鼎立
关系型数据库一般直接使用SQL交互,而非关系型数据库交互方式各不相同
非关系型数据库的数据结构千奇百怪,没有关系约束后,schema相对灵活
不管是否关系型数据库,大家都在尝试支持SQL(子集)和“事务”
Elastic Search
面向「文档」存储
文档可序列化成JSON,支持嵌套
存在「index」,index = 文档的集合
存储和构建索引能力依赖 Lucene 引擎
实现了大量搜索数据结构&算法
支持RESTFUL API,也支持弱SQL交互
mongoDB
- 面向「文档」存储
- 文档可序列化成 JSON/BSON,支持嵌套
- 存在「collection] , collection = 文档的集合
- 存储和构建索引能力依赖 wiredTiger 引擎
- 4.0后开始支持事务(多文档、跨分片多文档等)
- 常用 client/SDK 交互,可通过插件转译支持弱 SQL
redis
- 数据结构丰富(hash表、set、zset、list)
- C语言实现,超高性能
- 主要基于内存,但支持 AOF/RDB 持久化
- 常用 redis-cli/多语言 SDK 交互
分布式数据库
单机数据库遇到了哪些问题 & 挑战,需要我们引入 分布式架构 来解决?
- 容量
- 弹性
- 性价比
解决容量问题
- 单点容量有限,受硬件限制
- 存储节点池化,动态扩缩容
解决弹性问题
单机节点硬件固定,如果想升级 CPU 或者增加磁盘空间,就需要更换一个新的节点,而这会造成全量复制,消耗时间和资源
而业务场景往往是多变的,服务访问量也会有高有低,扩缩容都会造成不小的消耗
使用池化也可以解决这一问题
解决性价比问题
单机节点各项硬件属性固定,而这些属性之间往往不好协调,可能我 CPU 换了一个更强大的,而磁盘空间浪费了很多
使用池化也可以解决这一问题
More to Do
-
单写 vs 多写
目前单机和分布式数据库都是同一时间同一份数据写入时只有单一用户在操作,需要更好的架构和算法支持多用户同时写入
-
从磁盘弹性到 内存弹性
-
分布式事务 优化