架构师之路,从「存储选型」起步

原创
06/15 10:00
阅读数 4.2K


经常有人问,架构师的学习路线是什么?

我一般推荐架构师的基本功,是从「存储选型」开始的。

本文整理了存储选型的思路和整体框架,主要包括几个部分内容:

  • 了解目前的存储技术趋势,以及对开发人员新的要求

  • 存储选型的原则,避免日常的经典误区

  • 结合典型数据库特点,说明如何进行存储选型,提高业务开发效率

  • 常见的场景和解决方案

1、存储技术发展看存储选型

1.1 存储类型多元化

DB-Engines数据库排名并不代表数据库的安装数量,或者使用量。但某数据库越来越受欢迎则代表在一定时间范围内更加广泛的使用。

这里贴了一张2022年5月份的排行榜(https://db-engines.com/en/ranking)。

我们对于排名前10的数据库中,比较熟悉的应该是MySQL、Redis和ES,这三个数据库在我们日常开发中占据绝大多数的比例。

但是,这三个数据库只代表了一小部分的数据库类型,我们是不是可以把视野打开更多一些,看看没有更多的数据库类型,可以适合我们不同的业务,包括
Relational、Document、Key-value、Search engine、Wide column、Time Series、Graph等等不同数据库类型。

1.2 云原生存储多元化

除去上面的传统数据库之外,云时代存储技术又有了更多的变化。

除了简单的把上面的数据库托管到云上之外,还多了许多充分利用云的基础设施产生的云原生数据库,比如aws的Amazon Aurora、阿里云的PolarDB、腾讯云的TDSQL等。

另外,云时代还产生了更多类型的数据库,比如阿里云的多模数据库Lindorm、Pingcap的HTAP数据库TiDb等。

多类型数据库是各个云厂商发展的趋势,他们为什么会支持越来越多用途的数据库呢?

供给侧的改变一定是来源于需求侧,因为随着互联网、物联网等场景发展,有很多业务需求不是任何单一的数据库能解决的了。

1.3 告诉我们什么?

「数据库类型多元化」 & 「云原生数据库类型多元化」 是一个必然的发展趋势。

我们要解决的场景会越来越多,我们需要掌握的数据库领域也越来越广,只有这样,我们才能面对在线事务、离线分析、海量存储、成本与效率等因素,真正做好存储选型。

2、存储选型原则:不要耍流氓存储

2.1 不讲场景的选型都是耍流氓

大家可能都知道,数据库的选型一定是基于实际的业务场景的。但是,可能也遇到过类似的对话:

上面的对话可能有些夸张,但是实际生产中,可能是对场景的理解有误,也可能是为了快速完成任务开发,结果是在「特定场景」选择了错误的数据库的情况时有发生。

常见的特定场景包括:

  • 离线业务:日志、搜索、统计等。

  • 事务需求:强事务型、分析型。

  • 数据热度:全热数据、冷热明显等。

  • 数据读写偏好:多读、多写。

  • 数据增长方式:按日期、按用户、按位置类型等。

对于存储选型来说,一定需要识别特定场景的特点,是在线业务还是离线业务?数据冷热是否明显?数据访问方式特点?数据增长方式等等。

如果没有根据场景特点来做存储选型,可能会带来不良后果,包括无法满足业务需求、存储成本暴涨等,然后就需要花大代价做不停机数据迁移和代码重构。

因此,针对特定业务场景的存储选型一定要仔细、慎重,并在一开始就设计好。

2.2 不讲数据规模的选型都是耍流氓

除了特定场景外,「数据规模」是存储选型的另一个核心要素。

这样的对话非常常见。

虽然在一些新业务场景下,确实很难准确评估业务的数据规模,但是无法评估的数据规模,往往意味着无法做好正确的存储选型。

因此,如果有一定的先验知识,我们需要尽量做好数据规模的评估。比如,之前有没有类似的业务、其他组有没有类似的需求或功能,它们目前的数据规模大致如何,然后进行评估。

常见的数据规模指标有三个:

  • 数据总量

  • QPS

  • rt

不同的数据规模指标,往往意味着不同的存储选型。

2.3 不讲掌控度的选型都是耍流氓

对于存储选型,「掌控度」是非常重要的选型原则。

这里其实包括了两个维度,开发同学对存储的掌控度 & DBA对存储的掌控度。

1)开发同学的掌控度

对开发同学来说,选择一个存储,一定是基于对该存储的基本认知&最佳实践的了解。

一定不是其他人也这么用所以我这么用。

