很多时候我们都会有这样的疑问。
如果这时候直接去看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
参考：
《数据密集型应用系统设计》