我正在研究实现一个简单的开源对象时态数据库的最佳数据结构，目前我非常喜欢使用持久性红黑树来完成它。
使用持久数据结构的主要原因首先是最小化锁的使用，因此数据库可以尽可能并行。此外，实现ACID事务更容易，甚至能够抽象数据库以在某种集群上并行工作。 这种方法的好处在于它几乎可以免费实现时态数据库。这是非常好的，特别适用于网络和数据分析（例如趋势）。
所有这些都很酷，但我对在磁盘上使用持久数据结构的整体性能有点怀疑。即使今天有一些非常快的磁盘可用，并且所有写入都可以异步完成，所以响应总是立即的，我不想在错误的前提下构建所有应用程序，只是意识到它不是真的好这样做的方法。
这是我的思路： - 由于所有写操作都是异步完成的，并且使用持久数据结构将不会使先前（当前有效）结构无效，因此写入时间实际上并不是瓶颈。 - 有一些像this这样的结构的文献正是用于磁盘的。但在我看来，这些技术将增加更多的读取开销，以实现更快的写入。但我认为恰恰相反是可取的。这些技术中的许多确实最终会使用多版本树，但它们并不是严格不可变的，这对于证明持久开销非常重要。 - 我知道在向数据库附加值时仍然需要进行某种锁定，而且我也知道如果不是要维护所有版本，应该有一个好的垃圾收集逻辑（否则文件大小肯定会大大增加） 。还可以考虑增量压缩系统。 - 在所有搜索树结构中，我真的认为红黑是最接近我需要的，因为它们提供的旋转次数最少。
但在此过程中可能存在一些陷阱： - 异步写入 - 可以影响实时需要数据的应用程序。但我不认为Web应用程序就是这种情况，大部分时间都是如此。此外，当需要实时数据时，可以设计另一种解决方案，例如需要以更实时的方式工作的特定数据的登记/结账系统。 - 它们也可能导致一些提交冲突，但我没有想到它何时会发生的好例子。如果两个线程使用相同的数据，那么正常的RDBMS中也会发生冲突，对吧？ - 拥有像这样的不可变接口的开销将呈指数级增长，一切注定要很快失败，所以这一切都是个坏主意。
有什么想法吗？
谢谢！
编辑： 似乎存在对持久性数据结构的误解： http://en.wikipedia.org/wiki/Persistent_data_structure
答案 0 :(得分：2)
如果您发现写入时间遇到瓶颈，或者没有同步写入（嗯......），您的持久性保证毫无意义，您应该执行大多数其他数据库所做的事情：实现Write-Ahead Log（WAL） ，或重做日志。
磁盘实际上非常擅长顺序写作，或者至少这是他们最擅长的。它是随机写入（例如树中的那些）非常慢。即使是闪存驱动器，在随机写入中击败了磁盘，在顺序写入方面仍然明显更好。实际上，即使大多数RAM在顺序写入时也更好，因为涉及的控制信号更少。
通过使用预写日志，您不必担心：
答案 1 :(得分：1)
我的想法是你有个好主意。现在去构建一个令人生畏的东西。从你写的所有内容来看，这听起来像是analysis paralysis的急性病例。
答案 2 :(得分：1)
我知道这个问题有点陈旧，但我已经实现了几乎相同的东西，我发现的是，作为一个二叉树意味着表现很糟糕（由于搜索次数） 。尽管存在额外的空间开销，尝试制作更广泛的持久树可能是一个更好的主意。
答案 3 :(得分：1)
有兴趣的人喜欢这样:-)我实际上已经实现了一个使用持久数据结构作为其数据模型的数据库。一种持久的B2树，我想可以称之为。仅附加存储到磁盘和垃圾收集 - 并非所有历史记录都需要永久保存。可以设置有限的保留期以允许数据库忘记早期历史。