数据库与平面文件

Question

我工作的公司正在尝试将使用平面文件格式的产品切换为数据库格式.我们正在处理相当大的数据文件(即:25GB /文件),并且它们可以非常快速地更新.我们需要运行随机访问数据的查询,以及连续的方式.我试图说服他们使用数据库的优势,但我的一些同事似乎不愿意这样做.所以我想知道你们是否可以通过一些理由或链接到我们应该使用数据库的帖子来帮助我,或者至少澄清为什么平面文件更好(如果它们).

Answer 1

1. 数据库可以处理查询任务,因此您不必手动遍历文件.数据库可以处理非常复杂的查询.
2. 数据库可以处理索引任务,因此如果使用id = x获取记录的任务非常快
3. 数据库可以处理多进程/多线程访问.
4. 数据库可以处理来自网络的访问
5. 数据库可以监视数据完整性
6. 数据库可以轻松更新数据(参见1))
7. 数据库是可靠的
8. 数据库可以处理事务和并发访问
9. 数据库+ ORM允许您以程序员友好的方式操作数据.

Answer 2

这是我前段时间已经给出的答案:

它完全取决于特定于域的应用程序需求.很多时候,直接文本文件/二进制文件访问可以非常快速,高效,并且为您提供操作系统文件系统的所有文件访问功能.

此外,您的编程语言很可能已经有一个内置模块(或很容易制作)用于特定的解析.

如果您需要的是许多附加(INSERTS？)和顺序/少数访问很少/没有并发,文件是要走的路.

另一方面,当您对并发,非顺序读/写,原子性,原子权限,数据的性质等要求时,您最好使用关系数据库或OO数据库.

使用SQLite3可以实现很多功能,它非常轻便(300kb以下),符合ACID标准,用C/C++编写,并且非常普遍(如果它还没有包含在您的编程语言中 - 例如Python-,肯定有一个可用).即使对于140 TB或128 tebibytes(链接到数据库大小)的db文件,它也可能更有用.

如果你的要求更大,甚至没有讨论,那就去找一个完整的RDBMS.

正如你在评论中所说的那样,"系统"只是一堆脚本,那么你应该看看pgbash.

Answer 3

如果你能买它,不要建造它.

我最近听到了这句话,它似乎很适合作为指导.问自己这个...花了多少时间处理你的应用程序的文件处理部分？我怀疑在优化此代码以获得性能方面花费了相当多的时间.如果您一直在使用关系数据库,那么处理这部分应用程序的时间会少得多.您可以有更多时间来应用您应用的真正"业务"方面.

Answer 4

他们更快; 除非您将整个平面文件加载到内存中,否则数据库几乎在所有情况下都允许更快的访问.

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

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

一旦设置完成,它们就不那么复杂了.