HC-tree 是 SQLite 的实验性高并发数据库后端
本文译自：HC-tree is an experimental high-concurrency database back end for SQLite
HC-tree
SQLite有时用作客户端/服务器数据库系统的核心。 虽然它在这种情况下可靠地工作良好，但数据库后端模块 用于在其数据库文件中存储 B 树结构不是用这个设计的 考虑到这种情况，可以通过多种方式进行改进。HC树（hctree） 项目是开发一个新的数据库后端的尝试，以改进 常规SQLite如下：
-
**改进的并发性：**库存SQLite仅限于单个 并发编写器。
使用开始并发扩展会更改此设置，以便多个 编写器可以使用乐观页面级锁定并发运行。这 在一定程度上提高了并发性，但页面级锁定可以检测到 逻辑上独立的事务和 COMMIT 之间的冲突 操作仍必须序列化。
Hctree 使用乐观行级锁定，旨在支持 数十个并发写入器全速运行。从原型中获得的测试结果 表明这是可能的。
-
**支持复制：**Stock SQLite 支持会话扩展，它 允许序列化已提交事务的内容 转移并应用到第二个数据库。
Hctree 将其构建到数据库后端，并添加对 将此类事务应用于领导者-追随者中的追随者数据库 配置。在这种情况下，从领导者数据库接收的事务 可以比 它们最初应用于领导者数据库，因为 无需交易验证。
-
**删除数据库大小限制：**Stock SQLite 使用 32 位 页码。使用默认的 4KiB 页面大小，这会导致最大 数据库大小为 2^44 字节或 16TiB。
Hctree 使用 48 位页码，允许 2^60 字节数据库或 1EiB。 大约 100 万 TiB。
一个隐含的目标是hctree必须与库存SQLite一样快或更快。 对于所有单线程案例。运行数十个是没有意义的 并发编写器，如果每个都比 写入旧数据库的单个编写器。
hctree 客户端（那些使用由此编译的 SQLite 版本的客户端 repository）可以读取hctree数据库和库存SQLite数据库。
项目/原型状态
此项目包含已修改的 SQLite 项目的分支 包含 HCTREE 数据库后端的原型。它可以被建造和 使用方式与常用 SQLite 库代码相同。
该原型足够先进，可以试验和执行多线程性能测试，但是 不完整。当前的代码至少存在以下缺点：
-
未实现“开始独占” 对于 hctree 数据库。它被解析，但行为就像常规一样 “开始”确实如此。
-
所有 hctree 数据库当前都使用 32 位页码（最大值 数据库大小为 16TiB，默认为 4KiB 字节页面大小）。
-
数据库始终使用 mmap（） 进行访问。这是不可能的 回退到 pread（）/pwrite（）。
-
不能完全放入主内存的事务（例如，大型 创建索引语句）处理效率不高。
-
未实现对复制的支持。
-
原型库仅适用于 POSIX，不适用于 win32 系统。
-
hctree 数据库的所有客户端，无论是读还是读/写，都必须访问 同一操作系统进程中的数据库。
-
不支持从电源故障中恢复或操作 系统崩溃。此类事件可能会损坏数据库。
获取和构建原型
原型位于化石存储库的“hctree”分支（不是树干！）上 在 hctree: doc/hctree/index.html。要获得 最新开发快照，下载：
- https://www.sqlite.org/hctree/tarball/hctree.tar.gz?r=hctree
或者使用 fossil 检查代码：源代码的构建和部署方式可能与 stock SQLite 相同。
fossil clone https://www.sqlite.org/hctree hctree.fossil
mkdir hctree
cd hctree
fossil open ../hctree.fossil
fossil up hctree
应用程序编程
创建/打开数据库
打开现有数据库时，库会自动确定 无论它是股票SQLite数据库还是hctree数据库。由 默认情况下，创建新数据库时，库会创建一个普通数据库 SQLite 数据库。要创建新的 hctree 数据库，SQLite URI 参数 “hctree=1” 必须在首次打开新数据库时指定。例如
file://new_hctree_database.db?hctree=1
检查数据库是否真的是hctree数据库的最简单方法 是：
-
检查数据库文件的前 6 个字节。对于一个 hctree 数据库它们是“hctree”，而不是在第一个中找到的通常的“SQLite” 6 字节的库存 SQLite 数据库。
-
打开数据库并评估特定于 hctree 的杂注命令，例如 “普拉格玛hct_ncasfail”。如果它返回一个整数，则数据库是一个 hctree 数据库。如果它不返回任何行，则为旧版 SQLite 数据库。
每个数据库由两个文件 - 数据库文件本身和第二个文件 文件名“<数据库>页映射”。
并发模型
Hctree提供与SQLite类似的基于MVCC的乐观并发，具有 开始并发扩展，除了它基于 键和访问的键的逻辑范围，而不是页集。
与任何MVCC数据库系统一样，包括库存SQLite，阅读器和 编写器访问数据库的一致快照，其中已提交写入 交易打开后永远不可见。在 交易是私下累积的，并且仅对交易可见 本身，直到他们承诺。
当事务要在乐观并发系统中提交时， 必须首先对其进行验证。验证交易就是检查何时 与所有其他过去和当前的交易一起考虑， 事务可能已在序列化所有 事务在不改变最终状态结果的情况下 返回到任何客户端的数据库或查询结果。在实践中，有两个 验证 hctree 事务的方法：
-
如果此后没有其他客户端将事务提交到数据库 写入器的快照已打开，事务必须有效。
-
如果没有其他客户端修改任何 b 树（表或索引）条目 或正在提交的事务由某个范围访问的范围或 刺伤查询，则交易有效。
例如，考虑以下数据库：
CREATE TABLE t1(a INTEGER PRIMARY KEY, b TEXT, c TEXT);
CREATE INDEX i1 ON t1(b);
INSERT INTO t1 VALUES(1, 'a', 'A');
INSERT INTO t1 VALUES(2, 'b', 'B');
INSERT INTO t1 VALUES(3, 'x', 'X');
INSERT INTO t1 VALUES(4, 'c', 'C');
INSERT INTO t1 VALUES(5, 'd', 'D');
以及以下交易：
BEGIN CONCURRENT;
SELECT * FROM t1 WHERE (b BETWEEN 'a' AND 'c') AND c!='B';
INSERT INTO t1 VALUES(6, 'e');
COMMIT;
然后在事务执行期间，hctree 记录以下内容是 访问：
- 索引中“a”和“c”之间的键范围（包括 B树。
- 表 B 树的键 1、2、4 和 6。
如果在尝试提交时，hctree 客户端发现 索引 B 树范围或表 B 树之一的内容 自打开编写器的快照以来，键已被修改，验证 不成功，事务未提交。
请注意，另一个客户端修改 （2， ‘b’， ‘B’） 元组会导致 验证失败，即使 SELECT 查询排除该行也是如此。这 是因为验证基于读取的条目和条目范围 来自 B 树层，而不是数据库实际使用的子集 发动机。如果数据库架构中没有索引，则示例 SELECT 查询将使用表 B 树的全表扫描来实现。在 在这种情况下，对表 B 树的任何行的任何修改都会导致 事务验证失败。
所有数据库事务都隐式读取数据库架构。所以任何 修改数据库架构的事务只有在没有的情况下才能提交 自编写器的快照以来，其他客户端已写入数据库 已打开（上述案例 1）。
交易类型
Hctree允许客户打开三种不同的交易类型，如 遵循：
-
**开始;**使用“开始”打开的交易不收取 验证数据。这意味着，如果他们写入数据库，他们 仅当没有其他客户端写入数据库时，才可以提交 自从编写器的快照被打开以来 （上述验证案例 1）。
-
**开始并发;**使用“开始并发”打开的交易 在运行时收集验证数据。这样如果他们写信给 数据库，在提交时，它们可能会经过验证，被提交 即使自快照以来已提交其他事务 被打开了。
-
开始独家;“开始独占”命令不仅会打开 事务，但也阻止任何新的事务提交操作 从开始和旋转锁定，直到所有正在进行的提交完成。 任何新的提交操作在 BEGIN EXCLUSIVE 事务开始时启动 处于活动状态，也处于旋转锁定状态，直到完成。因此，事务开始了 使用“开始独占”始终通过验证，因为它始终 针对准备它的同一快照提交。
隐式事务的处理方式与使用 “开始”。
通常，“BEGIN”应该用于只读事务，因为它确实如此 不会产生累积验证所需的数据的开销。“开始 CONCURRENT“应该用于大多数读/写事务，”BEGIN 排他性“作为可能发生冲突的交易的后备 （也许是因为它们已经被尝试并发现冲突了几个 时间，或者可能是因为它们包含架构修改）。
在上述所有情况下，“spin-lock”实际上意味着调用SQLite xBusy 如果已注册，则回调，否则字面上旋转锁定。
扫一扫
1186
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
