f# - 用于处理数据的 F# GPU 编程与 KDB，什么是最快的？

Question

嗨，我想询问任何人的经验，什么是使用 F# GPU（例如使用 C Nivida GPU api typeprovider）编程与 KDB 处理数据来处理大量数据的最具成本效益和效率的方法。

我知道这两种方法完全不同，但在投资一种或两种技术之前，我只想从这两种方法中工作过的人那里得到一些建议。

对于 GPU 方面的事情，我计划使用单个表和 2-3 个其他表的简单连接来使用关系数据库或 NoSQL 数据库（如 mongodb）。

有谁知道这两种方法之间的任何指标或比较（​​主要是速度）？

Answer 1

正如其他人所说，太多取决于您的用例，哪个更快。我之前帮助创建了一个针对几个不同的股票数据数据库的 15 个查询和一些算法策略的测试框架：

• PostgreSQL
• mysql - 内存版本
• mongodb - 对于它支持的查询
• 数据库
• 加上一些其他较新的 nosql 和面向列的数据库

在大多数查询中，kdb 数据库比上面提到的要快得多。一个数据库在性能方面很接近，但要让它执行我想要的计算要困难得多。

不，我不能给出确切的数字，因为这违反了一些数据库供应商的条款。但我会强调，如果你要构建一个系统，你的团队所拥有的技能应该会影响选择。加上您快速更改系统及其编程的能力。

Answer 2

老实说，在 KDB 中形成复杂的查询（然后再理解它们）比“像 MongoDB 之类的东西”要容易得多。

我也是F#的粉丝。

现在，无论是 F# 还是 KDB+ 都可以帮助您以与 GPU 兼容的方式思考（基于数组、一次性解决整个问题、线性度较低、并行性）。无论您做出何种选择，请考虑使您到达那里的过程，以及您是否被锁定在一种特定的世界观中。

就建模而言，上下文非常重要。这实际上取决于您要运行的模型类型以及吞吐量因素。

KDB+ 的敏捷性、简洁性和速度非常棒。同样，F# 非常适合类型安全，以及基于研究的东西，比如生命科学。

没有什么能阻止您同时使用两者。哦，KDB+ 的 32 位版本现在可以以商业或非商业方式免费使用。

和 John 一样，我也尝试了来自 BerkeleyDB 及更高版本的许多选项。特别是，除 KDB+ 之外的列选项在几个方面都缺乏（不仅仅是性能）。我从内核的角度来看待它，甚至在销售团队放弃时与一些从事这些内核工作的工程师进行了交谈。KDB+ 超越基准，是一种明智的前进方式，这是有根本原因的。

速度是一个或多或少取决于应用的因素。其他因素以及这些因素与产品路线图的关系可能是普遍的。