如何进行数据库选型

导语：随着云上应用的迅速发展，DT时代的到来，面对数智化、多场景情况下，我们如何做好数据库选型？

近年来应用上云、数字化转型的升级，数据沉淀的规模呈现爆发式增长，数据问题治理和分析以实现数据价值，数据库作为数据承载力的基石，多种数据库产品应运而生，我们需要根据不同的应用场景选择更适合我们的数据库产品。

如何进行数据库选型

进行数据库的选型，主要需要考虑两个方面：业务侧的应用功能需求、运维侧的架构需求

业务侧的思考

业务多场景化，比如：电商、金融、游戏等用户行业，存储的商品及订单信息、交易数据、游戏储值数据等信息，不同业务对数据结构、未来设计和扩展的需求，决定了我们是选择关系型数据库还是非关系型数据库

• 对数据结构、数据表的规划设计，选择适合业务需求的数据库类型，满足对数据操作的需求
• 冷热数据查询借助内存数据库做缓存，从架构上减少数据库压力，提升业务系统的性能及稳定性
• 数据库高并发场景下，设计合理的链接池、队列控制等可以有效减轻对数据库直接造成压力冲击或数据库连接池不释放导致的性能问题

运维侧的思考

运维侧主要考虑数据库的性能及数据库架构扩展能力是否能满足对业务侧快速发展迭代对数据库存储、性能、扩展方面的需求

• 功能性方面，存储的数据规模及后期扩展，采用主从模式还是Sharding的数据库架构
• 稳定性方面，出现异常如何进行快速切换，是否要代码层主动切换IP，还是数据库自身结合DNS、负载均衡、高可用的技术完成无缝切换

数据库分类

在寻找数据库的过程中，我们首先应该关注的是广度，给大家推荐一个专门收集和呈现数据库管理系统信息的数据库引擎排名站点DB-engines，在业内，对数据库的通用分类主要包括5大类：

1. 关系型数据库：以Mysql、Oracle、PostgreSQL作为代表，均是结构化的关系型数据库，主要基于SQL进行操作
2. 文档数据库：以MongoDB、Elasticsearch作为代表，支持灵活的半结构化数据结构，如JSON等
3. 时序数据库：以InfluxDB、Prometheus作为代表，主要服务于监控、日志类的数据存储，支持按照时间维度进行存储和分析
4. Key-Value数据库：以Redis、Memcached作为代表，主要应用在热点数据的缓存系统，支持典型数据库的快速存储访问
5. 图数据库：以Neo4j作为代表，支持图的存储，主要应用于知识图谱、关键路径搜索等场景

关系型数据库

业务应用系统可以按照交易类型分为联机事务处理过程OLTP（On-Line Transaction Processing）和联机实时分析OLAP（On-Line Analytical Processing）两大场景，混合事务和分析处理HTAP（Hybrid Transaction and Analytical Process）打破两者的隔阂，既可以应用于事务型数据库场景，也可以应用于分析型数据库场景，实现实时业务决策。因此我们应该在选择数据库分类的基础上，需要进一步具体到某一款数据库，需要考虑一些数据库特点：

• 属于OLTP还是OLAP类型

OLTP类型的数据库提供事务能力，严格满足ACID特性，实时性要求较高；而OLAP类型数据库支持强大的汇聚分析能力，可能不支持事务，一般情况下实时性会差一些。

• JSON格式的支持性

随着数据库技术的不断发展，关系型数据库与非关系型数据库界限逐渐模糊，较多关系型数据库已经支持JSON数据格式，避免一些特定场景需要手动编解码，但并不意味着它是万能的，放松对数据格式和模型的设计，把关系型数据库当作文档数据库使用时错误的

• 性能评估是否全面

我们不仅需要关注查询分析响应速度，还要关注业务相关维度，比如：聚合分析支持的并发、支持的读写能力等，事务型在关注读写并发能力的同时也需要关注在数据分析上的性能表现

文档数据库

文档数据库由于灵活的数据结构受到众多开发者的亲睐，如：Mongodb、ES等，经常作为业务核心数据库使用，然后因为灵活方便反而容易被滥用，我们使用文档型数据库时应注意：

• 区分元数据与数据

由于文档数据库支持复杂JSON的结构，导致在使用过程中不对数据模型进行抽象，导致数据库中保存了很多冗余信息，不仅占用额外的磁盘空间，也导致数据库建立索引和聚合分析性能开销变大

• 事务能力

文档数据库一般不支持多文档事务，仅保证单文档变更原子性，避免依赖文档数据库的结构灵活性而忽略业务事务型的诉求，导致最后业务代码实现越来越复杂，稳定性与性能都会越来越差

• 更新数据

mongoDB针对单文档操作有非常不错的性能，不同语言也都有成熟的SDK支撑，但不能因为修改方便，频繁的进行文档修改操作，大量的修改操作叠加在一起性能开销会被放大

Key-Value数据库

Redis作为常用的Key-Value型数据库以缓存的方式应用于服务中，不过当我们不需要在多个服务器间进行共享时，其实没有必要单独建立Redis数据库进行cache，很多语言本身就有成熟的内存cache库可以使用，这样可以避免每次访问都会有网络开销

