国内用kdb+的公司多吗

Discussion in 'kdb+' started by vanilla, Jun 10, 2009.

  1. 实时系统里面用的差别应该很大吧。
    实时系统里面为了保证性能,应该功能尽量会简单。就像lvsoft提到的那种情况,估计主要就是做采集用的。
     
  2. 智能电网里面的数据库实现就叫实时库。简单的说就是实时数据库。
    实时数据库包含两方面的特点:
    1、任何处理都有时间要求,也就是必须某个时间内响应,比如xx毫秒
    2、所有数据记录都带有时间属性。

    实时库通常要求,最差达到每秒响应100W次读写。其实可以算算,按照CPU 3G主频来算,达到100W次读写每秒,也就是平均每次操作要在3000个时钟周期内完成。

    3000个时钟周期是啥概念,这篇文章有个比较形象的阐述:
    http://duartes.org/gustavo/blog/post/what-your-computer-does-while-you-wait

    我简单的总结下吧。假设一个时钟周期比作一秒,那么CPU平均而言(在流水线发挥作用的情况下,大部分情况是达不到的),每秒都能做一次加法计算,这个速度跟人差不多吧。
    访问一次L1 cache需要3秒的时间,相当于拿起一张草稿纸。
    访问一次L2 cache,需要14秒,相当于走过去拿本书。
    访问一次内存,需要4分钟,相当于下楼去买零食了。
    而访问一次磁盘,需要一年零三个月。

    按照以上的比较,相当于要在50分钟不到的时间内完成一次数据操作。这个时间看似很长,其实由于访问一次内存需要4分钟,因此总共也只能进行12次内存读写的操作。
    所以也不能做的很复杂。

    当然啦,这只是从一方面去阐述复杂性,另一方面,也可以说实时库的实现是极端复杂的。
    比如,内存的访问并不是匀速的,有许多边界条件可以加速访问速度,如何安排数据去适应这些边界条件,会有许多技巧。再比如如何尽可能加大cache命中率,尽量减少内存访问的需要。再比如如何安排指令序列,利用流水线让执行效率充分发挥等等等等。
    另外算法上也有许多挑战,比如随着数据的增大,动态的无缝扩充hash表容量等等。还有可靠性方面的要求,比如在如此时间要求上还要做到多节点冗余,任何节点down掉其他节点能接替它的工作。还有因为冗余导致的数据一致性维护等等~

    而且这些问题整合在一起,一个两个还好说,都有对应的办法。但当所有问题纠缠在一起,复杂度会指数上升。

    所以,不要认为开个内存大数组,问题就能解决了~实时库远不是这么简单的东西。
     
  3. 要是能拿过来对比下就好了。kdb据说是现在公开的,最快的。但是应该还有更稳定更快的。
     
  4. 直接拿来对比很难~智能电网是更小众的系统。比如我知道南瑞的Open3000,软件对外报价是2000W,当然,不是美刀~要运行在IBM的PowerPC架构的服务器上,OS是AIX。
    不过在我看来他们那套系统也已经落后了~

    另外就是实时库跟金融数据库侧重点不同。实时库侧重于大量数据的随机写入和高频率更新读写。金融数据库侧重于大量数据的顺序写入,并且读取部分侧重于附加核运算。后者这一点在实时库中不存在,或者说由另一个叫公式计算的模块完成,并不是直接跟跟实时库实现捆绑在一起的。