【如此简单！数据库入门系列】之前世今生(2) -- 数据库历史

---

回顾

接上次【如此简单！数据库入门系列】之前世今生

---

新势力 – NoSQL登场

NoSQL最早出现在什么时候呢？

在1998年，Carlo Strozzi使用“NoSQL”这个术语命名了他创造的数据库Strozzi NoSQL（最早出现NoSQL字眼）。然而，从本质上讲，这种数据库仍然是关系型的，并不是我们理解的NoSQL。

直到2009年，开发人员Johan Oskarsson组织了一次讨论非关系型数据库的活动，NoSQL术语才重新进入视野。从那时起，NoSQL开始快速发展。

NoSQL的含义是什么呢？

有人说“NoSQL”代表“非SQL”，也有人说代表“不仅仅是SQL(Not Only SQL)”。不管怎样，大多数人都同意NoSQL数据库是以关系表以外的格式存储数据的数据库。关系表对应SQL，非关系表自然对应NoSQL。

既然已经有了SQL，为什么还需要NoSQL呢？

先总结一下关系数据库的缺点：

1. 数据建模的刚性
   • 关系数据库最大的限制之一是：将数据组织成表以及表之间关联的刚性结构
   • 为了避免数据重复（Normalization要求），需要创建复杂且难以管理的数据模型（例如雪花模型和星型模型）
   • 这种方法无法存储天然数据，也不能存储为树和图
2. 空间浪费
   • 定义关系的模式时，同时也定义了所有属性的大小
   • 然而，并不是所有的记录都有完整的数据，甚至有些数据不需要存储某些属性
3. 模式变更成本高
   • 对一个模式进行修改，可能会影响所有的数据，这种重量级的修改通常是昂贵且不可行的

再让我们回顾一下2000年之后发生了哪些变化？

• 存储成本大幅下降：
  • 相对而言，开发人员成为软件开发的主要成本
  • 导致应用程序需要存储和查询的数据量也在增加
  • 不仅数据量急剧增加，数据形态也呈现多样化趋势（分为结构化、半结构化和非结构化数据），导致提前定义模式几乎是不可能的
• 开发模式的转变：
  • （思想转变）敏捷方法逐步流行，促使开发人员重新思考软件开发模式，渐渐认识到如何迅速适应不断变化的需求才是根本问题。
  • （行动转变）开发人员开始快速迭代整个软件堆栈，使得各个组件能够快速应对需求变化，这其中也包含数据库。
• 云计算兴起：
  • 开发人员开始使用公共云来托管他们的应用程序和数据
  • 希望能够跨服务器和区域分发数据，以使应用程序具有弹性

正是因为关系数据库很难满足这些新需求，才给了NoSQL数据库快速发展的机会。NoSQL数据库如何满足这些需求呢？

NoSQL数据库：

• 允许宽松的模式，甚至无模式，允许为了追求性能而存在数据重复
• 操作接口简单，用户界面友好，降低开发人员学习和使用成本
• 支持海量半结构化和非结构化数据的存储和计算
• 提供强大灵活的管理功能
• 支持横向弹性扩展，便于部署在云计算环境中

NoSQL数据库具体可以分为哪些类型？

NoSQL数据库会针对特定目的设计专用的数据存储。通常，按照存储格式可以分为以下四种：

1. 键值（Key-Value）存储，也称为键值数据库
   • 顾名思义，每个数据项包含键和值
   • 例如，Redis（一种内存键值数据库）
2. 文档（Document ）存储：也称为文档数据库。
   • 它将数据存储在类似于JSON (JavaScript Object Notation)对象的文档中。
   • 每个文档包含字段和值。值通常可以是各种类型，包括字符串、数字、布尔值、数组或对象
   • 例如，MongoDb
3. 宽列（Wide Column）存储，也称为列族数据库（Column Family Databases）
   • 数据被组织成列族，每个列族可以有自己的列集，且可以针对不同类型的查询进行优化
   • 列族是行和列的集合，每行有一个唯一键，每列有一个名称、值和时间戳
   • 例如，Apache Hbase
4. 图形（Graph ）数据库
   • 将数据存储在节点和边中
   • 节点通常存储有关人、地点和事物的信息，而边存储有关节点之间关系的信息
   • 例如，Neo4j

---

王者归来 – NewSQL出现

NoSQL一时风光无限，难道SQL就此没落了吗？

NoSQL旨在解决SQL所施加的限制。其设计目的在于：

1. 处理海量半结构化和非结构化数据
2. 提供快速响应
3. 支持水平扩展

NoSQL一度被认为是大数据应用程序的理想数据库系统。然而，它并没有达到目标，因为：

1. 缺乏一致性
   • NoSQL更注重可用性而不是一致性，在必须支持一致性的场景下，它无法胜任
   • 数据节点之间的数据可能存在不一致，从而增加系统故障的风险
2. 缺乏标准化
   • 没有特定的标准语言，虽然某些数据库支持了类SQL语言，但始终没有形成统一的查询语言。
3. 缺乏安全性
   • 无法提供数据层面的安全性
4. 缺乏事务支持
   • 无法提供完整的ACID支持
   • 无法适用于依赖事务的交易型场景

既然NoSQL帮不上忙，该如何应对“一致性+事务+水平扩展”的场景呢？

早期的应对策略是：

1. 一个强大的单节点机器，它可以处理所有事务
2. 一个定制的中间件系统，在传统的DBMS节点上分发查询

但这两种方法的实施都非常昂贵。因此，需要一种折中方案：将NoSQL系统的分布式架构与多节点并发特性和一种全新的存储机制结合起来 – NewSQL。

NewSQL是一类现代化的关系数据库系统，它追求：

• 提供OLTP工作负载的同时
• 也支持与NoSQL相同的可伸缩性能
• 同时保证事务符合RDBMS中的ACID要求

换句话说，这些系统希望实现NoSQL的可伸缩性，同时不必放弃SQL关系模型和DBMS的事务支持。例如，CockroachDB和TiDB。

---

展望

数据库系统未来会往那些方向发展呢？

1. 云数据库。据调查，2023年数据库市场中，云数据库份额已经超过50%，数据库上云是大势所趋。
2. 多模融合。 SQL和NoSQL的界限正在变得模糊，SQL数据库也在支持非结构化数据，而NoSQL在一致性和事务方面有所增强。
3. 混合负载。同时支持OLTP和OLAP的HTAP数据库系统。
4. 与AI结合，又分为AI for DB和DB for AI两个方向。
   • AI for DB：AI在数据库中的应用，例如自适应配置、AI优化查询计划和AI数据清洗等
   • DB for AI：向量数据库或数据库向量化，为支持AI应用而生的专用数据库系统
5. 开源。利用开源社区力量做大做强，也是一个发展方向，例如国内的OpenGauss和国外的Postgresql等。
6. 生产力提升。数据库的监控可视化、故障诊断、慢SQL分析等针对于数据库核心功能的分析工具进一步提升，可以极大地提高数据库的易用性，降低数据库产品使用的门槛

---

总结

• 数据库系统的发展与计算机、网络和存储的发展密切相关。每当成本降低和应用模式发生变化时，会催生大量新的需求，从而促进新技术的研发和应用。
• 没有哪种产品能够解决所有问题。脱离场景谈好产品就是耍流氓。还记得这篇文章中的观点吗？好方案一定是有针对性的
• 新技术和新产品，对你来说不一定就好。从实际问题出发，能有效解决问题的就是好产品。不能光看先进的好处，而忽略了先进的风险。
• NewSQL出现，并不意味着传统SQL没有市场。同样，也要看具体场景、成本和抗风险程度。