血缘关系

列表

MySQL

简介

国内使用最多的RDBMS(关系型数据库管理系统),在互联网领域使用最多。

特点

  • 设计上为单机存储
  • 单机存储在千万条数量级

扩展方式

  • 高可用——主备(不同步),部署多台服务器,一主多备,主备之间共享同一块网络磁盘
  • 高可用——主备同步,部署多台服务器,一主多备,主备之间进行通过binlog进行同步
    • 异步同步:主库写入成功后事务成功
    • 半同步:一个备写入成功后事务成功
    • 全同步:所有备写入成功后事务成功
  • 分库分表
    • 垂直切分:一个表按照列分为多个库表
    • 水平切分:一个表按照主键根据一定规则分到多个库表
    • 带来的问题:
      • 事务支持需要借助外部中间件:xts
      • 多库结果合并(group by order by)
      • 跨库Join:基础字段冗余法/公共JoinKey
      • 容量和增长估算不准确,来回拆库迁移

以上功能一般通过 MySQL中间件实现

  • MYSQL proxy (官方)
  • Cobar (阿里)
  • MyCAT
  • TDDL (淘宝)
  • DBProxy (美团)

使用场景

  • 大多数场景,优先考虑

块存储

简介

传统意义上的块存储就是一个格式化后的磁盘,可以通过mount挂载在操作系统中。随着云的发展,块存储一般以网络磁盘的方式提供。

特点

提供磁盘设备级别存储

主流方案

  • 使用Ceph提供的RBD
  • Ceph底层提供分布式和高可用

使用场景

  • 虚拟机/容器外挂的虚拟存盘
  • 注意点
    • 不能多点以写方式挂载同一个
    • 网络抖动带来IO问题

分布式文件系统

简介

文件系统系统类似于块存储,区别在于:多个客户端可以挂载同一个文件系统,从而实现共享。

特点

  • 需要支持Posix协议,做到对应用程序透明
  • 支持共享
  • 存在问题
    • 目录锁性能问题

主流方案

  • CephFS
  • NFS (企业级较少)

适用场景

  • 一写多读(写会加读写锁,多写会存在性能问题)
  • 小文件较多
  • POSIX文件接口访问
    • AI训练
    • 共享式外部文件资源依赖
  • 注意点
    • 单文件系统文件总数 小于 5 亿
    • 避免多人写同一文件
    • 目录权限,避免误删
    • 避免大目录list

对象存储

简介

类似于文件系统的存储,不支持多级任意级别目录树,仅支持二级结构(/存储桶/对象

特点

  • 扩展性极强,伸缩性强
  • 高可靠,高可用
  • EB级别存储的数据治理服务

主流方案

  • Swifi (OpenStack)
  • RGW (Ceph)

使用场景

  • HTTP REST访问
  • 高并发
  • 不需要层次结构
  • 相对稳定不变的非结构化数据
    • 视频、图片、文档、备份包
  • 注意点
    • 不适合频繁增删改场景
    • 延时敏感不适合
    • 不支持目录层次结构、Rename (Rename可以做事务)

缓存

简介

通过将某些数据缓存在内存中,提高响应速度,减少DB压力。

主流方案

  • Redis

Redis 注意点:

  • 可靠性问题:不能用作持久化存储
  • 一致性:最终一致性
  • 持久化:可能丢失1s以上数据
  • 总容量:1TB以下
  • 避免大key(Redis单线程)
    • string value < 10kb
    • hash/set/zset 元素 < 5000

Redis 方案

  • 主从方案(主从同步)
  • 集群方案(Sharding,分片存储)
  • proxy方案(利用代理屏蔽)

适用场景

  • 用户信息缓存 (Redis Hash类型)
  • 技术服务后端
  • 排行榜 (Redis SortedSet)
  • 共享session服务
  • 分布式锁
  • 关系网络 (Set)
  • 最新列表 (List)
  • 通知触发器

大规模KV存储

简介

这里的KV存储指的大规模分布式的KV存储。可以作为分布式数据库的底层存储使用。一般情况下Key是有序的(这样才支持range查询)

常见实现

  • Hbase
  • RocksDB

注意点

  • 单分区HA切换时间秒级,注意重试超时
  • 总容量:1TB~1PB
  • 提供准确TPS,Latency,Value size以便shard,避免分裂抖动
  • 避免大Key (小于 1mb)

文档数据库

简介

提供和RDMS想类似的功能。但是不需要预先定义schema

常见实现

  • MongoDB

MongoDB使用注意点

  • 不适合复杂联合查询(Join)
  • 不适合跨文档事务的场合

使用场景

  • Schema Free:文本数据,爬虫数据,嵌套数据
  • 高度变化的数据:游戏用户数据
  • LBS数据
  • 快速迭代开发

分布式数据库

简介

趋向于实现完整的RDBMS的全部功能(比如全部的事务支持、强一致性等)。同时具有分布式存储系统的优点:可扩展,高并发,大规模。

一般情况下底层构建在分布式KV存储之上

常见实现

  • Google Spanner (非开源)
  • TiDB
  • CockroachDB

特性

  • 机房容灾
  • 面向在线业务
  • 分布式事务
  • 强一致性(raft等)
  • 顺序扫描
  • 高可用(多副本)
  • 条件更新(cas)
  • 数据自动过期(TTL)
  • 毫秒级延迟
  • TB级大容量
  • 百万QPS/TPS

使用场景

  • 单行数据不宜过大
  • 索引会影响插入效率

图存储(图数据库)

简介

主要用于存储复杂多维关系(比如社交关系),主要存储边(关系)和节点。

主流实现

  • Neo4J

当然可以通过分布式KV系统实现

  • 点(vertex) id-type
  • 边(Edge) id1-edgetype-id2-timestamp

注意点

  • 可能出现大点(边超级多的点)
  • 多维查询,度不能太大
  • 热点写入或查询问题

使用场景

  • 社交关系(点赞、2度好友关系、共同关注)
  • 知识图谱/血缘关系
  • 金融气爪风控监测
  • 实时引擎推荐

消息队列

https://www.jianshu.com/p/2838890f3284

简介

用于实现生产者消费者模型的中间存储

主流实现

  • RocketMQ
    • 有序性
    • 事务性
    • 延时发送
    • 吞吐量较低
  • NSQ
    • 高吞吐量
    • 不保证有序性
    • 不持久化
  • Kafka
    • 吞吐量高于RocketMQ一个数量级
    • 分区多了性能会受影响(磁盘随机IO变多)

适用场景

  • 解耦生产处理
  • 兜底,失败重试
  • 弹性,缓冲
  • 异步,批量处理
  • 跨组织跨部门处理

消息队列的消费语义和投递语义

消费语义

  • 消息至多被消费一次 (At Most Once)
  • 消息至少被消费一次 (At Least Once)
  • 消息仅被消费一次 (Exactly Once)

投递语义

  • 如何保证消息最多投递一次
  • 如何保证消息至少投递一次
  • 如何保证消息恰好投递一次

相关文章

  • Kafka
  • NSQ
    • Go语言开发
    • 支持 defer 延迟推送
    • 超轻量级
  • rabbitmq
  • RocketMQ
    • Java语言开发
    • 支持事务
    • 适合业务开发