可扩展、快速、文本文件支持的数据库引擎?

有大量的数据(几十TB),将一个副本加载到关系数据库中是负担不起的(我们必须购买两倍的存储空间)。

我会考虑采用现有数据,而不是存储原始数据,而是通过以下两种方式进行处理:

1. 以众所周知的压缩格式(如gzip或bzip2)将其压缩后存储到永久存档介质(备份服务器、磁带机等)上,以便保留.tsv格式的优势。
2. 将其处理成具有良好存储效率的数据库。如果文件具有固定且严格的格式(例如,X列为 总是 一个字符串,Y列是 一个16位的整数),那么你的状态可能很好。否则,NoSQL数据库可能更好(参见Stefan的答案)。

你应该能够减少你的存储空间,不应该需要两倍于你所说的存储空间。

什么之中的一个 these nosql dbs 可能有用。我高度怀疑任何文件是否可以配置为放在平面、分隔文件的顶部。您可以查看其中一个开源项目并编写自己的数据库层。

可伸缩性始于制表符分隔ASCII之外的一点。

只是要实际一点-不要把它学术化-公约解放你的手指和你的思想。

如果我有这个名声,我会支持杰森的推荐。我唯一要补充的是,如果您不以数据库那样的不同格式存储它,Jason建议您为每个操作支付解析成本,而不是在最初处理它时只支付一次。

在科学应用中,数据的易处理性和自己编写表达式的能力将真正发挥作用。

针对分隔文本文件的LINQ是LINQ的常见演示。您需要提供向LINQ提供表格模型的能力。Google LINQ以获取文本文件的一些示例(例如,请参见 http://www.codeproject.com/KB/linq/Linq2CSV.aspx , http://www.thereforesystems.com/tutorial-reading-a-text-file-using-linq/ 等)。

期待一个学习曲线,但它是一个很好的解决你的问题。关于这个问题最好的治疗方法之一是乔恩·斯基特的 C#深度

我以前也做过类似的工作,需要清理、重复和添加大量邮件列表。你总是受到束缚。尝试固态驱动器,特别是Intel的“E”系列,它具有非常快的写入性能,并尽可能并行地RAID它们。我们也使用了网格,但必须调整算法来进行多通道方法,以减少数据量。

注:我同意其他答案,即如果数据非常规则,则应将数据加载到数据库并编制索引。在这种情况下,您基本上是在做ETL,这是仓库社区中一个众所周知的问题。然而,如果数据是临时的,那么科学家只需将他们的结果放到一个目录中,就需要“敏捷/及时”转换,如果大多数转换都是单程选择的。。。哪里。。。加入,那你就走对路了。

VelocityDB . 它在将tab分隔的数据读入C对象和数据库时非常快速。整个Wikipedia文本是一个33gbxml文件。此文件需要18分钟才能读入并作为对象持久化(每个Wikipedia主题1个),并存储在紧凑型数据库中。许多例子显示了如何阅读标签分隔的文本文件作为下载的一部分。

在我们的中心,我们有一个 standard talk we give “所以你有40 TB的数据”,因为科学家们最近发现自己一直处于这种情况。这个话题名义上讲的是可视化,但主要是为那些对它不熟悉的人管理大量数据。我们试图了解的基本要点:

• 计划I/O
  • 二进制文件
  • 尽可能多的大文件
  • 可并行读取的文件格式,提取子区域
  • 尤其要避免在一个目录中出现大量的文件
• • 包括源代码的元数据
  • 合理的数据管理
    • 数据目录的层次结构,只有当它总是工作
  • 数据库,允许元数据的格式
• 使用可扩展、自动化的工具:
  • 可编写脚本的工具-gnuplot、python、R、ParaView/Visit。。。

我们有很多东西要买 large-scale I/O generally