数据库与平面文件答案

【问题标题】：database vs. flat files数据库与平面文件
【发布时间】：2011-01-22 08:19:08
【问题描述】：

我工作的公司正在尝试将使用平面文件格式的产品转换为数据库格式。我们正在处理相当大的数据文件（即：25GB/文件），而且它们的更新速度非常快。我们需要运行随机访问数据的查询，以及以连续的方式。我试图让他们相信使用数据库的优势，但我的一些同事似乎不愿意这样做。所以我想知道你们是否可以在这里为我提供一些原因或链接到为什么我们应该使用数据库的帖子，或者至少澄清为什么平面文件更好（如果是的话）。

【问题讨论】：

你应该提到你在这里谈论的是什么样的数据结构。如果这 25 GB 文件中的每一个都转换为 25 行，每行 1 GB，那么您最好使用平面文件。
我实际上更好奇为什么您的同事不想使用关系数据库作为您的数据存储？吉祖斯
这一切都取决于各种变量。不可能说一个比另一个更好。
@JD：工作保障可能，不知道为什么
@Josh Davis：只是一个制表符分隔的结构，包含我们业务所需的各种信息

标签： database file

【解决方案1】：

数据库可以处理查询任务，所以你不必走路手动覆盖文件。数据库可以处理非常复杂的查询。
数据库可以处理索引任务，因此，如果像获取带有 id 的记录这样的任务 = x 可以非常快
数据库可以处理多进程/多线程访问。
数据库可以处理来自网络
数据库可以监视数据诚信
数据库可以轻松更新数据（见 1））
数据库可靠
数据库可以处理事务和并发访问
数据库 + ORM 让您可以操作以对程序员非常友好的方式获取数据。

【讨论】：

【解决方案2】：

这是an answer I've already given前段时间：

这完全取决于特定领域的应用需求。一种很多时候直接文本文件/二进制文件文件访问可以非常快，高效，同时为您提供的所有文件访问功能您的操作系统的文件系统。

此外，您的编程语言很可能已经有一个内置的模块（或易于制作）用于具体解析。

如果你需要很多附加（插入？）和顺序/很少访问很少/没有并发，文件是路要走。

另一方面，当你的并发要求，非顺序读/写，原子性，原子权限，你的数据本质上是相关的，等等，你会过得更好关系或 OO 数据库。

有很多东西可以使用SQLite3 完成，其中非常轻（小于 300kb），ACID 兼容，用 C/C++ 编写，并且非常普遍（如果还没有包含在您的编程语言中 -例如Python-，肯定有一个可用的）。它甚至可能很有用在最大 140 TB 或 128 TB (Link to Database Size) 的 db 文件上，可能更多。

如果您的要求更大，甚至没有讨论，选择成熟的 RDBMS。

正如你在评论中所说的“系统”只是一堆脚本，那么你应该看看pgbash。

【讨论】：

【解决方案3】：

如果你能买到，就不要建造它。

我最近听到了这句话，它似乎真的很适合作为指导方针。问问自己这个……在您的应用程序的文件处理部分上花费了多少时间？我怀疑花费了大量时间优化此代码以提高性能。如果您一直在使用关系数据库，那么您处理应用程序的这一部分所花费的时间将大大减少。您将有更多时间用于应用的真正“业务”方面。

【讨论】：

实际上，整个应用程序只是几个怪异的 bash 脚本......整个系统是一个显示移动文件的人。伤心，我知道...
酷，但最后我检查了最好的数据库是免费的。
唉，反之亦然。更好的说法是“购买适合您需求的好的解决方案（如果存在），否则构建它”

【解决方案4】：

他们更快；除非您将整个平面文件加载到内存中，否则数据库在几乎所有情况下都可以实现更快的访问。

它们更安全；数据库更容易安全备份；他们有检查文件损坏的机制，而平面文件没有。一旦你的平面文件中的损坏迁移到你的备份，你就完成了，你甚至可能还不知道。

他们有更多的功能；数据库可以允许多个用户同时读/写。

一旦设置好，它们的使用就不会那么复杂了。

【讨论】：

【解决方案5】：

Databases 一路。

但是，如果您仍然需要存储文件，则没有能力采用新的 RDBMS（如 Oracle、SQLServer 等），而不是研究 XML。

XML 是一种结构文件格式，它使您能够将事物存储为文件，但也使您能够查询文件和其中的数据。 XML 文件比平面文件更容易阅读，并且可以通过应用 XSLT 轻松转换以提高人类可读性。如果需要，XML 也是一种很好的数据传输方式。

我强烈建议使用 DB，但如果你不能走这条路，那么 XML 就可以了。

【讨论】：

但是 Oracle 和 SQL Server 是要花钱的，既然免费更好，为什么还要花钱呢？ MySQL 一路走来。
如果他们有一个 25gb 的 CSV 文件，使用 XML 标记行和列的大小很容易翻倍（如果不是更多的话）。当从平面文件迁移到 XML 时，只是说显着膨胀是一个考虑因素。
@Scott Root：我个人倾向于不喜欢 XML，因为我认为它是一种繁重的数据传递方法。
您也可以使用 PostgreSQL，而不是 Oracle 或 SQL Server。非常强大，XML 和 csv 也可以作为输出。纯 XML 会非常慢，开销太大。
@Rook 有趣的观察 - MySQL 比 Oracle 和 SQL Server 更好。您显然从未使用过企业级软件。

【解决方案6】：

Amazon 的 SimpleDB、Tokio Cabinet 等非关系型 (NoSQL) 数据库怎么样？我听说 Google、Facebook、LinkedIn 正在使用它们来存储他们庞大的数据集。

您能否告诉我们您的数据是否是结构化的、您的架构是否是固定的、您是否需要简单的可复制性、访问时间是否很重要等？

【讨论】：

我们也在研究这个问题......首先我们需要确保我们都在同一个页面上。不过，如果您需要运行一些复杂的报告，我不确定 nosql 是如何处理的。

【解决方案7】：

没有提到什么类型的文件。如果它们是媒体文件，请继续使用平面文件。您可能只需要一个用于标记的数据库以及某种将“外部 BLOB”与数据库中的记录相关联的方法。但是，如果您需要全文搜索，那么除了迁移到完整数据库之外别无他法。

另一件事，就物理文件的数量而言，您的文件系统可能会提供上限。

【讨论】：

【解决方案8】：

SQL 即席查询能力对我来说就足够了。有了良好的表架构和索引，这将快速有效并且具有良好的性能。

【讨论】：

【解决方案9】：

除非每次启动时都将文件加载到内存中，否则请使用数据库。就这么简单。

这是假设您的大学已经有程序来处理对文件的查询。如果没有，则使用数据库。

【讨论】：

【解决方案10】：

数据库文件和平面文件的区别如下：

数据库提供更大的灵活性，而平面文件提供的灵活性较低。
数据库系统提供数据一致性，而平面文件不能提供数据一致性。
数据库比平面文件更安全。
数据库支持 DML 和 DDL，而平面文件不支持这些。
数据库中的数据冗余更少，而平面文件中的数据冗余更多。

【讨论】：