#InceptionDB

在将空闲时间投入到 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...

InceptionDB ，一款类似于 MongoDB 的多功能 NoSQL 数据库，现在包含了一项强大的新功能：“默认值”。此功能允许用户为集合中的新文档定义默认值，从而简化数据录入并确保一致性。 InceptionDB 中的“默认值”功能通过自动使用预定义值填充字段来简化文档创建。这减少了重复数据录入的需求，并有助于维护数据完整性。用户可以为集合中的任何字段指定默认值，确保新文档遵循一致的结构。 如何使用默认值 要为集合定义默认值，用户必须在集合模式中指定所需的默认值。例如： { "name": "my_collection", "defaults": { "status": "pending", "created_at": "2023-01-01T00:00:00Z", "is_active": true } } 当向“my_collection”添加新文档而未指定这些字段时， InceptionDB 将自动使用提供的默认值填充它们。 实际用例：用户注册 在用户注册系统中，你可以为字段设置默认值，例如 status （“pending”）、 created_at （当前时间戳）和 is_active （true）。这确保了所有新用户具有一致的初始状态。 { "username": "johndoe", "email": "johndoe@example.com" } 该文档将存储为： { "username": "johndoe", "email": "johndoe@example.com", "status": "pending", "created_at": "2023-01-01T00:00:00Z", "is_active": true }...