重新审视InceptionDB及其优化

在将空闲时间投入到 flowtest.io（我希望这将是一项能够彻底改变API测试方式的服务）两个月后，我又重新拾起了 InceptionDB。

尽管时间已经过去，但我仍清楚地记得当时正在优化性能，心理目标是突破每秒百万次插入（在单个节点上）。百万次并不难超越，但借助AI，我执意要轻松超过百万。实际上，我执意要将其推向更疯狂且不必要的程度，探索各种方案并攻击Inception的不同抽象层。

我重新执行了最后的测试，结果惊人得好像出了什么问题。我选中第一个基准测试：INSERT，运行它，几乎同时结束。肯定有问题！日志显示在200毫秒内插入了100万条，但我不相信，我以为我关掉了持久化，只工作在内存中，或者没有并发控制导致数据重叠，或者数据发送了但服务器将其丢弃到了/dev/null。

我不信任它，我可以想到一千个理由，但在删除数据库之前设置了一个断点并重新执行。尽管在调试中，结果几乎相同，但现在我有了：/tmp/inceptiondb_bench_811457574/col-1779494946505865611，它并非空文件，但只占41MiB。没多想，我将其移动到本地Inception的数据目录，启动它，加载页面，那里就有100万条数据。而且数据似乎也是正确的。

我仍然不相信，创建一个索引，按升序查询，找到了第一个文档 0。改变顺序，最后一个文档 999999 也在。似乎一切正常。我移开视线，确认自己还在呼吸。

我想到写一篇博客文章，但在此之前重新测试。这次是1000万条。

接近每秒1000万条，估计为410 MiB。显然离磁盘瓶颈还很远，实际测试中磁盘可达9.4 GiB/s，这连5%都不到。

基准测试包含多个测试，用于衡量特定场景的性能：INSERT、PATCH、REMOVE，但还有一些我记不清了：INSERTPK、INSERTBTREE、RETRIEVEBTREE、RETRIEVEFS。

我将运行所有测试，并记录每个测试的性能。

总的来说，所有操作都超过了每秒百万次。顺便提一下，让我提醒你 Throughput Open 是相同的操作，但在数据库启动时执行。这一点很重要，因为Inception完全依赖日志来持久化数据，因此要恢复状态，必须重新读取整个日志才能再次就绪。