小智 16
谷歌的快速搜索提出了答案:
使用面向列的方法,许多操作更有效.特别是,需要从特定列访问一系列值的操作要快得多.如果列中的所有值都具有相同的大小(在设计中,在kdb中是真的),事情会变得更好.这种类型的访问模式是使用q和kdb的应用程序的典型.
为了使这个具体,让我们检查一列64位浮点数:
q).Q.w[] `used
108464j
q)t: ([] f: 1000000 ? 1.0)
q).Q.w[] `used
8497328j
q)
如您所见,保存一百万个8字节值所需的内存仅略高于8MB.那是因为数据按顺序存储在一个数组中.为了澄清,让我们创建另一个表:
q)u: update g: 1000000 ? 5.0 from t
q).Q.w[] `used
16885952j
q)
t和u都共享列f.如果q按行组织其数据,则内存使用量将增加8MB.确认这一点的另一种方法是看看kh
现在让我们看看当我们将表写入磁盘时会发生什么:
q)`:t/ set t
`:t/
q)\ls -l t
"total 15632"
"-rw-r--r-- 1 kdbfaq staff 8000016 May 29 19:57 f"
q)
16字节的开销.显然,所有数字都按顺序存储在磁盘上.效率是关于避免不必要的工作,在这里我们看到q确实完成了在阅读和编写专栏时需要做的事情 - 不多也不少.
好的,所以这种方法节省空间.这种数据布局如何转化为速度？
如果我们要求q对所有100万个数字求和,那么将整个列表紧密地打包在内存中是一个比面向行的组织更大的优势,因为我们在内存层次结构的每个阶段都会遇到更少的错失.避免缓存未命中和页面错误对于从机器中获取性能至关重要.
此外,对存储在一起的一长串数字进行数学运算是现代CPU指令集具有要处理的特殊功能的问题,包括预取在不久的将来需要的数组元素的指令.虽然这些功能最初是为了提高PC多媒体性能而创建的,但它们对统计数据也很有用.此外,局部性和CPU特性的相同协同作用使得面向列的系统能够比索引搜索(及其伴随的分支预测失败)更快地执行线性搜索(例如,在无索引列的子句中的子句),直到令人惊讶的行计数.
来源(S):http://www.kdbfaq.com/kdb-faq/tag/why-kdb-fast