犯了一个策略上的错误

我的技术人员的身份可能还是强了些。数据存储和查询这块,开始的底线是不用盒装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变小,分裂变多。但其它方案和我的选择之间,是不是基本是等价的恐怕还得算算。

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

posted on 2011-06-08 04:46  怪怪  阅读(618)  评论(4编辑  收藏  举报

导航