时序数据库

时序数据库主要用于记录监控数据，如：prometheus、druid等，有些典型的特点：

• 数据以实践流方式存在
• 大部分时序数据库不支持更新
• 是否具备可扩展的指标收集插件，如：prometheus支持job exporter收集数据，同时支持altermanger集成实现告警功能，还可以继承到grafana上展示和分析监控数据
• 存储可扩展性，有些数据库主要运行在单节点场景，数据规模较大时我们需要考虑分布式节点，如：durid本身支持集群模式，不过需要引入第三方插件zookepper等
• 是否支持计算分析能力

云数据库

云计算时代，大量的应用上云，自然而然更多的云数据库应运而生，选择云平台数据库的一些好处：

• 云数据库具备良好的弹性伸缩能力，可根据业务需求快速动态调整
• 云平台厂商每款数据库都有专门的研发团队，数据库配置调优更专业
• 减少研发团队数据运维成本

腾讯云数据库分类

腾讯云数据库

应用是否一定是单一数据库

现在日益复杂的业务场景及分布式情况下，通常我们会同时使用多种数据库，比如：可能会在将一些热点数据存储在Redis中，将业务数据拆解成行列二维表存储在Mysql中，将一些全文搜索的数据放在ES中，将一些日志数据或者文档数据放在MongoDB中等等，面对NoSQL数据库与关系型数据库该如何抉择

关系型数据库优点

关系型数据库对业务层开发效率有很大帮助，我们通过一个简单案例解释一下，上班期间我们需要通过打卡考勤，通过关系型新建员工、考勤机、考勤记录三张表，如下图：

员工打卡考勤关系图

在关系数据库中，表中的每行数据由多个从属列的单一值（比如数字、字符串）构成，虽然表中可以存放任意行数据，但列却是定义且不变的，因此我们很容易通过行、列交汇处的单一值进行关联操作，完成各类业务目的的查询统计，比如：业务开发者可以通过下面这行SQL语句，找到在某天打卡的员工，上报其员工ID以及所在打卡的考勤机

SELECT
e.name,r.record_time,m.location
FROM records as r
JOIN machines as m on m.id=r.machine_id
JOIN employees as e on e.id=r.employee_id
WHERE r.record_time='20220626'

运营人员可以通过下面SQL语句，统计各考勤机的使用频率

SELECT
m.id,count(*) as nums
FROM machines as m
JOIN records as r on r.machine_id=m.id
GROUP BY m.id

因此，关系型数据库可以通过预定义的关系，由数据库本身完成复杂的逻辑计算，为不同的场景提供数据服务，通过事务来保证相关数据间的一致性

关系型数据库的问题

虽然基于单一值的映射关系提供了事务等许多功能，但也引入了几个问题：

1. 内存中的数据结构具有多样性，难以直接映射到行列交汇处的单一值上，不过这个问题可以通过一些ORM框架解决，ORM框架可以将上述行列二维表映射为内存中的类对象，进而转化为OOP中的函数调用
2. 为了实现关系映射，每张表中的字段都需要预先定义好，一旦迭代过程中数据模型发生变化，就需要同步完成:
   • 修改表结构
   • 修改应用层操作数据的代码
   • 根据新的规则转换、迁移已有数据
3. 关系型数据库固有的可伸缩问题，单点主库无法解决数据持续增长引入的性能问题，NoSQL数据库放弃了单一数据模型，适合部署在成千上万个节点的分布式环境中

NoSQL数据库如何解决上述问题

NoSQL数据库放弃了与分布式环境相悖的ACID事务，提供了另一种聚合数据模型，从而拥有可伸缩的非关系型数据库，NoSQL包含上述数据库分类中除了关系型数据库之外的4类数据库，NoSQL快速发展的原因：

可用性及性能

• NoSQL数据可伸缩性非常好，基于Key-Value模型沿AKF Z轴将系统扩展至上万个节点

AKF模型

• 数据基于Key分片后，很容易通过MapReduce思想，提高系统的计算能力，比如：MongoDB就在查询接口中提供了MapReduce函数
• 通过冗余备份，NoSQL可以提供良好的容灾能力
• 如果每个Key中Value存放的复合数据已经满足全部业务需求，那么NoSQL数据库的单机查询速度也会优于关系型数据库

易用性

• 我们可以低成本的变更Value结构，不需要像关系型数据库同时需要修改表结构及迁移数据等操作

因此，如果我们多个业务数据间互相关联，我们需要从多个不同的角度分析、计算，并且需要保持相关数据的一致性，那么关系型数据库较为合适，一旦数据行数达到亿级别以上，就需要放弃单一值结构，将单行数据聚合为复合结构，放在可以伸缩的NoSQL数据库，此时我们无法依赖NoSQL数据库提供ACID事务操作，只能基于二段式提交等算法在应用层代码中实现事务。

实际上，关系型数据库与非关系型数据库都有明显的优缺点，我们进行选型时可以从业务数据模型、访问方式、数据量等考量，结合具体的应用场景权衡取舍。