哈哈,也借题发挥一下,那个lb垃圾一个。4KW更多的被怀疑是利益输送。 就是通过过滤表,没什么技术的。 确实现在电信的网络本身就有类似比那2个lb功能更强的过滤软件的了,只是一般不太会注意,有时你上一些站点的时候浏览器里就会有一个电信给的提示信息的
http://images.google.cn/images?hl=zh-CN&um=1&newwindow=1&q=女黑人&sa=N&start=0&ndsp=18 http://images.google.cn/images?hl=zh-CN&um=1&newwindow=1&sa=1&q=小猪&btnG=搜索图片&aq=f&oq=
hmm.... 简单研究了下,存储的压缩效率比我目前的低压缩率版本高4%,不相上下了(多出的4%,偶是含cache的,HDF还没有cache的实现加入)~ 性能方面,初步的人肉观察,跟我的实现也是不相上下的级别,但是还缺乏进一步测试~ 搜索方面,这个HDF貌似要自己手动创建index,而我是内建index的,不需要手动创建了~这会是个麻烦的问题...不确定大数据集下重建索引的时间...还需要再深入研究研究~ 功能方面,支持核函数的计算,这一点很强~ 不过我已经把K线的计算这种上层应用,作为cache的核心整合进去了,HDF缺乏这个实现,还要自己想办法重新实现,略嫌麻烦了点。但是扩展性应该会比我的更高~ 结论是...要是我早知道有这个东西,我就不自己写了,害我辛苦了7天的时间....
是的,常用的那几个指标移了些过去。 用内存表定义一系列字段,相当于数组变量,把K线加载后用一系列update .... order by kline_date即可。 很稳定。没有GUI,也不用传入传出的开销。
呵呵,联系我啊,我可以给你们一个半价, 我一个哥们在他们总部担任要职。 可以拿个一个不公开的内部价。 KDB的速度和功能目前无人可以匹敌,人就是专门为干这个设计的。自己重做 轮子也是得不偿失的。 其主要市场也不在零售,个人用户这点小钱目前他们还没有看上眼。
虽然没用过KDB,不过无人可以匹敌这话说的太满了。 不知道你知不知道智能电网里面的实时库?同时接收分布在广域(比如整个华东电网)电网的数十万到数百万个采样点,每个采样点每秒会产生50-100个采样数据,每个数据点还分多个采样值。 这么多数据会源源不断的聚集汇入,延迟有十分严格的要求。数据采样回来之后会进行一个迭代运算,规模上1000x1000的矩阵内进行许多次迭代,最慢5秒延迟内算出整个电网的潮流分布。算慢了,或者出错的话,可能会导致变电站电器过载烧毁,极端情况可能会导致爆炸。 虽然KDB不是用来干这个的,但是也可以想象下,KDB所需处理的工作量,与之相比还算不算无可以匹敌?KDB说穿了,只是一个基于内存的向量数据库而已。 至于重复造轮子的问题,对于大多数人来说是没必要的,也造不好。 但也有人习惯用自己的东西,用的顺手,想改进就改进,不会有未知的局限性。 其实我还算是比较懒得~我认识的一位算法高手更bt,他几乎不用系统自带的库,包括STL在内,所有的核心库,算法库,实现框架,都用自己实现的。