|
|
一、什么是分布式数据库
分布式数据库是一种将数据存储在多个物理位置的数据库系统。
这些位置可以是同一网络中的不同节点，也可以是地理散的数据中心。
分布式数据库通过分布式架构现数据的存储和管理，具备以下特点：
复制
1.数据分布：数据分散在多个节点上，每个节点可以单独处理部分数据。
2.透明性：用户需关心数据的物理存储位置，系统会自动处理数据访问和操作。
3.高可用性：通过数据复制和冗余，即使部分节点故障，系统仍能正常运行。
4.扩展性：可以通过增加节点来扩展存储容量和处理能力。
5.并行处理：多个节点可以同时处理任务，提升性能。
1.
2.
3.
4.
5.
二、分布式数据库发展历史
分布式数据库的发展历史可以追溯到20世纪70年代，随着计算机技术和网络技术的进步，分布式数据库逐渐从理论走向践，并在现代大数据和云计算时代得到广泛应用。
以下是分布式数据库发展的主要阶段和里程碑：
1.早期理论探索（1970年代）
背景：计算机网络开始发展，研究者开始探索如何将数据分布在多个节点上。
重要贡献：
1976年，IBM的研究员E.F.Codd提出了关系模型，为数据库理论奠定了基础。
1979年，C.J.Date提出了分布式数据库的“12条规则”，定义了分布式数据库的理想特性。
早期的研究集中在数据分片、分布式事务和一致性协议上。
2.原型系统出现（1980年代）
背景：计算机网络技术逐渐成熟，分布式数据库从理论研究走向践。
重要系统：
SDD-1：由美国计算机公司CCA开发，是首个分布式数据库原型系统。
R*项目：由IBM开发，研究了分布式查询化和事务管理。
Ingres/Star：加州大学伯克利分校开发的分布式数据库系统，支持数据分片和分布式查询。
技术进展：
分布式事务管理（如两阶段提交协议，2PC）。
数据分片和分布式查询化。
3.商业化和初步应用（1990年代）
背景：企业开始需要跨地域的数据管理和高可用性解决方案。
重要系统：
Oracle RAC（Real Application Clusters）：Oracle推出的分布式数据库解决方案，支持多节点共享存储。
IBM DB2 Distributed Database：IBM推出的分布式数据库产品。
技术进展：
分布式数据库的商业化应用逐渐增多。
数据复制和分布式事务管理技术进一步完善。
4.互联网时代和大数据兴起（2000年代）
背景：互联网的速发展导致数据量激增，传统集中式数据库难以应对。
重要系统：
Google Bigtable（2022年）：Google开发的分布式存储系统，为后来的NoSQL数据库提供了灵感。
Amazon Dynamo（2022年）：Amazon开发的分布式键值存储系统，提出了比较终一致性和去中心化的设计理念。
Apache Hadoop（2022年）：开源分布式计算框架，支持大规模数据存储和处理。
技术进展：
NoSQL数据库兴起，强调高可用性和扩展性。
CAP理论（一致性、可用性、分区容错性）被提出，成为分布式系统设计的理论基础。
5.现代分布式数据库（2022年代至今）
背景：云计算和大数据技术的普及，推动了分布式数据库的进一步发展。
重要系统：
Cassandra：开源分布式NoSQL数据库，适合高可用性和大规模数据存储。
MongoDB：文档型分布式数据库，支持灵活的数据模型。
GoogleSpanner（2022年）：全球分布式数据库，支持强一致性和高可用性。
CockroachDB：受Spanner启发，开源的分布式SQL数据库。
TiDB：开源的分布式NewSQL数据库，兼容MySQL协议。
技术进展：
NewSQL数据库兴起，结合了SQL数据库的一致性和NoSQL数据库的扩展性。
分布式数据库在云原生环境中得到广泛应用。
数据分片、多副本一致性、分布式事务等技术进一步成熟。
:分布式事物如何现的
分布式事务是分布式数据库中的一个核心问题，其目标是保证跨多个节点的事务操作满足ACID特性（原子性、一致性、隔离性、持久性）。
由于分布式环境下节点间的通信延迟和故障风险，现分布式事务比集中式事务复杂得多。
以下是分布式事务的几种主要现方式及其原理和差异：
1. 两阶段提交（2PC, Two-Phase Commit）
原理：
阶段一：准备阶段：
1）协调者（Coordinator）向所有参与者（Participants）发送“准备请求”。
2）参与者执行事务操作，并将结果（成功或失败）返回给协调者。
阶段二：提交阶段：
1） 如果所有参与者都返回“成功”，协调者发送“提交请求”。
2） 如果有任何一个参与者返回“失败”，协调者发送“回滚请求”。
3）参与者根据协调者的指令提交或回滚事务。
点：
现简单，适合强一致性场景。
保证事务的原子性。
缺点：
同步阻塞：在准备阶段，所有参与者必须等待协调者的指令，可能导致长时间阻塞。
单点故障：协调者故障可能导致整个系统法继续。
性能开销：需要多次网络通信，延迟较高。
适用场景：
对一致性要求极高的场景，如金融交易。
2. 阶段提交（3PC, Three-Phase Commit）
原理：
阶段一：准备阶段：
1） 协调者向所有参与者发送“准备请求”。
2） 参与者执行事务操作，并将结果返回给协调者。
阶段二：预提交阶段：
1）如果所有参与者都返回“成功”，协调者发送“预提交请求”。
2） 参与者确认可以提交事务。
阶段：提交阶段：
1）协调者发送“提交请求”。
2） 参与者提交事务。
点：
减少了阻塞时间，提高了系统的可用性。
通过预提交阶段降低了协调者故障的影响。
缺点：
现复杂，通信开销更大。
仍然存在单点故障问题。
适用场景：
对一致性和可用性要求较高的场景。
3. Paxos算法
原理：
Paxos是一种分布式共识算法，用于在多个节点之间达成一致。
角色：
Proposer：提出提案。
Acceptor：接受或拒绝提案。
Learner：学习比较终达成一致的提案。
过程：
1） Proposer向Acceptor发送提案。
2）Acceptor根据多数原则接受或拒绝提案。
3） 一旦提案被多数Acceptor接受，Learner学习该提案。
点：
高容错性，即使部分节点故障也能达成一致。
适合高可用性场景。
缺点：
现复杂，难以理解。
性能开销较大。
适用场景：
分布式系统中的一致性协议，如Google Chubby。
4.Raft算法
原理：
Raft是一种简化版的分布式共识算法，将共识问题分解为领导者选举、日志复制和安全性个子问题。
角色：
Leader：负责处理客户端请求和日志复制。
Follower：被动接收Leader的指令。
Candidate：参与领导者选举。
过程：
1）领导者选举：当Leader故障时，Follower成为Candidate并发起选举。
2） 日志复制：Leader将日志复制到所有Follower。
3）提交日志：当多数Follower确认日志后，Leader提交日志。
点：
易于理解和现。
高可用性和容错性。
缺点：
性能开销较大，尤其是在网络分区的情况下。
适用场景：
分布式系统中的一致性协议，如etcd、Consul。
5. Saga模式
原理：
Saga是一种比较终一致性的事务模型，将长事务分解为多个本地事务。
类型：
Choreography：每个本地事务发布事件，其他事务监听并执行相应操作。
Orchestration：通过一个协调者（Orchestrator）控制事务的执行顺序。
补偿机制：
如果某个本地事务失败，Saga会执行补偿操作（回滚）来撤销之前的事务。
点：
适合长事务和跨服务的事务。
避免了全局锁，提高了并发性能。
缺点：
现复杂，需要设计补偿逻辑。
只能保证比较终一致性。
适用场景：
微服务架构中的跨服务事务。
6.Google Spanner的TrueTime
原理：
Spanner使用TrueTime API现全局一致性。
TrueTime：
通过GPS和原子钟提供高精度的时间戳。
保证事务的时间顺序和一致性。
两阶段提交+时间戳：
1） 事务开始时获取一个时间戳。
2）使用两阶段提交协议执行事务。
3） 根据时间戳保证全局一致性。
点：
强一致性，适合全球分布式数据库。
高性能，减少了锁冲突。
缺点：
依赖硬件（GPS和原子钟），成本较高。
现复杂。
适用场景：
全球分布式数据库，如Google Spanner。
图片
图片
我们有充分的理由相信领域知识图谱会成为行业的主流，会逐步影响越来越多的人。悦数图数据库是一款完全自主研发的国产图数据库和原生分布式图数据库,具有高性能,易扩展,安全稳定,自主可控的特点.万亿级数据仅需毫秒级查询延时,应用于金融风控,实时推荐,知识图谱等业务场景。https://www.yueshu.com.cn/
|
|
发表于 