F# GPU编程与KDB相比，在处理数据时，什么是最快的？

Question

嗨，我想请教任何人的经验，什么是最具成本效益和效率的方式来处理海量数据的F#图形处理器(例如使用C Nivida GPU api类型提供程序)编程与KDB的数据处理。

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

在图形处理器方面，我计划使用关系数据库或mongodb之类的NoSQL数据库，使用单个表和2-3个其他表的简单连接。

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

Answer 1

正如其他人所说的那样，在很大程度上取决于您的用例，即哪个更快。我之前帮助创建了一个包含15个查询的测试框架，并针对几个不同的股票数据数据库制定了一些算法策略：

• postgreSQL
• mysql - in memory version
• mongodb -用于查询supported
• kdb
• plus和其他一些较新的nosql和面向列的数据库

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

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

Answer 2

在我看来，在KDB中形成复杂的查询(并在之后再次理解它们)要比“像MongoDB这样的东西”容易得多。

我也是F#的粉丝。

现在，F#或KDB+都可以帮助你以兼容图形处理器的方式思考(基于数组，一次解决所有问题，减少线性，并行)。无论你做了什么选择，都要考虑让你实现目标的过程，以及你是否被锁定在一个特定的世界观中。

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

KDB+的敏捷性、简洁性和速度都令人惊叹，同样，F#在类型安全和基于研究的东西方面也很棒，比如在生命科学方面。

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

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

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