数据库
文章平均质量分 92
我乐了.
这个作者很懒,什么都没留下…
展开
-
领导选举:如何在分布式系统内安全地协调操作?
如果同步过程中需要所有参与的节点互相进行操作,那么其通信开销会非常巨大。如下图所示,随着参与节点的增加,其通信成本逐步提高,最终一定会导致数据在集群内不一致。尤其在超大型和地理空间上分散的集群网络中,此现象会进一步被放大。为了减少同步通信开销和参与节点的数量,一些算法引入了“领导者”(有时称为协调者),负责协调分布式系统内的数据同步。原创 2024-02-05 11:28:54 · 807 阅读 · 0 评论 -
错误侦测:如何保证分布式系统稳定?
每个节点是否应该被认为失败,是由多个节点判断的结果推导出的,并不是由单一节点做出的判断,这大大提高了系统的稳定性。它保存一个全局节点的心跳列表,上面记录了每一个节点的心跳状态,从而可以直观地看到系统中节点的健康度。这种算法的好处是不需要将心跳检测进行广播,而是通过有限的网络连接,就可以检测到集群中各个分组内的健康情况,从而得知整个集群的健康情况。由图可知,该算法需要生成一个节点间的主要路径,该路径就是数据流在节点间最常经过的一条路径,该路径同时要包含集群内的所有节点。从而节点 1 判断节点 2 是存活的。原创 2024-02-05 11:27:25 · 408 阅读 · 0 评论 -
事务处理与恢复(下):如何控制并发事务?
当提交发生的时候,事务会检测其修改和读取的数据在提交之前是否已经被其他已提交事务修改了,如果是,则会终止当前事务,并进行回滚。事务开始的时候,记录当前时间,而后该事务内所有的读取操作只能读到当前提交版本小于事务开始时间的数据,而未提交的数据和提交版本大于事务开始时间点的数据是不能读取出来的。但快照隔离的行为是:一旦读到曾经读过的数据被修改,将立即终止当前事务,也就是进行回滚操作。序列化是最强的事务隔离级别,它是非常完美的隔离状态,可以让并行运行的事务感知不到对方的存在,从而安心地进行自己的操作。原创 2024-02-05 11:25:14 · 763 阅读 · 0 评论 -
事务处理与恢复(上):数据库崩溃后如何保证数据不丢失?
事务管理是数据库中存储引擎的一个相当独立并且重要的组件,它可以保证对数据库的一系列操作看起来就像只有一步操作一样。这大大简化了面向数据库的应用的开发,特别是在高并发场景下,其意义更为重要。一个典型的案例就是转账操作:从甲处转 100 元给乙。现实生活中,这个操作是原子的,因为纸币是不可复制的。但是在计算机系统内,这个操作实际上是由两个操作组成:甲账户减 100、乙账户加 100。原创 2024-02-05 11:23:33 · 272 阅读 · 0 评论 -
日志型存储:为什么选择它作为底层存储?
至此,我们学习了一个典型的面向分布式数据库所使用的存储引擎。从其特点可以看到,它高速写入的特性对分布式数据库而言是有非常大吸引力的,同时其KV 结构更是分片所喜欢的一种数据格式,非常适合基于此构建分布式数据库。所以诸如 Apache Cassandra、ClickHouse 和 TiDB 等分布式数据库都选用 LSM 树或类似结构的存储引擎来构建分布式数据库。原创 2024-02-05 11:22:21 · 713 阅读 · 0 评论 -
分布式索引:如何在集群中快速定位数据?
SSTable 文件是一个排序的、不可变的、持久化的键值对结构,其中键值对可以是任意字节的字符串,支持使用指定键来查找值,或通过给定键范围遍历所有的键值对。这里要注意,SSTable 是不可变的,也就是输入一旦写入是不可以更改的,而修改和删除操作一般也是以写入的形式进行的。索引的结果一般保存的是主键,而后根据主键去查找数据。下面就是 RocksDB 的 SSTable 结构,可以看到数据是放在前面,后索引作为 metadata 放在文件尾部,甚至 meta 的索引也是放在整个 meta 结构的尾部。原创 2024-02-05 11:21:21 · 637 阅读 · 0 评论 -
什么是存储引擎,为什么需要了解它?
而后者一般采用索引文件的形式来存储数据,以 B+树为例,数据被存储在叶子节点上,这样做的目的是减少检索数据时读取磁盘的次数,同时对范围扫描支持友好。前者如哈希组织表和索引组织表那样,数据的分布与索引分布是有关联的,它们被“聚”在一起,这样的查询效率很好。而后者最常见的例子就是针对这两种数据文件的二级索引,因为二级索引要索引的列不是主键,故索引与数据是分割的,查询时需要进行多次磁盘读取。而列式存储可以被认为是这种模式的一种优化,实现该模式的必要条件是要有分布式系统,因为一台机器的处理能力是有瓶颈的。原创 2024-02-05 11:18:31 · 585 阅读 · 0 评论 -
一致性与 CAP 模型:为什么需要分布式一致性?
但实际是不行的,以 Raft 为例,算法只是保证了复制 Log 的线性一致,而没有描述 Log 是如何写入最终的状态机的,这就暗含状态机本身不是线性一致的。其中提到了,异步系统是无法满足可用性要求的,并且在存在网络分区的情况下,我们无法实现同时保证可用性和一致性的系统。由不同进程执行的并发读/写操作不是串行的,根据寄存器在操作重叠时的行为,它们的顺序可能不同,并且可能产生不同的结果。这里提到的“最大努力”意味着,如果一切正常,系统可以提供该特性的保证,但是在网络分区的情况下,允许削弱和违反这个保证。原创 2024-02-05 11:16:08 · 657 阅读 · 0 评论 -
数据复制:如何保证数据在分布式场景下的高可用?
我们深入介绍了复制技术在分布式数据库中的作用;探讨了单主和多主两种复制技术;而后通过 MySQL 复制技术的发展路径来介绍了复制技术的应用案例。原创 2024-02-05 11:14:20 · 759 阅读 · 0 评论 -
数据分片:如何存储超大规模的数据?
先是详细介绍了分片的原理,以及多种常用的分片技术;而后分析了手动分片与自动分片的区别,要知道数据分片的未来是属于自动分片的。原创 2024-02-05 11:12:32 · 605 阅读 · 0 评论 -
SQL VS NoSQL:一次搞清楚五花八门的“SQL”
SQL 是在 20 世纪 70 年代被关系型数据库所引入,在随后的几十年里一直被看作是数据库标准的查询接口,从而形成了深厚的群众基础。而后 2000 年左右出现的 NoSQL 潮流,本质上与 SQL 没有实际联系,但讽刺的是,它们不得不依靠 SQL 这个“对手”来定义自身的价值,从而使我们感叹 SQL 那顽强的生命力。又随着近十年 NewSQL 和 Distributed SQL 的发展,SQL 回归本源,从旧时代的霸主摇身变为新时代的先锋。原创 2024-02-05 11:10:24 · 884 阅读 · 0 评论 -
导论:什么是分布式数据库?聊聊它的前世今生
用《三国演义》的第一句话来说:“天下大势,分久必合,合久必分。”而我们观察到的分布式数据库,乃至数据库本身的发展正暗合了这句话。分布式数据库发展就是一个由合到分,再到合的过程早期的关系型商业数据库的分布式能力可以满足大部分用户的场景,因此产生了如 Oracle 等几种巨无霸数据库产品;OLAP 领域首先寻求突破,演化出了大数据技术与 MPP 类型数据库,提供功能更强的数据分析能力;原创 2024-02-05 11:08:04 · 1159 阅读 · 0 评论