带你认识存储的本质 - 状态｜ 青训营笔记

用户6100719745122
77 阅读5分钟

这是我参与「第五届青训营 」伴学笔记创作活动的第 13 天

存储 & 数据库简介

  • 存储系统概览

    • 存储系统特点
    • 存储器层级结构
    • 单机存储栈
    • RAID技术

  • 数据库系统概览

    • 关系型数据库特点

      1、最大的特点，事务的一致性
      2、通用的SQL语言，使得操作关系型数据库非常方便
      3、ACID：原子性、一致性、隔离性、持久性
      4、表结构严格，存储数据很难出错

    • 非关系型数据库特点

      1、使用键值对存储数据
      2、数据没有耦合性，易扩展
      3、不提供sql，无事务处理
      4、不需要经过sql层的解析，性能很高
      5、数据存储更加灵活，但是可能导致数据不一致性的问题

    • 数据库 vs 经典存储

      1、结构化数据管理，数据库以表的形式进行存储管理
      2、事务能力 ：acid
      3、复杂的查询能力

主流产品剖析

  • 单机存储产品

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

    • 单机文件系统

    本地文件系统，如linux文件系统，一切皆文件 将io，设备抽象成一个文件

    数据结构：Index Node & Directory Entry

    • 单机key-value存储

    常见使用方式 put(k,v) & get(k)

    常见数据结构：LSM -Tree 某种程度上牺牲读性能，追求写入性能

    LSM-Tree全称是Log Structured Merge Tree，是一种分层，有序，面向磁盘的数据结构，其核心思想是充分了利用了，磁盘批量的顺序写要远比随机写性能高出很多。

    虽然这种结构的写非常简单高效，但其缺点是对读取特别是随机读很不友好，这也是为什么日志通常用在下面的两种简单的场景：

    （1） 数据是被整体访问的，大多数数据库的WAL（write ahead log）也称预写log，包括mysql的Binlog等

    （2） 数据是通过文件的偏移量offset访问的，比如Kafka。

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

    • HDFS

    • Ceph

  • 单机数据库产品

    • 关系型数据库 —— PG、MySQL
    • 非关系型数据库 —— ES、MongoDB、Redis
    • Elasticsearch使用案例

  • 分布式数据库产品

    • 问题与挑战
    • 解决方案

高性能硬件

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

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

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

总结

  • 存储系统

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

  • 数据库系统

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

  • 分布式架构

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

在存储 & 数据库领域，硬件反推软件变革非常常见

课后思考

  1. 写入存储系统的粒度太大，会不会导致数据原子性问题？例如一次性写100MB，如果系统突然crash，会不会只有一部分数据持久化了，另一部分丢失了？如果要解决原子性问题，一般会设计什么机制？

    • 如果系统不崩溃，批操作每次都正常完成，那么不会导致原子性问题。
    • 但是出现crash的情况，可能会出现原子操作被拆开的现象，解决方案是建立错误回滚机制，事务异常之后，应该回滚到上一个保障数据一致性的点。redolog binlog

  2. 在从应用程序到存储介质的链路上，无论读还是写，数据可能要被拷贝好几次，这几次拷贝能不能去掉？如果我们去掉大部分拷贝操作，会有什么副作用，要怎么缓解副作用？

    • 可以去掉
    • 数据获取写入时间过长，一旦中间数据丢失便无备份，对于经常访问的数据建立缓存，加快速度

  3. 一个关系型数据库大概率是会被并发访问的，如果要保证并发安全，除了在行数据上加悲观锁还有其他方式吗？

    • 锁升级策略，读数据需要获取共享锁（支持并发读），写数据获取独占锁（不允许其他读写）

    • 或者针对事务三级锁

  4. 在数据库领域，把数据按行存和按列存各有好处，你能从性能优先的角度设计出一种混合存储格式吗？

    • 利用ai进行决策，根据访问次数和访问类别进行决策得到适合当前场景下最优的存储格式。
avatar
文章
阅读
粉丝