数据库

零停机升级Postgres ，最近我们使用逻辑复制、一系列工具脚本 将 Postgres 11.9 升级到 15.3，实现了零停机。

在 KV 存储之上构建关系数据库的第一步是添加表。表只是一系列的行和列。列的某个子集被定义为“主键”；主键是唯一的，因此它们可用于引用行（在查询和二级索引中）。

最近，Google Cloud 推出了新功能，可将数据从 Pub/Sub 直接流式传输到 BigQuery。有了这个新的 BigQuery 订阅功能，我可能会有另一种替代解决方案。

由于我们的 B 树是不可变的，因此对 KV 存储的每次更新都会在路径中创建新节点，而不是更新当前节点，从而导致某些节点无法从最新版本访问。我们需要重用旧版本中这些不可达的节点，否则数据库文件将无限增长

B 树数据结构可以轻松转储到磁盘。让我们在它上面构建一个简单的 KV 存储。由于我们的 B 树实现是不可变的，因此我们将以仅追加的方式分配磁盘空间，磁盘空间的重用将推迟到下一章。

这个 B 树实现非常小，但最小对于学习来说是有好处的。现实世界的实现可能要复杂得多，并且包含实际的优化。

本章在 Golang 中实现了一个不可变的 B+ 树。实现是最小的，因此很容易跟着完成。我们的B树最终会被持久化到磁盘上，所以我们需要首先设计B树节点的传输格式。如果没有格式，我们将不知道节点的大小以

B 树的平衡与 BST 不同，流行的 BST（如 RB 树或 AVL 树）在子树的高度上进行平衡（通过旋转）。虽然所有 B 树叶节点的高度相同，但 B 树通过节点的大小进行平衡

数据库索引主要用于 范围查询和点查询，很容易看出范围查询只是点查询的超集。如果我们提取数据库索引的功能，那么创建一个键值存储就很简单了。所以重点是数据库系统可以构建在 KV 存储之上。

本章展示了简单地将数据转储到文件的局限性以及数据库要解决的问题。 数据什么时候真正持久化到磁盘上？ `write` 系统调用返回后，数据可能仍在操作系统的页面缓存中。当系统崩溃并重新启动时，文件的状态

本书包含了最小的可持久化的数据库实现。而且实现过程是渐进的。我们从 B-Tree 开始，然后在每一章中添加一个新概念，最终从简单的 KV 到迷你关系数据库。

使用 PostgreSQL 作为全文搜索引擎很诱人，因为它需要的基础设施较少。但它的搜索相关功能集是否足以与基于 Lucene 的替代方案竞争？ 在第 1 部分中，我们深入研究了 PostgreSQL

开发人员分为三种类型：第一种是知道索引可以加快数据库查询速度，第二种是知道索引可以加快数据库查询速度并占用额外的空间和时间，第三种是对索引及不同的索引类型优点和缺点有更深刻了解的人。一般情况下，第一组

PostgreSQL 提供了必要的模块，可以组合和创建自己的全文搜索搜索引擎。让我们尝试一下。 这是系列文章的第 1 部分，将要在其中探索 PostgreSQL 中的全文搜索功能，并研究我们可以完成多

我们之前的博客文章“我们最讨厌的 PostgreSQL 部分”讨论了大家最喜欢的 DBMS 多版本并发控制 (MVCC) 实现所带来的问题。其中包括版本复制、表膨胀、索引维护和真空管理。本文将探讨针对

数据库有很多（截至 2023 年 4 月有 897 个）。面对如此多的数据库，很难知道该选择什么！但有一个有趣的现象，互联网集体决定新应用程序的默认选择。在 2000 年代，传统观点选择 MySQL

1. 概述 Debezium 信号机制提供了一种方法来修改连接器的行为，或触发一次性操作，例如启动表的 临时快照。要触发连接器执行指定操作，可以发出特殊的SQL 命令以将信号消息添加到专门的信号表，也

要求表的引擎是innodb 且是每个表是单独表空间， 表空间导出和导入可以快速迁移大量数据。 实验版本mysql 8.0.25

上文讨论了 RR 隔离级别 主键索引的加锁情况， 本文接着讨论 RR 隔离级别下 二级唯一索引和普通二级索引 以及无索引时的加锁情况。

通常将Debezium connectors 部署到 Kafka Connect 服务中,并配置一个或多个连接器来监控上游数据库 ，这些连接器会捕获上游数据库中所有更改后生成数据更改事件。