SQL还是NoSQL?架构师必备选型技能

很多时候我们都会有这样的疑问。

如果这时候直接去看MySQL、Mongo、HBase、Redis等数据库的用法、特点、区别,其实有点太着急了。

这时候,最好从「数据模型」开始讨论。

1、SQL vs NoSQL

现在最著名的数据模型应该是SQL,它基于Edgar Codd在1970年提出的关系模型:

数据被组织成关系(relations),在SQL中称为表(table),其中每个关系都是元组(tuples)的无序集合(在SQL中称为行)。

那什么是NoSQL?

现在很多非关系型数据库会被称为NoSQL,其含义往往被解释 "Not only SQL"。

采用NoSQL的驱动因素在于:

  • 数据量。 比SQL更好的扩展性需求,包括支持超大数据集或超高写入吞吐量
  • 查询方式。 关系模型不能很好支持的一些特定查询操作
  • 动态扩展。 对关系模式的一些限制表示沮丧,需要更加具有动态和表达力的数据模型

2、数据模型的差异

SQL 和 NoSQL数据库的差异有很多,包括容错性和并发处理,我们这里暂时只讨论数据模型的差异。

关系型模型的主要优势在于:

  • 联结操作
  • 多对一和多对多关系更简洁的表达

注意,简单的多对多适合关系型模型,复杂的多对多更适合图模型

我们以文档型NoSQL为例,它和SQL对比的核心优势在于:

  • 模式灵活性
  • 局部性带来的性能优势

2.1 模式灵活性

「模式灵活性」的特点,往往被称为「schema-fress模式」,但是我们并不能将它直接理解为"无模式"。

因为我们在读取数据时,往往存在某种数据结构的隐式转换,所以我们称之为「读时模式」更准确(数据结构是隐式的,只有读取时才解释)。

而传统关系型数据库,对应可以称之为「写时模式」(模式是显示的,并且在写入数据库时被约束必须遵守)。

这两者差异跟编程语言中的动态检查(运行时)和静态检查(编译时)比较类似。

「模式灵活性」的优点在于:

  • 避免了大表变更时的停机或者耗时
  • 支持包含多种类似数据结构
  • 可以随时改变数据结构

「模式灵活性」带来的损害则是需要应用层做好结构约束,并且保证对历史数据的兼容性。

一般典型关系型场景,「模式灵活性」反而会导致难以维护。

2.2 局部性的性能优势

注意注意,局部性优势仅适用于需要同时访问文档中大部分数据的场景。

如果我们的查询需要访问整个文档,那么存储局部性具备显著的性能优势。

此时,如果数据被划分到了多个表中,则需要访问多个表来检索数据,会浪费更多的磁盘IO并花费更多的时间。

如果我们的访问只需要文档中的一小部分数据,那么对于大型文档来说就是一种浪费。

3、数据模型分析原则

对于一份数据存储,「数据模型」的建立, 就是考虑应该通过 SQL 还是 NoSQL 进行 数据组织 。

那么,结合前面对SQL和NoSQL的介绍与对比,我们总结了以下几个维度,来具体考虑如何建立「数据模型」。

3.1 数据对象关系

多对一或者多对多,一般考虑SQL。

一对多的关系,可以考虑SQL或者NoSQL。

3.2 查询性能

如果我们的查询通常需要访问整个文档,那么存储局部性具备显著的性能优势,关系型的join性能较差,因此可以考虑NoSQL。

(业务上,一般会通过整体结果缓存,对关系型join查询加速)

如果通常是局部数据对象、独立实体查询,考虑SQL。

3.3 写入吞吐量

如果需要超高的写入吞吐量,考虑NoSQL。

3.4 扩展性

  • 属性扩展:如果对象属性不确定,且经常变动,NoSQL更灵活。
  • 超大数据集扩展:NoSQL通常更好。
  • 单value大小:单value如果过大,可能导致数据库写入失败。考虑拆分对象,或者分级存储到对象存储。一般单value不要超过100KB(压缩后)。

3.5 延迟选择数据库类型

数据模型分析主要是根据业务场景区分 关系型 还是 非关系型。

延迟考虑具体数据库选型,用RDS还是Mongo还是其他数据库,它们之间的功能性差异在逐渐变少。

具体选择可以结合 研发人员熟悉程度、数据规模、其他非功能性需求 来判断。

一些例子:

  • Mongo 4.x支持事务
  • MySQL 8.0支持JSON格式
  • DB-engine上,mysql和mongo都从本身定位逐步扩展为multi-model

参考:

《数据密集型应用系统设计》

都看到最后了,原创不易,点个关注,点个赞吧~
文章持续更新,可以微信搜索「阿丸笔记 」第一时间阅读,回复【笔记】获取Canal、MySQL、HBase、JAVA实战笔记,回复【资料】获取一线大厂面试资料。
知识碎片重新梳理,构建Java知识图谱:github.com/saigu/JavaK...(历史文章查阅非常方便)