犯了一个策略上的错误

我的技术人员的身份可能还是强了些。数据存储和查询这块，开始的底线是不用盒装SQL产品，即便mysql这样的也不行。最初打算先包装一下bsd或者mongo一类的，把业务做完，这是最明智的选择。

临到了产生了一些简单的数据存储和进程间同步需求，我就觉得干脆自己实现一个跨进程索引算了。B+Tree的算法倒是小case，同步方面的顺序也有成型想法（后来翻书看起来基本没错），不过具体到实现发现细节真TM多。具体方案的设计断断续续做点考虑就用了小一周，效率低到0。

数据库的核心算法虽然也就那些，不过看起来还真有工作量，尤其是我现在彻底单打独斗了，这种时间耽搁真不知道承担得起不。不过既然已经弄了，就再多花点时间吧。关键的问题是每一个产品都有自己的抽象和封装，除了组装式的纯开发工作，粒度大小和接口设计很难有正合适的。

本来的意思是通过包装已有产品先初步解决接口问题，因为粒度问题在产生高可分离并行设计的需求前不是什么问题。得，现在底线成了不用任何成型第三方产品了。虽然初步结果估计执行效率肯定要比人家成型产品低不少，不过提高只要有时间（虽然我最缺的就是时间）也不难。

而且说实话，从根本上考量，“不要重复发明车轮”这话在现在的编程世界根本就不成立。成天在那讨论用某产品如何做这做那的技巧，还不如自己造个。这从根本的角度讲有两个原因：人家的抽象不见得适合你；其次人在某种程度上都是自私的，不是开了源就说明此人就绝对共产主义了。

设想比如mongo在推出产品的同时也提供实现用的基本素材（即以最大通用性为目的封装若干必要或辅助的算法和过程），保持足够小的粒度同时提供教程和文档，它的上层组织就不那么重要了，这对其作者来说是好事还是坏事？这还不要提找到这些基本素材的最佳形式很需要些功夫。

无论什么原因把，对于那些在基础设施上需要有一些考虑的项目，造车轮现阶段肯定是最好的选择。但是业务还没完全定型更别提在实践中考验，现在对具体细节的思考很可能走错方向。尤其是既然做这种基础设施，很多具体细节想不考虑也不行，毕竟这个第一个版本也得能跑不是。

这就远不如用别人的产品先做原型，然后通过实际效果上的反馈收集再开始自己的设计来的合理。唉既然决定了这都是废话了，看看俩星期、用脚本语言能实现个什么样的数据库吧。也不知道用不用很快翻译成C，理论上log_k(n)的算法，虽然有可能慢好几十倍，但未必是最要紧的瓶颈。

对了，可变长Key我是这么实现的：截出定长的前缀，在叶节点的Value保存一棵子树的指针，这个子树在截出的后缀上仍然重复此一过程，不知可否？可想的是，IO数增加的倍数是O(k/l)的，其中k是要查询的Key的长度，l是预设的节点内Key最大长度，觉得浪费，有没有完美的方案呢。

真讨论的话，比如可变order节点如果不对长度设限，节点的大小也不能是绝对固定的了，即便在使用特性上就设置上限（然后在这个限制下变长）从而忽略这方面的开销，也会让树变深的：这是由于order变小，分裂变多。但其它方案和我的选择之间，是不是基本是等价的恐怕还得算算。

最后顺便攻击下现有一切开发方法，没一种真正鼓励把知识片段沉淀下来。而产品总是会过时的，但包含的知识却应该是可重用的。最理想是地球上再没人需要做别人做过的工作；而且是确实没有任何理由做。