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

Question

我正在处理存储在制表符分隔的.tsv文件中的大量科学数据。要执行的典型操作是读取几个大文件，仅过滤掉某些列/行，与其他数据源连接，添加计算值并将结果写为另一个.tsv。

纯文本用于其健壮性，长寿性和自我记录性。以另一种格式存储数据不是一种选择，它必须保持开放并易于处理。有很多数据（数十TB），将副本加载到关系数据库是不可能的（我们必须购买两倍的存储空间）。

由于我主要做的是选择和加入，我意识到我基本上需要一个基于.tsv的后备存储的数据库引擎。我不关心事务，因为我的数据都是一次写入多次读取。我需要就地处理数据，无需重大转换步骤和数据克隆。

由于需要以这种方式查询大量数据，我需要利用缓存和计算机网格有效地处理它。

有没有人知道一个系统可以提供类似数据库的功能，同时使用普通的制表符分隔文件作为后端？在我看来，这是一个非常普遍的问题，几乎所有的科学家都会以某种方式处理。

Answer 1

  

有很多数据（数十TB），将副本加载到关系数据库是不可能的（我们必须购买两倍的存储空间）。

你比我们任何人都更了解你的要求，但我建议你再考虑一下这个问题。如果你有一个存储在csv文件中的16位整数（0-65535），你的.tsv存储效率大约是33％：它需要5个字节来存储大多数16位整数加上一个分隔符= 6个字节，而本机整数拿2个字节。对于浮点数据，效率更差。

我会考虑使用现有数据，而不是存储原始数据，以下列两种方式处理它：

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

这将创建一个可审计（但可能缓慢访问）的存档，具有较低的数据丢失风险，以及一个快速可访问的数据库，无需担心丢失源数据，因为您始终可以重新读取它从档案库进入数据库。

您应该能够减少存储空间，并且不需要像您所说的那样需要两倍的存储空间。

索引将是困难的部分;您最好知道需要哪些数据子集才能有效查询。

Answer 2

these nosql dbs中的一个可能有用。我非常怀疑任何可配置的文件都可以放在平坦的分隔文件上。您可以查看其中一个开源项目并编写自己的数据库层。

Answer 3

可伸缩性从超出制表符分隔的ASCII开始。

只是务实 - 不要将其学术化 - 惯例会释放你的手指以及你的思想。

Answer 4

如果您在.NET环境中，可以使用LINQ to Objects执行此操作。流式传输/延迟执行，函数式编程模型和所有SQL运算符。连接将在流模型中工作，但是一个表被拉入，因此您必须将一个大表连接到较小的表情况。

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

针对分隔文本文件的LINQ是LINQ的常见演示。您需要提供为表格模型提供LINQ的功能。用于某些示例的Google LINQ文本文件（例如，请参阅http://www.codeproject.com/KB/linq/Linq2CSV.aspx，http://www.thereforesystems.com/tutorial-reading-a-text-file-using-linq/等）。

期待学习曲线，但它是解决问题的好方法。关于这个主题的最好的治疗方法之一是Jon Skeet的 C＃深度。拿起Manning的“MEAP”版本，以便及早访问他的最新版本。

我之前已经完成了这样的工作，需要对大型邮件列表进行清理，删除和追加。你总是被IO束缚。尝试使用固态硬盘，特别是英特尔的“E”系列，它具有非常快的写入性能，并尽可能将它们并行化。我们还使用了网格，但必须调整算法以执行可以减少数据的多遍方法。

注意我同意其他强调加载到数据库并在数据非常规则时编制索引的答案。在这种情况下，您基本上在做ETL，这是仓库社区中一个很好理解的问题。如果数据是临时的，那么你有科学家只是将他们的结果放在一个目录中，你需要“敏捷/及时”转换，如果大多数转换是单通选择......其中......加入，然后你正确地接近它。

Answer 5

如果我有声誉，我会赞成Jason的推荐。我唯一补充的是，如果你不以不同的格式存储它，就像数据库一样，Jason建议你在每次操作时支付解析费用，而不是在最初处理它时只支付一次。

Answer 6

您可以使用VelocityDB执行此操作。将标签分离的数据读入C＃对象和数据库非常快。整个维基百科文本是一个33GB的xml文件。此文件需要18分钟才能读入并作为对象保留（每个Wikipedia主题1个）并存储在紧凑数据库中。展示了许多示例，了解如何在下载的标签分隔文本文件中阅读。

Answer 7

问题已经得到解答，我同意大部分陈述。

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

• 计划您的I / O.
  • 二进制文件
  • 尽可能使用大文件
  • 可以并行读取的文件格式，提取的子区域
  • 避免数以万计的文件
  • 特别是避免单个目录中的数以万计的文件
• 数据管理必须扩展：
  • 包含来源的元数据
    • 减少重新做的需要
  • 明智的数据管理
    • 只有在始终有效的数据目录层次结构
  • 数据库，允许元数据的格式
• 使用可扩展的自动化工具：
  • 对于大型数据集，并行工具 - ParaView，VisIt等
  • 可编写脚本的工具 - gnuplot，python，R，ParaView / Visit ...
  • 脚本提供可重复性！

我们在large-scale I/O generally上有相当多的东西，因为这是科学家们日益普遍的绊脚石。