#benchmarks

在将空闲时间投入到 flowtest.io （我希望这将是一项能够彻底改变API测试方式的服务）两个月后，我又重新拾起了 InceptionDB 。 尽管时间已经过去，但我仍清楚地记得当时正在优化性能，心理目标是突破每秒百万次插入（在单个节点上）。百万次并不难超越，但借助AI，我执意要轻松超过百万。实际上，我执意要将其推向更疯狂且不必要的程度，探索各种方案并攻击Inception的不同抽象层。 我重新执行了最后的测试，结果惊人得好像出了什么问题。我选中第一个基准测试： INSERT ，运行它，几乎同时结束。肯定有问题！日志显示在200毫秒内插入了100万条，但我不相信，我以为我关掉了持久化，只工作在内存中，或者没有并发控制导致数据重叠，或者数据发送了但服务器将其丢弃到了/dev/null。 sent: 1000000 took: 182.928406ms Throughput: 5466619.55 rows/sec Closing 'col-1779494946505865611'... http: Server closed 我不信任它，我可以想到一千个理由，但在删除数据库之前设置了一个断点并重新执行。尽管在调试中，结果几乎相同，但现在我有了： /tmp/inceptiondb_bench_811457574/col-1779494946505865611 ，它并非空文件，但只占41MiB。没多想，我将其移动到本地Inception的数据目录，启动它，加载页面，那里就有100万条数据。而且数据似乎也是正确的。 拥有100万文档的基准测试集合 我仍然不相信，创建一个索引，按升序查询，找到了第一个文档 0 。改变顺序，最后一个文档 999999 也在。似乎一切正常。我移开视线，确认自己还在呼吸。 我想到写一篇博客文章，但在此之前重新测试。这次是1000万条。 sent: 10000000 took: 1.078983549s Throughput: 9267981.90 rows/sec Closing 'col-1779498339775263815'... http: Server closed 接近每秒1000万条，估计为410 MiB。显然离磁盘瓶颈还很远，实际测试中磁盘可达9.4 GiB/s，这连5%都不到。 基准测试包含多个测试，用于衡量特定场景的性能： INSERT 、 PATCH 、 REMOVE ，但还有一些我记不清了： INSERTPK 、 INSERTBTREE 、 RETRIEVEBTREE...