怎么理解存储架构？
1. 理解技术本质
理解系统的核心技术本质，技术本质决定了应用场景和性能量级。
【案例】
1. Redis 是 K-V 存储系统；
2. HBase 是 sorted map。
2. 明确部署架构
学习存储系统支持的部署架构，
明确其架构的本质。
【案例】
1. Redis 支持3种部署架构；
2. HBase 只有1种部署架构。
3. 研究数据模型
研究存储系统提供的数据模型，包含哪些概念，如何应用。
【案例】
1. Redis 支持多种数据结构。
2. HBase 的 table，column等。
4. 模拟业务场景
模拟一些常见业务场景，完整的实现一个案例，并测试其性能，也可以先参考网上已有的测试结果
【案例】
1. 如何用 Redis 来存储关注关系？
2. 如何用 HBase 存储关注关系？
Redis 介绍 – Remote Dictionary Server
【技术本质解读】
1. in-memory：意味着性能高，但同时意味着数据持久化不是核心，可能丢数据。
2. data structure store：数据结构存储，而不是关系数据，也不是文件存储。
【用途】
database，cache，message broker。
【性能量级】
单机 TPS 5~10万。
【相关知识】
关系数据：数据之间的关系非常密切，互相依赖和影响，核心特征就是读的时候 Join，写的时候用事务保证一致性。
非关系数据：数据之间关系疏松，互相独立，数据间的一致性要求很低。
Redis 部署架构
【技术本质】
1. 主从复制，读写分离。
2. 无自动切换功能。
【技术本质】
1. 主从复制，读写分离。
2. Master 故障时 sentinel 自动切换。
【技术本质】
1. 分片集群。
Redis 数据模型
【总体结构】
K-V 存储，单个查找快，不支持范围查找。
【数据结构】
1. String 类型。
2. Hashtable：Hash 表。
3. Linked list：可重复，插入顺序排序。
4. Set：不可重复，无序。
5. Sorted set：不可重复，按照 score 排序。
模拟业务场景 – 用 Redis 实现关注列表存储
【方案1】
1. Key：用户 ID + follower；
2. Value：选择 List，List 是有序的，可以重复。
【具体方案】
1. 新增关注：需要扫描 List 判断是否重复，不重复则尾部追加；
2. 取消关注：需要扫描 List 找到粉丝 ID 然后删除；
3. 拉黑：和取消关注一样。
【方案分析】
新增关注和取消关注都需要扫描整个 List，性能较低，某些爆红的账户会有性能问题。
【方案2】
1. Key：用户 ID + follower；
2. Value：选择 Sorted set，有序但不能重复。
【具体方案】
1. 新增关注：使用关注时的 timestamp 作为score排序，无需扫描，Redis 会判断粉丝ID是否重复；
2. 取消关注：直接删除指定的粉丝ID对应的数据；
3. 拉黑：和取消关注一样。
【方案分析】
无论是性能还是实现复杂度，都比 List 要更优秀。
HBase 介绍
【技术本质解读】
1. no-relational：非关系型数据；versioned：多版本的。
2. after Bigtable：参考 Bigtable 的原理，multidimensional sorted map。
3. on top of Hadoop and HDFS：基于 Hadoop 和 HDFS，底层存储结构是 LSM。
【用途】
Big Data 存储。
【参考性能量级】
四台32核主机每秒插入70000条，读取大约是25000条，扫描100条以内记录，每秒15000条（读取比写入慢？）。
模拟业务场景 – 关注列表存储方案1
【方案1】
1. Key：用户 ID ；
2. Value：关注顺序作为 Column，被关注的用户 ID 作为 value，增加 count 列作为关注总数。
【具体方案】
1. 新增关注：先读取 count 列计算出关注顺序，再以此顺序作为 column；
2. 取消关注：需要遍历整个 follows column family，并修改 count 列；
3. 拉黑：和取消关注一样。
【方案分析】
性能太低，需要读取出来整个列表，然后遍历整个列表。
模拟业务场景 – 关注列表存储方案2
【方案1】
1. Key：用户 ID + follower ID；
2. Value：follower 的全名。
【具体方案】
1. 新增关注：直接插入新的一条记录；
2. 取消关注：直接删除记录；
3. 拉黑：和取消关注一样；
4. 查看列表：scan 前缀为“用户 ID”的 key。
【方案分析】
1. 读写性能都很好；
2. 一个关注关系要一条数据。
HDFS 介绍
【技术本质解读】
基于Google的GFS论文的开源实现
1. file system ：这是文件存储，不是关系数据，也不是数据结构。
2. distributed：分布式的文件存储，不是类似于 Linux 的 Ext 文件系统。
3. low-cost hardware：运行在低成本硬件，而不是 IOE 的高成本硬件。
【用途】
large data sets：大数据存储。
【参考性能量级】
性能可横向伸缩，瓶颈是带宽。
HDFS 部署架构
【技术本质】
1. 分片集群；
2. 大文件存储，不适合存储只有几K的小文件
HDFS 数据模型
简单来说，这就是一个文件系统，你需要自己来规划好目录和文件就可以了，意味着从传统的磁盘文件存储迁移到HDFS存储是非常方便的。
ClickHouse 介绍
【技术本质解读】
1. column-oriented：列式存储；
2. DBMS：数据库管理系统；
3. OLAP：OLAP 场景（MySQL 是 OLTP）。
【用途】
OLTP：联机事务处理，执行大量增删改查，关注响应速度、高并发、数据一致性。OLAP：联机分析处理，执行少量复杂查询，关注吞吐量，很少修改数据。
行式存储：表中的一行记录存储在一个数据块中。
列式存储：表中的一列数据存储在一个数据块中。
ClickHouse 部署架构
【技术本质】
1. 分片集群；
2. ZooKeeper 管理，分片独立复制。
ClickHouse 数据模
基于 SQL 表设计即可。
如果你需要将原来基于数据库的统计分析剥离出来，且数据量并不大的话，使用ClickHouse的复杂度是很低的；而如果切换为Hadoop、Spark这类平台的话，切换复杂度和成本就会高很多。
原文始发于微信公众号（二进制跳动）：存储结构剖析：redis、hdfs、hbase、clickhouse
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
文章由极客之音整理，本文链接：https://www.bmabk.com/index.php/post/167057.html
