最新

我为.NET构建了一个小型的、优化缓存的B+树存储引擎，名为BTreePlus。<p>这个项目的目标并不是构建一个通用数据库，而是探索在针对CPU缓存行为、小固定大小页面和可预测的读/写路径进行调优时，现代B+树设计能够达到的极限。<p>在我的基准测试中（链接在代码库中），BTreePlus在特定的键值风格工作负载下显示出比SQLite和Postgres更好的吞吐量，主要包括：<p>- 单键点查找<p>- 小页面的顺序插入<p>- 以读取为主的场景，没有复杂的SQL层<p>我非常希望能得到数据库和系统工程师的反馈，具体包括：<p>- 页面布局/分裂合并逻辑<p>- 锁定模型<p>- 设计是否避免了经典B树的陷阱<p>- 基准测试方法（乐意进行调整或重新测试）<p>NuGet: <a href="https://www.nuget.org/packages/BTreePlus" rel="nofollow">https://www.nuget.org/packages/BTreePlus</a>

我们是一家小型初创公司，正在构建一个专门的搜索引擎。刚开始时，逻辑很简单：“性能是我们的主要特点，所以我们需要使用C++。” 六个月过去了，运行时性能确实很出色，但我们的迭代速度却急剧下降。 感觉我们在每一个功能上都付出了巨大的代价。就在昨天，我花了整个下午与CMake斗争，只是为了链接一个库，而在其他生态系统中，这本可以通过一行命令（go get或npm install）轻松完成。我们还不断遇到一些虚幻的bug，结果发现是我们M1 Mac与Linux CI运行器之间的ABI微妙不匹配——这些问题在现代工具链中根本不存在。 这让人感到沮丧，因为我们的“慢”竞争对手每周都在推出新功能，而我们却被困在调试链接器错误或等待20分钟的清理构建中。 我开始怀疑“性能护城河”是否是一种陷阱。对于那些最近开始基础设施项目的人：你们还在坚持使用C++吗？还是转向了Rust或Go？或者你们只是接受了为了原始速度而牺牲迭代速度的现实？

1. 让他们继续交谈 2. 持续学习 3. 让他们付出代价

嗨，HN，我是Stefano，我刚刚推出了h00k.dev，这是一个专注于清晰性、隐私和实用开发工具的Webhook检查器。 它可以让你捕获和探索传入的Webhook，预览请求体（如JSON、图片、音频、视频等），检查请求头，解码JWT，并保存快照以便调试或分享。你还可以将请求转发到本地环境，并创建AI生成的模拟响应。 这个工具的开发源于我在调试分布式系统时，常常需要的不仅仅是一个基本的请求查看器。 期待听到你的想法！