# 数据库的前世今生 ## 信息系统和数据存储 1936年阿兰·图灵提出的的计算机模型，系统由数据存储（Tape）、寄存器和处理逻辑构成。现在最复杂的信息系统也同样沿用这种架构，只是将磁带Tape换成了数据库。 ## 数据库技术发展历史 - 混沌洪荒（50年代-60年代）：初步的数据理论，原生的数据结构和文件组织 - 文明曙光（60年代-80年代）：层次型数据库和网状数据库 - 一统天下（90年代-00年代中）：关系型数据库，1986年：ANSI把SQL作为关系数据库语言的美国标准，公布标准SQL文本。 - 群雄争霸（00年代后-20年代）：关系型数据库，NewSQL，NoSQL的崛起，**1998年：NoSQL**一词诞生，、不提供ACID的数据库设计模式99年提出NoSQL的概念，2008年：开源的Hives与Cassandra数据库，09年，MongoDB，Redis，10年ES，带动数据库产业技术上的变动，非关系型数据库逐渐普及。 - 群雄争霸（20年代-现在）： newSQL的出现（2012年：谷歌发布**spanner**论文），云数据库打破了原来数据库厂商的格局（2015年7月：Amazon正式发布关系型数据库Amazon Aurora）。云原生数据，MPP数据库，分布式数据库，图数据库，向量数据库等 ## IT技术现状 ### 技术趋势：分布式是解决信息大爆炸的必经之路 设计良好的分布式系统，可以解决传统集中式无法解决的众多问题，事件视界望远镜（EHT）：利用分布在世界各地的射电望远镜，组成一台巨大的虚拟望远镜，其口径相当于地球直径。IT系统也越来越多的使用分布式来实现大规模的计算和存储，比如大数据，大模型训练，互联网大并发的系统。 ### 技术趋势：开源和云是目前是技术趋势 另外一个趋势就是开源和云计算，有句话软件正在吃掉世界，未来已来，现在基本生活的方方面面都被软件控制，大到卫星和飞机，小到支付和出行，都离不开软件。而软件行业正被开源说主导，随着开源的发展，通过云计算来进行开源的部署和管理成为趋势。 ## 数据库的趋势 ### SQL仍然是主流，数据库类型百花齐放 SQL仍然是当前数据库的主流，随着应用对弹性的需求和运维简化的要求，云数据库逐步普及 ### 开源数据库和商用数据库平分秋色 2021年1月：DB-Engines的排行榜，开源数据库第一次超过了商业数据库（包括了云数据库），现在开源数据库的流行度以50.6分领先于商业数据库。 ### 分布式数据库普及，云数据库崛起 分布式数据库可以跨越多个服务器和数据中心，提供高可用性和容错能力，能够处理大规模数据和高并发访问，适用于互联网、金融等对性能要求高的行业 云数据库凭借云计算平台的高可用性、可扩展性以及按需付费的模式，能够根据自身业务需求灵活扩展或收缩存储和计算资源，降低了基础设施建设成本和运维难度，成为众多企业的首选。 ### 人工智能与数据库结合，自治数据库概念 - 自动优化：AI技术用于自动优化数据库性能，如自动调整索引、查询优化等。 - 智能管理：通过机器学习算法预测和预防数据库故障，提升数据库的稳定性和管理效率 - 向量数据库：高效的相似性搜索和索引技术，向量数据库可以与机器学习模型无缝集成，支持模型的训练和推理过程。 ### 多模型数据库的兴起 - 支持多种数据模型：多模型数据库能够同时支持关系型、文档型、图型等多种数据模型，满足复杂业务需求。 # 数据库的选项 ## 相关的技术背景（应用扩展模型， CAP， ACID， 最终一致性） ### ACID（刚性事务） 数据库的一大难点就是保证事务的正确执行， ACID 是指数据库事务正确执行的四个基本要素， - **原子性（Atomicity）**：事务中的所有操作要么全部完成，要么全部不完成，不能存在部分完成的情况。就像一个原子不可分割一样，事务是一个不可分割的工作单位。例如在银行转账事务中，转出账户扣钱和转入账户加钱这两个操作必须同时成功，如果其中一个操作失败，整个事务就会回滚，回到事务开始前的状态，保证账户余额的正确性，不会出现转出账户钱扣了但转入账户没收到钱的情况。 - **一致性（Consistency）**：事务执行前后，数据库必须处于一致的状态。即事务执行的结果要使数据库从一个一致性状态转变到另一个一致性状态，数据库的完整性约束不能被破坏。以转账为例，转账前两个账户的总金额为一定值，转账后两个账户的总金额也应该保持不变，不能因为转账操作导致总金额出现变化，确保数据的准确性和完整性。 - **隔离性（Isolation）**：在并发环境中，并发的事务之间是相互隔离的，一个事务的执行不能被其他事务干扰。不同的事务并发操作相同的数据时，每个事务都有各自完整的数据空间，一个事务内部的操作及使用的数据对其他并发事务是隔离的。比如多个用户同时对同一账户进行操作，一个用户的操作在未提交前，其他用户不应该看到该操作的中间结果，避免数据混乱和不一致。 - **持久性（Durability）**：一个事务一旦提交，它对数据库中对应数据的状态变更就应该是永久性的，即使数据库系统遇到故障，如停电、系统崩溃等，也不会丢失提交事务的操作结果。例如银行转账成功后，即使后续系统出现问题，转账记录和账户余额的变更也应该被保留下来，不会恢复到转账前的状态。 ### CAP 在分布式系统设计中，CAP原则是指导系统设计者在一致性（Consistency）、可用性（Availability）和分区容忍性（Partition tolerance）之间进行权衡的重要理论。该原则指出，分布式系统无法同时满足这三个特性，最多只能满足其中的两个。 - 一致性（Consistency）：一致性是指在分布式系统中，所有副本的数据始终保持一致。无论从哪个节点访问，用户都能看到相同的数据。这通常通过同步机制实现，确保所有节点在写操作后立即更新数据副本。 -  可用性（Availability）：可用性指的是系统在正常运行时能够快速响应请求，确保服务的连续性。即使部分节点出现故障，系统仍能通过其他节点提供服务。 - 分区容忍性（Partition tolerance）：分区容忍性是指系统在面对网络分区时仍能正常工作。网络分区可能由网络故障、节点失效或延迟增加引起，系统需要在这种情况下保持数据的一致性和服务的可用性。 ### BASE - **基本可用（Basically Available）**：在分布式系统出现故障时，允许损失部分非核心功能的可用性，但要保证核心功能可用。比如在电商系统中，交易付款功能出现故障，不过商品依然可以正常浏览，用户仍能进行部分关键操作，不会导致整个系统完全不可用。 - **软状态（Soft State）**：不要求数据在任何时刻都保持强一致性，允许系统中的数据存在中间状态，即数据在一段时间内可能处于不一致的状态。例如在数据同步过程中，会出现 “数据同步中” 这样的中间状态，直到最终数据达到一致后才变为成功状态。 - **最终一致（Eventually Consistent）**：经过一段时间后，所有分布式节点上的数据最终会达到一致状态。比如在分布式数据库中，数据更新操作可能不会立即在所有节点上生效，但随着时间推移，通过数据复制、同步等机制，所有节点的数据最终会达成一致。 ###  分布式架构模式 - share everything：多个处理器或节点共享同一个数据库存储系统、内存和其他资源。优点是实现相对简单，易于管理和维护，能够充分利用共享资源，适用于小型到中型规模的数据库应用，能满足一定的并发处理需求。缺点是可扩展性差。 - share nothing：每个节点都有自己独立的处理器、内存和存储设备，节点之间不共享任何物理资源。数据被分区并分布在各个节点上，每个节点负责处理自己的数据。优点是具有良好的可扩展性，能够通过增加节点来处理更多的数据和并发请求，性能随节点数量增加而线性增长。缺点是架构复杂，需要解决数据一致性和分布式事务等问题。 - share disk：-多个节点共享同一个磁盘存储系统，但每个节点拥有自己独立的处理器和内存。节点通过高速网络连接到共享磁盘，数据可以在多个节点之间共享和访问。优点是可以在一定程度上实现资源共享，减少存储成本，同时能够提供较好的并发处理能力。缺点是共享磁盘可能成为性能瓶颈。 - 存算分离：将数据存储和计算功能分离到不同的节点或系统中。存储节点专门负责数据的持久化和管理，计算节点则负责处理数据的计算任务，两者通过高速网络进行通信。优点是可以根据业务需求灵活地扩展存储和计算资源，存储资源可以独立于计算资源进行扩展，实现资源的按需分配和高效利用。缺点是系统复杂，通常需要特殊的硬件支持。 ## 数据库选型的参考维度 ### 数据库的类型 - SQL数据库：适合结构化数据、高一致性和复杂查询，如金融系统。延迟低，支持复杂查询，支持全部的并行级别。 - NoSQL数据库：适合非结构化数据、高扩展性和高并发，如社交媒体和物联网。 - NewSQL数据库：适合需要扩展性和结构化查询的应用，如实时分析和电子商务。分布式系统中保持一致性而引入一定的延迟，复杂查询和OLTP不可兼得。支持部分的并行级别 ### 非技术因素 - 合规性：业务数据是否可以存放在公有云上？是否需要特定的认证，如信创证书？ - 成本：在可以接受的成本内，寻找最佳的解决方案？ 除了硬件成本，软件成本，开发的学习成本和后期的运维成本往往被忽略。 - 团队能力：是否有开发该类数据库的经验，运维团队是否能够支持选型的数据库 ### 技术因素 - 数据结构：结构化数据 VS 非结构化数据。如果是非结构化数据，NoSQL是个很好的选择 - 读写比例：读写比例如何，是否有复杂的查询需求 - 一致性：需要强一致性还是最终一致性？ - 扩展性：是否需要水平扩展或分布式架构？ - 数据量：需要处理的数据量，每个数据库都有数据处理上限 - 延迟性能：对于数据库访问时时延的要求 - 可用性要求：数据库提供的最高备份策略能否满足业务需求 ## 数据选型的建议 - 数据库的架构为所谓好坏，只选**合适**不选先进的。集中式数据可以满足大部分的应用场景。 - 不要指望数据库可以解决一切问题，有时**应用程序才是正道**。通过微服务的合理拆分，将复杂的数据结构进行分解；通过CQRS，可以大大减低对数据库依赖。 - 弱水三千，只取一瓢，瓢的大小由你的**运维能力**决定。一个系统的数据库最好不要超过3种，如果使用公有云全托管服务，不要超过5种 # 数据库的前世今生 ## 信息系统和数据存储 1936年阿兰·图灵提出的的计算机模型，系统由数据存储（Tape）、寄存器和处理逻辑构成。现在最复杂的信息系统也同样沿用这种架构，只是将磁带Tape换成了数据库。 ## 数据库技术发展历史 - 混沌洪荒（50年代-60年代）：初步的数据理论，原生的数据结构和文件组织 - 文明曙光（60年代-80年代）：层次型数据库和网状数据库 - 一统天下（90年代-00年代中）：关系型数据库，1986年：ANSI把SQL作为关系数据库语言的美国标准，公布标准SQL文本。 - 群雄争霸（00年代后-20年代）：关系型数据库，NewSQL，NoSQL的崛起，**1998年：NoSQL**一词诞生，、不提供ACID的数据库设计模式99年提出NoSQL的概念，2008年：开源的Hives与Cassandra数据库，09年，MongoDB，Redis，10年ES，带动数据库产业技术上的变动，非关系型数据库逐渐普及。 - 群雄争霸（20年代-现在）： newSQL的出现（2012年：谷歌发布**spanner**论文），云数据库打破了原来数据库厂商的格局（2015年7月：Amazon正式发布关系型数据库Amazon Aurora）。云原生数据，MPP数据库，分布式数据库，图数据库，向量数据库等 ## IT技术现状 ### 技术趋势：分布式是解决信息大爆炸的必经之路 设计良好的分布式系统，可以解决传统集中式无法解决的众多问题，事件视界望远镜（EHT）：利用分布在世界各地的射电望远镜，组成一台巨大的虚拟望远镜，其口径相当于地球直径。IT系统也越来越多的使用分布式来实现大规模的计算和存储，比如大数据，大模型训练，互联网大并发的系统。 ### 技术趋势：开源和云是目前是技术趋势 另外一个趋势就是开源和云计算，有句话软件正在吃掉世界，未来已来，现在基本生活的方方面面都被软件控制，大到卫星和飞机，小到支付和出行，都离不开软件。而软件行业正被开源说主导，随着开源的发展，通过云计算来进行开源的部署和管理成为趋势。 ## 数据库的趋势 ### SQL仍然是主流，数据库类型百花齐放 SQL仍然是当前数据库的主流，随着应用对弹性的需求和运维简化的要求，云数据库逐步普及 ### 开源数据库和商用数据库平分秋色 2021年1月：DB-Engines的排行榜，开源数据库第一次超过了商业数据库（包括了云数据库），现在开源数据库的流行度以50.6分领先于商业数据库。 ### 分布式数据库普及，云数据库崛起 分布式数据库可以跨越多个服务器和数据中心，提供高可用性和容错能力，能够处理大规模数据和高并发访问，适用于互联网、金融等对性能要求高的行业 云数据库凭借云计算平台的高可用性、可扩展性以及按需付费的模式，能够根据自身业务需求灵活扩展或收缩存储和计算资源，降低了基础设施建设成本和运维难度，成为众多企业的首选。 ### 人工智能与数据库结合，自治数据库概念 - 自动优化：AI技术用于自动优化数据库性能，如自动调整索引、查询优化等。 - 智能管理：通过机器学习算法预测和预防数据库故障，提升数据库的稳定性和管理效率 - 向量数据库：高效的相似性搜索和索引技术，向量数据库可以与机器学习模型无缝集成，支持模型的训练和推理过程。 ### 多模型数据库的兴起 - 支持多种数据模型：多模型数据库能够同时支持关系型、文档型、图型等多种数据模型，满足复杂业务需求。 # 数据库的选项 ## 相关的技术背景（应用扩展模型， CAP， ACID， 最终一致性） ### ACID（刚性事务） 数据库的一大难点就是保证事务的正确执行， ACID 是指数据库事务正确执行的四个基本要素， - **原子性（Atomicity）**：事务中的所有操作要么全部完成，要么全部不完成，不能存在部分完成的情况。就像一个原子不可分割一样，事务是一个不可分割的工作单位。例如在银行转账事务中，转出账户扣钱和转入账户加钱这两个操作必须同时成功，如果其中一个操作失败，整个事务就会回滚，回到事务开始前的状态，保证账户余额的正确性，不会出现转出账户钱扣了但转入账户没收到钱的情况。 - **一致性（Consistency）**：事务执行前后，数据库必须处于一致的状态。即事务执行的结果要使数据库从一个一致性状态转变到另一个一致性状态，数据库的完整性约束不能被破坏。以转账为例，转账前两个账户的总金额为一定值，转账后两个账户的总金额也应该保持不变，不能因为转账操作导致总金额出现变化，确保数据的准确性和完整性。 - **隔离性（Isolation）**：在并发环境中，并发的事务之间是相互隔离的，一个事务的执行不能被其他事务干扰。不同的事务并发操作相同的数据时，每个事务都有各自完整的数据空间，一个事务内部的操作及使用的数据对其他并发事务是隔离的。比如多个用户同时对同一账户进行操作，一个用户的操作在未提交前，其他用户不应该看到该操作的中间结果，避免数据混乱和不一致。 - **持久性（Durability）**：一个事务一旦提交，它对数据库中对应数据的状态变更就应该是永久性的，即使数据库系统遇到故障，如停电、系统崩溃等，也不会丢失提交事务的操作结果。例如银行转账成功后，即使后续系统出现问题，转账记录和账户余额的变更也应该被保留下来，不会恢复到转账前的状态。 ### CAP 在分布式系统设计中，CAP原则是指导系统设计者在一致性（Consistency）、可用性（Availability）和分区容忍性（Partition tolerance）之间进行权衡的重要理论。该原则指出，分布式系统无法同时满足这三个特性，最多只能满足其中的两个。 - 一致性（Consistency）：一致性是指在分布式系统中，所有副本的数据始终保持一致。无论从哪个节点访问，用户都能看到相同的数据。这通常通过同步机制实现，确保所有节点在写操作后立即更新数据副本。 -  可用性（Availability）：可用性指的是系统在正常运行时能够快速响应请求，确保服务的连续性。即使部分节点出现故障，系统仍能通过其他节点提供服务。 - 分区容忍性（Partition tolerance）：分区容忍性是指系统在面对网络分区时仍能正常工作。网络分区可能由网络故障、节点失效或延迟增加引起，系统需要在这种情况下保持数据的一致性和服务的可用性。 ### BASE - **基本可用（Basically Available）**：在分布式系统出现故障时，允许损失部分非核心功能的可用性，但要保证核心功能可用。比如在电商系统中，交易付款功能出现故障，不过商品依然可以正常浏览，用户仍能进行部分关键操作，不会导致整个系统完全不可用。 - **软状态（Soft State）**：不要求数据在任何时刻都保持强一致性，允许系统中的数据存在中间状态，即数据在一段时间内可能处于不一致的状态。例如在数据同步过程中，会出现 “数据同步中” 这样的中间状态，直到最终数据达到一致后才变为成功状态。 - **最终一致（Eventually Consistent）**：经过一段时间后，所有分布式节点上的数据最终会达到一致状态。比如在分布式数据库中，数据更新操作可能不会立即在所有节点上生效，但随着时间推移，通过数据复制、同步等机制，所有节点的数据最终会达成一致。 ###  分布式架构模式 - share everything：多个处理器或节点共享同一个数据库存储系统、内存和其他资源。优点是实现相对简单，易于管理和维护，能够充分利用共享资源，适用于小型到中型规模的数据库应用，能满足一定的并发处理需求。缺点是可扩展性差。 - share nothing：每个节点都有自己独立的处理器、内存和存储设备，节点之间不共享任何物理资源。数据被分区并分布在各个节点上，每个节点负责处理自己的数据。优点是具有良好的可扩展性，能够通过增加节点来处理更多的数据和并发请求，性能随节点数量增加而线性增长。缺点是架构复杂，需要解决数据一致性和分布式事务等问题。 - share disk：-多个节点共享同一个磁盘存储系统，但每个节点拥有自己独立的处理器和内存。节点通过高速网络连接到共享磁盘，数据可以在多个节点之间共享和访问。优点是可以在一定程度上实现资源共享，减少存储成本，同时能够提供较好的并发处理能力。缺点是共享磁盘可能成为性能瓶颈。 - 存算分离：将数据存储和计算功能分离到不同的节点或系统中。存储节点专门负责数据的持久化和管理，计算节点则负责处理数据的计算任务，两者通过高速网络进行通信。优点是可以根据业务需求灵活地扩展存储和计算资源，存储资源可以独立于计算资源进行扩展，实现资源的按需分配和高效利用。缺点是系统复杂，通常需要特殊的硬件支持。 ## 数据库选型的参考维度 ### 数据库的类型 - SQL数据库：适合结构化数据、高一致性和复杂查询，如金融系统。延迟低，支持复杂查询，支持全部的并行级别。 - NoSQL数据库：适合非结构化数据、高扩展性和高并发，如社交媒体和物联网。 - NewSQL数据库：适合需要扩展性和结构化查询的应用，如实时分析和电子商务。分布式系统中保持一致性而引入一定的延迟，复杂查询和OLTP不可兼得。支持部分的并行级别 ### 非技术因素 - 合规性：业务数据是否可以存放在公有云上？是否需要特定的认证，如信创证书？ - 成本：在可以接受的成本内，寻找最佳的解决方案？ 除了硬件成本，软件成本，开发的学习成本和后期的运维成本往往被忽略。 - 团队能力：是否有开发该类数据库的经验，运维团队是否能够支持选型的数据库 ### 技术因素 - 数据结构：结构化数据 VS 非结构化数据。如果是非结构化数据，NoSQL是个很好的选择 - 读写比例：读写比例如何，是否有复杂的查询需求 - 一致性：需要强一致性还是最终一致性？ - 扩展性：是否需要水平扩展或分布式架构？ - 数据量：需要处理的数据量，每个数据库都有数据处理上限 - 延迟性能：对于数据库访问时时延的要求 - 可用性要求：数据库提供的最高备份策略能否满足业务需求 ## 数据选型的建议 - 数据库的架构为所谓好坏，只选**合适**不选先进的。集中式数据可以满足大部分的应用场景。 - 不要指望数据库可以解决一切问题，有时**应用程序才是正道**。通过微服务的合理拆分，将复杂的数据结构进行分解；通过CQRS，可以大大减低对数据库依赖。 - 弱水三千，只取一瓢，瓢的大小由你的**运维能力**决定。一个系统的数据库最好不要超过3种，如果使用公有云全托管服务，不要超过5种