如果盲目使用一个自己不了解的存储,很容易带来不良后果,轻则造成资源浪费,重则引起线上故障(比如Mysql的慢sql、HBase的热点访问等)。

2)DBA对存储的掌控度

对DBA来说,对一个存储的基本认知&最佳实践是基础要求了。在此之上,还有其他更多的要求。

一个是社区活跃度。社区活跃度决定着你获取信息的难易程度,也决定到出现了故障后的定位速度甚至是能不能定位出来,如果社区很活跃,自然就能得到更多的帮助。

第二个是有没有案例背书。最好是一些中厂、大厂最新的案例实践(千万不要被大厂多年前的案例迷惑,技术发展往往意味着更新更合适的解决方案)。如果案例与存储不匹配,或者没有什么案例来支持你的存储选型,那么这个选型可能就是不合适的。

第三个是存储组件的上手成本。团队具备了什么样的技术储备?选择的是自研还是云产品?云产品是全托管的还是半托管的?毕竟每一种数据库都不是这么简单,如果人力有限而上手难度又很大,那么这个存储组件目前可能不是一个好的选择。

3、选型路线图

结合上面的原则,我们来做一个存储选型路线图供大家参考。

进一步,针对各个类型数据库,我们都需要了解它们的优点、缺点、最佳实践等,来结合业务场景因地制宜。

3.1 Relational

以MySQL为代表的关系型数据库。常用于在线业务(OLTP)场景,对于强事务有较好支持。

优点:

  • 容易理解,大家基本上都用得比较熟

  • 事务特性

  • 配套成熟(备份恢复、数据订阅、数据同步等)

  • 服务极度稳定

缺点:

  • 不易水平扩展

  • 大表表结构变更复杂

  • 全文检索能力弱

  • 复杂分析、统计能力弱

最佳实践:

  • 索引设计

  • 避免n+1轮训

  • 避免深分页

  • 单表千万考虑分库分表,或者使用云数据库(polarDB或者TDSQL)

  • 冷热数据注意归档

  • 不直接处理统计、分析型操作

3.2 Key-value

KV型NoSql顾名思义就是以键值对形式存储的非关系型数据库,是最简单、最容易理解也是大家最熟悉的一种 NoSql。

Redis是其中的代表,典型用于缓存场景。

优点:

  • 数据基于内存,读写效率高

  • KV型数据,时间复杂度为O(1),查询速度快

缺点:

  • 查询方式单一

  • 内存有限,且非常昂贵

  • 由于存储是基于内存的,会有丢失数据的风险(有持久化存储方案)

最佳实践:

  • 合理控制kv大小,避免大key

  • 避免热点key

  • 设置合理的TTL

  • 注意缓存雪崩、穿透、击穿、兼容问题

  • 不要用于消息队列,异常情况无法堆积消息

  • 不要将redis作为数据库使用,可能会丢数据

3.3 Search engine

搜索型NoSql顾名思义主要是用在搜索场景下的。

尽管MySQL可以通过索引来加速查询,但是对于全文搜索、模糊搜索等场景就比较无力,搜索型NoSql正是为了补足这个场景诞生的。

ElasticSearch是其中的代表产品。

优点:

  • 支持分词场景、全文搜索,这是区别于关系型数据库最大特点

  • 支持条件查询,支持聚合操作,适合数据分析

  • 在集群环境下可以方便横向扩展,可承载PB级别的数据

缺点:

  • 读写之间有延迟,写入的数据不一定能马上读到

  • 硬件性能要求高

最佳实践:

  • 核心在线应用强依赖ES需要考虑可行的降级方案

  • 禁止使用单索引多type

  • ES成本较高,因此建议仅数据库加速、全文检索情况下使用es

  • ES中仅存储索引字段,通过id回查数据库,不要全量数据存储ES

  • 根据节点数量设置合理的分片数量、分片大小

3.4 Document

文档型 NoSql 指的是将半结构化数据存储为文档的一种 NoSql,通常以 JSON 或者 XML 格式存储数据。

Mongo是其中的代表产品。

优点:

  • 没有预定义的字段,扩展字段容易

  • 相较于关系型数据库,读写性能优越

  • 分片集群易水平扩展

缺点:

  • 文档结构过于灵活,可能导致不易维护

  • 客户端控制力强,对开发、优化上有一定要求

最佳实践:

  • 选择合理的片键

  • 建立合适的索引

  • 正确使用写关注设置(Write Concern)

  • 正确使用读选项设置(Read Preference)

  • 正确使用更新语句(局部更新、防止大量更新集中在一条数据内)

