Database 磁盘性能上的持久（纯功能）红黑树

我正在研究实现一个简单的开源对象时态数据库的最佳数据结构，目前我非常喜欢使用持久的红黑树来实现它

我使用持久数据结构的主要原因首先是为了尽量减少锁的使用，这样数据库就可以尽可能地并行。此外，实现ACID事务甚至能够抽象数据库以在某种集群上并行工作也会更容易。 这种方法的优点在于，它几乎可以免费实现时态数据库。这是非常好的东西，特别是对于网络和数据分析（例如趋势）

所有这些都很酷，但我对在磁盘上使用持久数据结构的总体性能有点怀疑。尽管现在有一些非常快的磁盘可用，而且所有写入都可以异步完成，因此响应总是立即的，但我不想在错误的前提下构建所有应用程序，只是意识到这并不是一种很好的方法

以下是我的思路： -由于所有写操作都是异步完成的，并且使用持久数据结构将不会使以前和当前有效的结构失效，因此写时间并不是真正的瓶颈。 -有一些关于这种结构的文献正是针对磁盘使用的。但在我看来，这些技术将增加更多的读取开销，以实现更快的写入。但我认为恰恰相反的做法更可取。此外，这些技术中的许多确实最终会得到多版本的树，但它们并不是严格不变的，这对于证明持久性开销是非常重要的。 -我知道在向数据库添加值时仍然需要某种类型的锁定，而且我还知道如果不是所有版本都要维护，那么应该有一个良好的垃圾收集逻辑（否则文件大小肯定会急剧增加）。还可以考虑使用增量压缩系统。 -在所有的搜索树结构中，我真的认为红黑最接近我所需要的，因为它们提供的旋转次数最少

但在此过程中可能存在一些陷阱： -异步写入可能会影响需要实时数据的应用程序。但我认为大多数情况下，web应用程序并非如此。此外，当需要实时数据时，还可以设计其他解决方案，例如需要以更实时的方式处理的特定数据的签入/签出系统。 -此外，它们可能会导致一些提交冲突，尽管我想不出一个好的例子来说明何时会发生冲突。如果两个线程使用相同的数据，在正常的RDBMS中也会发生提交冲突，对吗？ -拥有这样一个不可变的接口的开销将呈指数级增长，所有东西都注定很快会失败，所以这一切都是一个坏主意

有什么想法吗

谢谢

编辑： 对于什么是持久数据结构似乎存在误解：

---

我的想法是你有一个好主意。现在去建造那该死的东西。从你所写的每一件事来看，听起来你好像患上了急性肺结核

如果您发现您在写入时间上遇到瓶颈，或者您的持久性保证在没有同步写入的情况下毫无意义（嗯…），那么您应该像大多数其他数据库那样：实现（WAL）或重做日志

磁盘实际上非常擅长按顺序写入，或者至少这是它们最擅长的。随机写入（如树中的写入）速度非常慢。即使是在随机写入方面击败了磁盘的闪存驱动器，在顺序写入方面也有显著的优势。实际上，即使大多数RAM在顺序写入方面也更好，因为所涉及的控制信号更少

通过使用预写日志，您不必担心：

• 撕写（在猫吃掉你的电源之前，你写了半棵树的图像）
• 信息丢失（你实际上没有坚持树，但乔认为你坚持了）
• 随机同步磁盘I/O对性能的巨大影响

---

我知道这个问题有点老了，但我一直在实现几乎相同的东西，我发现，作为一个二叉树意味着性能很差（由于搜索次数太多）。尽管有额外的空间开销，但尝试创建更宽的持久化树可能是一个更好的主意。
有人对此很感兴趣：-）我实际实现了一个数据库，它使用持久化数据结构作为其数据模型。一种持久的B2树，我想可以称之为。仅将存储附加到磁盘和垃圾收集—并非所有历史记录都需要永久保存。可以设置一个有限的保留期，以允许数据库忘记早期历史

---

请参见
您能否解释为什么“我使用持久数据结构的主要原因首先是为了尽量减少锁的使用”？？？不管是否持久，您仍然需要锁……嗯，您是对的。仍然需要使用锁，但它被最小化到绝对最小。例如，在我的例子中，我们唯一需要锁的地方是“弱”引用，比如红黑树的树头。在将所有树更改附加到文件之后，我们只需锁定它以更改指向树头的指针（仅为int）。未知读取器不可能在不一致的状态下捕获树，锁应该工作得非常快。同样对于写作来说，唯一需要锁的时候就是改变文件的大小（向文件中添加数据）我刚刚意识到，像冈崎在书中建议的那样，纯粹的功能性方法不是一个好的选择，因为不仅空间效率非常差，而且在一段时间内它使查询变得更加困难，因为一个人需要