kdb是否仅由于内存中的处理而快速

我已经听过很多次人们谈论KDB在几乎没有时间的情况下处理数百万行。为什么这么快？这仅仅是因为数据都是在内存中组织的吗

---

另一件事是，有没有其他选择？任何大的数据库供应商都提供内存数据库？

< P>速度方面，内存的事情确实起到了很大的作用，但是还有其他一些东西，从硬盘上快速读取HDB，SpRead等等。我可以说，如果你想写那么多代码，你可以从C++得到很好的速度。有了kdb，你可以得到所有这些，还有更多

关于速度的另一件事也是编码的速度。学习曲线陡峭，但一旦你掌握了它，复杂的问题可以在几分钟内编码。 您可以查看onetick或谷歌内存数据库的备选方案

一个快速的谷歌搜索给出了答案：

使用面向列的方法，许多操作更高效。特别是，需要从特定列访问值序列的操作要快得多。如果一列中的所有值都具有相同的大小（根据设计，在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。另一个确认这一点的方法是看看k.h

现在让我们看看将表写入磁盘时会发生什么：

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功能的协同作用使面向列的系统能够比索引搜索（伴随分支预测失败）更快地执行线性搜索（例如，在未索引列上的where子句中），最多可执行惊人的行数

---

来源：

kdb速度很快，但非常昂贵。另外，学习Q是一件痛苦的事情。有一些替代品，如DolphinDB、Quasardb等。

SQLite，从未听过有人说SQLite很快。从未尝试过，所以不能说，但是的，也从未听过有人夸耀它的速度：）有一篇类似的文章。回答与原始问题无关