mysql不同编码方式的数据库之间进行转储和导入会不会出现错误,通过方式将数据库版本推向其极限...

与其他形成鲜明对比

写时复制(COW)方法，但是，我们不能简单地复制整个记录页，这浪费了存储空间。根据所使用的版本控制算法，我们仅从页面复制许多记录(每次更改的记录本身)。

对于大多数数据库系统，我们存储固定数量的记录，即每个数据库页面的实际数据(当前最多512条记录)。记录本身具有可变大小。超出预定义长度(以字节为单位)的超长记录存储在其他溢出页面中，并且仅在记录页面中引用。

我们实施了许多备份系统中最著名的版本控制策略，用于记录页的写时复制操作。即，我们要么复制:

完整记录页面，即页面中的任何记录(完整)

仅记录页面中与旧版本有关的更改记录(增量)

仅保留自整页转储(差异)以来记录页中更改的记录

众所周知，每种版本控制策略都有其优点和缺点。简单地存储整个页面(完整)对于阅读操作非常有效。但是，与所有其他方法相比，写入性能最差，因为除了复制所有更改的记录之外，我们还简单地复制所有未更改的记录。

增量版本是另一个极端，写性能最好，因为它存储了最佳版本(仅更改了记录)，但是另一方面，重建页面需要间歇性的页面完整快照，以使页面的每个新修订版的性能都不会随着每个新版本的增量增加而降低。

差异版本会尝试更好地平衡读写，但仍不是最佳选择。每次修改页面中的记录时，都会写入一个新页面，其中包含自页面过去的完全转储以来所有更改的记录。这意味着仅需读取页面片段的每两个修订版本即可重建记录页面。但是，页面的每个新修订版的写性能也会下降。

关于写入性能的

增量版本控制，由于需要间歇的页面完全转储，因此会导致写入峰值。 差异版本转换也存在类似的问题。如果没有间歇性的完整转储，则每次新写入都必须复制很多数据。

马克·克拉米斯(Marc Kramis)提出了一种新颖的滑动快照算法，该算法平衡了读/写性能以规避任何写峰值。

该算法利用了滑动窗口。首先，必须存储任何更改的记录。其次，任何早于窗口预定义长度N且在这些N修订期间未更改的记录。最多只需要读取这些N版本。页面片段的获取可以并行完成，或者只要从最新版本开始就重建了整个页面，我们就停止了。

一旦我们确定存储系统可以线性扩展以获取旧修订以及最新修订，而对数则用于获取和存储单个记录以及整个修订，因此我们将重点放在了注意上层。

然后，我们投入了大量工作来实现持久的DOM接口(例如，本地存储XML文档和将来的JSON文档)。

我们的记录存储有稳定的标识符，该标识符永远不会改变，无论记录是否被更新以及它们在物理上的位置。插入标记以删除记录。为了存储当前XML/XDM节点的一种DOM表示，编码只是简单的第一个孩子，左兄弟姐妹，右兄弟姐妹，父ID和节点ID。

然后，我们再次将重点转移到实现版本化的用户定义的索引结构上。

在每次事务提交期间，不仅会生成存储数据的快照，还会生成索引的快照。当前，这些索引基于存储在我们内部ZFS相同树结构的不同子树中的记录页面中的AVL树/AVL节点。

资源中所有路径的路径摘要始终保持最新。

为了使用户能够充分利用我们的时态数据库系统并真正轻松地回答上述问题，我们可能会通过时态数据库系统来回答我们扩展的查询-编译器称为Brackit。

用户现在可以打开特定的修订版，在类似于DOM的树结构中导航以选择特定修订版中的节点，然后及时浏览。通过新颖的基于时间的轴，例如，可以轻松地分析选定的或一系列记录/节点/在下一个修订版，上一个修订版，第一个或最后一个修订版，过去或将来的修订版中的样子，全部修订

此外，我们还可以根据给定的时间戳或修订ID来查询一系列修订。

但是，如果我们想导入先前存在的文档的多个修订版本，或者与我们选择的版本控制算法无关地比较存储在系统中的任何修订版本，该怎么办？

我们首先实现了称为fast-matching-simple-edit脚本(FMSE)的差异算法，以支持导入不同版本的文档和在我们的存储系统中进行几次修订。该算法不依赖于节点标识符。通过首先在要导入的树状文档的叶节点上计算最长公共子序列(LCF)，它基于子树的相似性进行匹配。然后，它尝试匹配自下而上的方式。在下一步中，将使用编辑操作将文档从一个版本转换为另一个版本。该算法显然以树到树校正问题的形式使用启发式算法，因此也采用NP-hard。如果叶节点非常独特，则效果最佳，并且生成的编辑脚本最少。

基于ID的算法，可以选择使用存储的哈希值

为了计算Sirix资源的任何修订版与记录页级别的版本控制之间的差异，我们开发了一种算法，该算法利用了稳定的记录标识符(这是基于序列生成器的，并且从不重新分配ID(例如，从已删除的记录中分配)如果我们在插入过程中存储节点的哈希，则diff算法能够跳过整个子树(如果节点标识符和哈希值相同)匹配。

描述基于ID的差异算法的工作原理

我们最近在XQuery和DOM-API层之上构建了一个更高级别的API，可与基于Vert.x，Kotlin/Coroutines和Keycloak的Sirix服务器进行通信以进行身份验证。其实现和用法示例已经是另一篇文章的主题。

如一些屏幕截图所示，我们曾经开发了一种Visual Analytics方法来比较存储在Sirix中的树结构。但是，它有些陈旧，需要移植到网络上。

接下来，我们将研究如何最好地存储JSON文档，这简单地归结为我们希望记录的细粒度问题(例如对象记录节点，数组索引节点)。

但是，我们非常乐于讨论未来的方向和想法。任何帮助将不胜感激。