【问题标题】:F# GPU programing vs KDB for crunching data, what is the fastest?F# GPU 编程与 KDB 处理数据,最快的是什么?
【发布时间】:2013-02-07 17:33:26
【问题描述】:

您好,我想询问任何人关于使用 F# GPU(例如使用 C Nivida GPU api 类型提供程序)编程与 KDB 处理数据处理大量数据的最具成本效益和效率的方法的经验。

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

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

有人知道这两种方法之间的任何指标或比较(​​主要是速度)吗?

【问题讨论】:

  • 你能更具体地说明你想做什么吗? “处理数据”可能意味着很多事情,没有办法知道你想做的事情是否会发挥 F#、GPU 或 KDB 的优势。
  • 基本上想连续每1分钟左右处理一批百万行(10-50),简单统计,没什么花哨的..
  • @JackP。为什么人们投票删除这个?
  • 你没有问问题。您的文本中没有问号。您要求的是“每个人的体验”,这是一项调查。
  • 成本效益:F#胜;对于效率/速度/便利性:K + KDB 获胜。如果预算允许,我认为没有理由为您的应用程序选择 F# 而不是 KDB - 我认为这是高频金融数据处理。

标签: f# gpu kdb


【解决方案1】:

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

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

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

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

【讨论】:

  • 谢谢,这一切都说得通。所以你会说在 KDB 中形成复杂的查询就像在 MongoDB 中一样容易?
【解决方案2】:

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

我也是 F# 的粉丝。

现在,无论是 F# 还是 KDB+ 都可以帮助您以与 GPU 兼容的方式思考(基于数组、一次性解决整个问题、较少线性、并行性)。无论您做出何种选择,请考虑让您实现目标的过程,以及您是否被锁定在一种特定的世界观中。

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

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

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

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

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

【讨论】:

    猜你喜欢
    • 2013-07-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2017-03-08
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多