架构设计之数据库选型

2024-09-09 18:57:39 浏览数 (1)

做架构选型的时候通常涉及数据库的选型,一般会从业务场景(时效性、数据量、成本、数据schema等)、数据库的成熟度、数据库的社区活跃度(可参考网站:https://db-engines.com/en/ranking)、数据库功能等多角度考虑。

数据库特性

事务

事务是代表一个或者一系列操作的最小逻辑单元,这个逻辑单元内的所有操作要么全部成功,要么就全部失败。

例举常用的例子:假设银行转账操作,A向B账户转账100元,下面将分三步进行:

  1. 检査A账户余额是否髙于100块钱;
  2. 从A账户余额中减去100块钱;
  3. 在B账户余额中增加100块钱;

转账就是本次一系列操作的最小逻辑单元,只有3个操作都成功了才算转账成功,任何一个步骤失败都算整个转账操作失败,只要其中任意一个步骤执行失败都不会再往下执行,并对已经执行的数据变更进行恢复。

这样在事务的机制下,不管转账成功还是失败系统数据最终都是一致的,钱才不会出现凭空变多或者减少,这也是事务存在的意义。

然而,支持数据库实现事务特性的是ACID机制。

ACID

  • 原子性(Atomicity)

上述例子中检查金额、A账户扣款、B账号增加钱一系列操作均是原子的,要么全部成功,要么失败,回到事务前的执行状态。

  • 一致性(Consistency)

事务要保证数据库整体数据的完整性和业务数据的一致性,事务成功提交整体数据修改,事务错误则回滚到数据回到原来的状态。上述例子中, 一致性确保了,即使在执行第二、三条语句之间时系统崩潰,A账户也不会损 失100块,因为事务最终没有提交,事务中所做的修改也不会保存到数据库中,保证了数据一致性。

  • 隔离性(Isolation)

隔离性是说两个事务的执行都是独立隔离开来的,事务之前不会相互影响,多个事务操作一个对象时会以串行等待的方式保证事务相互之间是隔离的。但是隔离也分级别,隔离级别越严格,并发效率越低,具体可了解MySQL事务隔离级别

  • 持久性(Durability)

持久性是指一旦事务成功提交后,只要修改的数据都会进行持久化(通常是指数据成功保存到磁盘),不会因为异常、宕机而造成数据错误或丢失。数据库的持久化机制各样,可了解MySQL的redo log binlog及habse的Hlog持久化。

业务场景分类

OLTP(OnLine Transaction Processing 联机事务处理):描述一系列的transactions同时发生的场景,例如取钱、转账、购物等,实时性要求比较高,对数据库的事务要求高。例如MYSQL

OLAP(online analytical processing在线分析处理):实时性要求没有OLTP要求高,重分析。用于复杂的 ETL、数据挖掘等延时要求不高的场景。处理的数据规模大、灵活性高,但查询延时差。例如hive、habse

OLTP 和 OLAP的比较OLTP 和 OLAP的比较

HTAP:是OLAP和OLTP的融合,既支持数据的实时处理又支持数据离线分析处理。例如腾讯云的 TDSQL-H LibraDB、TiDB。

数据库分类

下面根据业务使用场景对常用数据库进行通用分类,

关系型数据库

产品:Mysql、Oracle、PostgreSQL为代表,均是结构化的关系型数据库,主要基于SQL进行操作;

  1. MYSQL

文档数据库

产品:以MongoDB、Elasticsearch作为代表,支持灵活的半结构化数据结构,如JSON等

时序数据库

产品:以InfluxDB、Prometheus作为代表,主要服务于监控、日志类的数据存储,支持按照时间维度进行存储和分析

KV数据库

产品:以Redis、Memcached作为代表,主要应用在热点数据的缓存系统,支持典型数据库的快速存储访问

这里给腾讯自研开源数据库Dcache打个call,相较于Redis和Memcached,Dcache具有如下特点:

1.支持二级Key;

2.按照key值hash路由至一组group,且group集群支持基于etcd 选主的分布式集群;

3.后接DB持久化,支持冷热淘汰机制,不需要再关心 DB 和缓存之间的数据一致性,以及缓存不命中带来的一系列问题

该项目于2019年4月10日正式开源

官方开源地址:

https://github.com/Tencent/DCache

图数据库

产品:以Neo4j、nebula作为代表,支持图的存储,主要应用于知识图谱、关键路径搜索等场景

0 人点赞