您好我想询问任何人在使用F＃GPU（例如使用C Nivida GPU api类型提供程序）编程与KDB处理数据时最经济有效的方法来处理大量数据的经验。
我知道这两种方法都是完全不同的，但只是想要在投资一种或两种技术之前从事过两种工作的人的建议。
对于我计划使用的GPU方面，使用单个表和2-3个其他表的简单连接来关闭像mongodb这样的关系数据库或NoSQL数据库。
有没有人知道两种方法之间的任何指标或比较（主要是速度）？
答案 0 :(得分：4)
正如其他人所说，过多取决于你的用例，哪个更快。我之前曾帮助创建了一个针对少数股票数据库的15个查询和一些算法策略的测试框架：
kdb数据库明显快于上面提到的数据库。一个数据库在性能方面很接近，但要让它执行我想要的计算要困难得多。
不，我不能给出硬数字，因为这违反了某些数据库供应商的条款。但我要强调的是，如果你要建立一个系统，你的团队所拥有的技能应该影响选择。此外，您还可以快速更改系统及其编程。
答案 1 :(得分：1)
在我的诚实意见中，在KDB中形成复杂的查询（之后再次理解它）比使用像MongoDB这样的东西要容易得多。＆＃34;
我也是F＃粉丝。
现在，无论是F＃还是KDB +都可以帮助您以GPU兼容的方式思考（基于数组，整体问题，线性，并行性较差）。无论你做出什么样的选择，都要考虑让你到达那里的过程，以及你是否被锁定在一个特定的世界观中。
就建模而言，上下文非常重要。这实际上取决于您想要运行的模型类型以及吞吐量因素。
KDB +的灵活性，简洁性和速度非常棒。同样地，F＃非常适合类型安全，也适用于基于研究的东西，例如生命科学。
没有什么可以阻止你们同时使用它们。哦，32位版本的KDB +现在可以以商业或非商业方式免费使用。
和John一样，我也尝试过很多BerkeleyDB的选项。特别是，KDB +以外的柱状选项缺少多种方式（不仅仅是性能）。我从内核的角度看待它，甚至在销售团队放弃时与一些研究这些内核的工程师交谈过。除了基准测试之外，KDB +是一个明智的前进方式，这是有根本原因的。
根据应用，速度是一个或多或少的重要因素。其他因素以及这些因素与产品路线图的关系可能是普遍存在的。