用于快速,高度并发,进程内访问大型数据集的选项

时间:2014-01-08 11:37:05

标签: .net database sqlite nosql scientific-computing

上下文:我目前正在领导一个项目,将我们的应用程序(一个与高分辨率科学数据一起工作的模型 - .NET,Winforms)与我公司所在领域的另一个提供程序集成(a类似的模型 - .NET,云架构)。我将实现协作者应用程序定义的接口 - 在运行时,这些类的实例将传递给协作者的基于云的应用程序,以提供分析细节。云应用程序将跨处理节点分发这些实例,从而协调整个分析。

我想问的具体问题是:用于提供应用程序元素的模型数据可能是一个很好的商店?

我们的数据结构复杂,结构合理,因为我们当前的数据库模式已经过相当高的标准化(数据库平台是企业级和关系型)。我们的应用程序的当前输入格式是逗号分隔的文本文件,这些文件的格式反映了数据库架构。我们实现的协作者应用程序的元素使用的数据可以保存在磁盘上他们选择的位置,并且每个处理节点都可以访问该位置。每个节点都需要访问所有数据中的一小部分(例如,平均0.001% - 0.01%)。我们有以下要求:

必须

  • 除了应用程序之外,不得有任何与数据访问相关的进程
  • 支持.NET
  • 将持有并成功使用100GB - 1TB数据。
  • 选择快速(在运行时不会插入,更新或删除)。

较佳的

  • 免费,如果是,则允许许可(例如BSD /公共领域)
  • 插入快速 - 不如选择重要,因为数据库填充将在分析之前执行
  • 支持可视化架构设计
  • 受到尊重/证实。

到目前为止,我们已考虑以下选项:

  • 开发我们自己的索引文件格式 - 我不熟悉如何执行此操作。我考虑过将数据划分为并行化轴(这样每个处理节点只能访问一个分区),仍然保持与我们当前使用的平面文件格式相同的数据(分区只是根文件夹中的子文件夹) 。我当时正考虑将数据子集读入标准.NET集合,但需要设计一种合理的方法来执行集合间查找。
  • SQLite - 我已经读过人们成功使用100GB +的数据库,这让我感到惊讶 - 显然它并不像听起来那么轻巧。到目前为止,我的基准测试工作表明,对于多达1000万条记录的表格,插入/选择性能很好,但我们在某些表格中会有数十亿条记录。
  • NoSQL - 我对NoSQL技术并不熟悉,并且已经明白它们旨在解决我们的问题(与松散结构化的数据配合使用,其中水平可伸缩性是一个问题,听起来像是与我们需要的相反)。但是,我简单地尝试了MongoDB(这里不合格,因为没有进程内模式),选择和插入性能似乎都比我使用的关系数据库好很多倍。符合条件的NoSQL数据库包括Redis和DensoDB,我计划接下来对其进行评估 - 可能还有其他数据库,我只是不确定这一查询是否真的合情合理。

如果您已经阅读了这篇文章,感谢,如果您能够评估上述任何选项的有效性,或者建议更合适的内容,那么我将非常感激。我期待着您的回复!

0 个答案:

没有答案