3.5 Wide column

一般用于可靠性要求不高的海量存储场景。

HBase是代表产品(国外cassandra用得多,国内HBase用得多)。

优点:

  • 动态列调整,不受表结构困扰

  • 海量数据存储,PB 级别数据

  • 横向扩展方便,且支持廉价存储扩展,成本低,适用于无法预估存储量的海量数据

缺点:

  • Hadoop生态产品,组件依赖多,没有云托管产品,运维能力要求比较高

  • Rowkey设计需要一定经验,避免热点

  • 单集群SLA一般3个9,如果用于在线核心业务,一定需要考虑降级和容灾

  • 只支持行级事务

最佳实践:

  • 适用于行数多,但单个kv数据量小(1M以下)

  • 特别注意Rowkey设计,避免热点

  • 大value(10M以上)禁止存入HBase,考虑对象存储

  • 表创建时必须预分区

  • 表的列族数量不得超过 2 个

  • HBase是CP型系统,SLA一般是3个9,一般建议离线业务使用。如果核心在线业务使用,必须做好降级、容灾

4、常见场景和选型方案

上文提出了 三条选型原则 和 常见数据库的选型依据,下面结合不同场景做一下常规选型方案参考。

4.1 主要场景和方案

毋庸置疑,互联网业务的主要场景,是采用mysql进行数据存储。正如MySQL的自己所说 —— most popular open source database。

当然,为了扛住高并发场景,缓存也不可缺失。

因此,最主要的方案就是 MySQL + Redis。

适用于日常主要场景:

  • MySQL满足事务性要求

  • Redis抗热点

4.2 模糊搜索 or 全文检索

MySQL数据库擅长在线业务(OLTP)读写,不擅长做统计、分析型业务(OLAP)。因此,一般会通过MySQL做持久化存储,ES构建索引进行查询、分析。

适用于搜索场景:

  • 复杂查询

  • 模糊搜索

  • 全文搜索

  • 统计分析

4.3 大量数据场景

数据规模:100TB以内的数据量。

1)MySQL分库分表 + es

传统MySQL横向扩展方案,利用分库分表中间件进行存储扩展,利用ES进行非分表键查询和复杂查询。

适用场景:

  • 数据量较大

  • 有中间件使用能力

  • 已有MySQL横向扩展

2)云原生数据库(以polarDB为例)

云时代的新方案。

PolarDB是阿里巴巴自研的新一代云原生关系型数据库,在存储计算分离架构下,利用了软硬件结合的优势,为用户提供具备极致弹性、高性能、海量存储、安全可靠的数据库服务,100%兼容MySQL 5.6/5.7/8.0。

最高100 TB,不再需要因为单机容量的天花板而去购买多个实例做分片,由此简化应用开发,降低运维负担。

适用场景:

  • 数据量较大

  • 有公有云使用基础设施

3)mongo分片集群

适用场景:

  • 数据量较大的NoSQL场景

  • 表结构变更频繁场景,free-schema

  • 对mongo使用有一定理解

4.4 海量数据场景

数据规模:100TB以上的数据量。

1)高可用数据库 + HBase

由于数据量非常大,需要考虑存储成本。因此一般会考虑冷热数据分离。

热数据在高可用数据库进行读写,可以选择MySQL、Mongo等。冷数据存入成本较低的HBase或者对象存储等组件。

适用场景:

  • 海量数据

  • 可靠性要求高

2)直接使用HBase

如果是非核心在线业务,或者离线业务,可以考虑直接使用HBase。

适用场景:

  • 海量数据

  • 低成本

  • 可靠性要求不高

5、总结

在业务开发过程中,除了常用的MySQL,一定要多关注市面上更合适的存储方案,这是架构师的基本功。

通过了解更多存储组件的基本特性和使用场景,因地制宜选择合适存储,提高业务开发效率,降低使用成本。

希望本文能够抛砖引玉,提供一些启发和思考。





往期热门笔记合集推荐:


原创:阿丸笔记(微信公众号:aone_note),欢迎 分享,转载请保留出处。

没有留言功能的悲伤,扫描下方二维码「加我」聊些有的没的吧~

                                                                              觉得不错,就点个  再看 吧👇



本文分享自微信公众号 - 阿丸笔记(aone_note)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。

展开阅读全文
加载中

作者的其它热门文章

打赏
2
15 收藏
分享
打赏
0 评论
15 收藏
2
分享
返回顶部
顶部
返回顶部
顶部