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

【问题标题】：Scalable, fast, text file backed database engine?可扩展、快速、文本文件支持的数据库引擎？
【发布时间】：2011-03-22 23:09:13
【问题描述】：

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

使用纯文本是因为它的健壮性、寿命和自记录特性。以另一种格式存储数据不是一种选择，它必须保持开放且易于处理。数据很多（几十 TB），将副本加载到关系数据库中是负担不起的（我们必须购买两倍的存储空间）。

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

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

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

【问题讨论】：

我几乎不会认为 TB 的分隔数据“稳健”。
TB 的纯数据如何自我记录？
我敢打赌一个漂亮的石头加入是没有索引的谋杀。
@InsertNickHere：您不需要任何特殊软件即可查看数据。因此，如果我以前从未处理过数据，我可以打开一个文件，读取标题，查看实际数据并编写一个以某种方式处理它的脚本。如果我要以人类不可读的格式存储数据，我需要软件+文档。
Stefan Kendall：它的稳健性与纸张的稳健性相同。您的软件可能会崩溃，您的计算机可能会炸毁，但只要您有数据的打印版本，就可以使用它。如果您的狗吃了一页，那么您只丢失了那一页，其余部分的完整性不会丢失。而且您无需成为 DBA 即可阅读一篇论文 - 任何人都可以做到。

标签： database csv scientific-computing plaintext large-data

【解决方案1】：

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

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

规划您的 I/O
- 二进制文件
- 尽可能大的文件
- 可以并行读取的文件格式，提取子区域
- 避免大量文件
- 尤其要避免单个目录中的数以万计的文件
数据管理必须扩展：
- 包括出处的元数据
  - 减少重做的需要
- 合理的数据管理
  - 数据目录的层次结构只有在这将始终有效的情况下
- 允许元数据的数据库、格式
使用可扩展、可自动化的工具：
- 对于大型数据集，并行工具 - ParaView、VisIt 等
- 可编写脚本的工具 - gnuplot、python、R、ParaView/Visit...
- 脚本提供可重现性！

large-scale I/O generally 上有很多东西，因为这对科学家来说是一个越来越常见的绊脚石。

【讨论】：

【解决方案2】：

您可以使用VelocityDB 执行此操作。将制表符分隔的数据读入 C# 对象和数据库的速度非常快。整个维基百科文本是一个 33GB 的 xml 文件。该文件需要 18 分钟才能读入并作为对象持久保存（每个 Wikipedia 主题 1 个）并存储在紧凑型数据库中。许多示例显示了如何在下载过程中读取制表符分隔的文本文件。

【讨论】：

【解决方案3】：

数据量很大（数十 TB），将副本加载到关系数据库中是负担不起的（我们将不得不购买两倍的存储空间）。

您比我们任何人都更了解您的要求，但我建议您再考虑一下。如果您将 16 位整数 (0-65535) 存储在 csv 文件中，您的 .tsv 存储效率约为 33%：存储大多数 16 位整数加上分隔符 = 6 字节需要 5 个字节，而本机整数占用 2 个字节。对于浮点数据，效率更差。

我会考虑获取现有数据，而不是存储原始数据，而是通过以下两种方式对其进行处理：

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

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

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

索引将是困难的部分；您最好了解需要哪些数据子集才能高效查询。

【讨论】：

我通常有不同精度的浮点数和字符串。问题是目前正在使用许多不同的脚本、遗留软件和第三方软件访问数据。该数据库将提供额外的功能，允许用户进行大型查询，但对纯文本数据的简单访问很重要。我可能需要使用提供未压缩数据视图的 Fuse 文件系统。

【解决方案4】：

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

轻松塑造数据和编写自己的表达式的能力将在科学应用程序中大放异彩。

针对分隔文本文件的 LINQ 是 LINQ 的常见演示。您需要提供向 LINQ 提供表格模型的能力。 Google LINQ for text files for some examples (e.g., see http://www.codeproject.com/KB/linq/Linq2CSV.aspx, http://www.thereforesystems.com/tutorial-reading-a-text-file-using-linq/, etc.)。

预计会有一个学习曲线，但它是解决您问题的好方法。 Jon Skeet 的C# in depth 是该主题的最佳处理方法之一。获取 Manning 的“MEAP”版本，抢先体验他的最新版本。

我以前做过这样的工作，需要清理、删除和附加大型邮件列表。你总是受到 IO 限制。尝试使用固态硬盘，尤其是英特尔的“E”系列，它具有非常快的写入性能，并尽可能并行地对它们进行 RAID。我们也使用了网格，但必须调整算法以执行会减少数据的多通道方法。

注意，如果数据非常规则，我会同意其他强调加载到数据库和索引的答案。在这种情况下，您基本上是在做 ETL，这是仓库社区中一个众所周知的问题。但是，如果数据是临时数据，那么您的科学家只是将他们的结果放在目录中，您需要“敏捷/及时”转换，如果大多数转换是单通道选择...哪里...加入，那么你就是以正确的方式接近它。

【讨论】：

谢谢，这听起来绝对有可能。遗憾的是，这是在 Linux 上运行的，但我可能会从 LINQ 借鉴这个想法，同时提供我自己的实现。

【解决方案5】：

如果我有声望，我会支持 Jason 的推荐。我唯一的补充是，如果您不以数据库 Jason 建议的不同格式存储它，而不是在最初处理它时只支付一次解析成本。

【讨论】：

我想我可能会想出一个混合解决方案——只压缩最占用空间的文件类型，只在数据库中存储最关键的数据部分。一切都与经济有关 - 以访问和管理的便利性换取速度是值得的。

【解决方案6】：

可扩展性始于制表符分隔的 ASCII 之外的某个点。

只要实用 - 不要学术化 - 惯例可以解放你的手指和思想。

【讨论】：

我希望我能保持一个约定，但需求正在发生变化，并且数据通常来自随时间改变架构的硬件和软件。有些查询完全是临时的（例如，有人在 Excel 中附带了一个随机翻译表，并希望将其用作查询的一部分）。

【解决方案7】：

these nosql dbs 之一可能有效。我非常怀疑任何可以配置为位于平面分隔文件之上。您可能会查看其中一个开源项目并编写自己的数据库层。

【讨论】：

我想这需要一些重大的黑客攻击，但我会环顾四周。我对 Drizzle 及其微内核架构很好奇——这可能是一种方式。
我找到了luciddb.org——它似乎可以解决问题！它支持平面文件连接 - 您可以使用常见的 SQL 命令查询 .csv 文件，就像它是一个表一样。
哦，太棒了！您可能希望将其发布为答案，以防有人稍后查看。我仍然想知道“可扩展”，但我想测试它是否满足您的业务需求很容易，并且鉴于您发布了这个事实，它可能会吗？ :P