从文件或数据库服务器访问数据是否更快？

Question

如果我有一个由文件夹和文件组成的静态数据库,访问和操作会比SQL服务器类型数据库更快,考虑到这将用于CGI脚本吗？

使用文件和文件夹时,有哪些提高性能的技巧？

Answer 1

我会加入它取决于人群.

这是一个没有通用答案的问题,但在很大程度上依赖于手头的情况.我最近甚至将一些数据从SQL数据库移动到平面文件系统,因为数据库的开销加上一些数据库连接可靠性问题,使用平面文件是更好的选择.

在做出选择时我会问自己的一些问题包括:

1. 我如何消费数据？例如,我只是按照输入的顺序从开头到结尾读取？或者我会搜索符合多个条件的行？

2. 在一个程序执行期间,我多久会访问一次数据？我会去一次用Salinger作为作者获得所有书籍,还是会多次去找几位不同的作者？我会针对几个不同的标准不止一次？

3. 我将如何添加数据？我可以直接添加一行,这对我的检索是否完美,还是需要使用？

4. 代码在六个月内看起来有多合理？ 我强调这一点是因为我认为这在设计事物时经常被遗忘(不仅仅是代码,这个爱好马实际上来自我作为海军机械师诅咒机械工程师的日子).在六个月内,当我必须维护你的代码时(或者你在另一个项目之后你做了),哪种存储和检索数据的方式会更有意义.如果从平面文件转到数据库导致效率提高1%,但是当你必须更新代码时,需要花费一周的时间来解决问题,你真的改进了一些东西.

Answer 2

取决于您的信息是什么以及您的访问模式和规模.关系数据库的两个最大好处是:

1. 缓存.除非你非常聪明,否则你不能写一个像DB服务器那样好的缓存

2. 优化.

但是,对于某些专门的应用程序,与文件+文件夹数据存储相比,这两种好处都没有表现出来 - 因此答案是响亮的"依赖".

至于文件/文件夹,技巧是:

• 缓存频繁请求的文件的内容
• 拥有小目录(深度嵌套的小目录中的文件比在更平坦的结构中访问要快得多,因为读取大目录的内容需要时间).
• 还有其他更高级的优化(跨磁盘切片,放置在磁盘或不同分区中的不同位置等等) - 但如果您需要THAT级别,那么最好先使用数据库.

Answer 3

作为一般规则,数据库比文件慢.

如果您需要索引文件,那么如果您正确执行,自定义索引结构上的硬编码访问路径将始终具有更快的可能性.

但是,在基于文件的解决方案上选择数据库时,"性能"不是目标.

您应该问问自己,您的系统是否需要数据库提供的任何好处.如果是这样,那么小的性能开销是完全可以接受的.

所以:

1. 您需要处理多个用户和并发更新吗？(好吧;你确实说它是静态的.)
2. 您是否需要灵活性以便从各种角度轻松查询数据？
3. 您是否拥有多个用户,并且可以从使用现有安全模型中获益？

基本上,问题更多的是更容易开发.两者之间的性能差异不值得浪费开发时间.

Answer 4

根据我的一点经验,与本地文件系统相比,基于服务器的数据库(甚至是在本地机器上提供的数据库)往往具有非常慢的吞吐量.然而,这取决于某些事情,其中​​之一是渐近的复杂性.比较扫描大型文件列表与使用数据库和索引查找项目,数据库获胜.

我的一点经验是使用PostgreSQL.我有一张300万行的表,我只更新了8,000条记录.花了8秒钟.

至于引用"过早的优化是所有邪恶的根源.",我会采取一些盐.如果使用数据库编写应用程序,然后发现它很慢,则可能需要花费大量时间才能切换到基于文件系统的方法或其他方法(例如SQLite).我想说你最好的办法就是创建一个非常简单的工作负载原型,并用两种方法进行测试.我相信知道在这种情况下哪个更快是很重要的.

Answer 5

正如其他人指出的那样：这取决于！

如果您确实需要找出哪种性能更符合您的需求，则可能需要生成一些样本数据以每种格式存储，然后运行一些基准测试。Benchmark.pm模块是Perl随附的，它使得与以下内容进行并排比较变得相当简单：

use Benchmark qw(:all) ;

my $count = 1000;  # Some large-ish number of trials is recommended.

cmpthese($count, {
    'File System' => sub { ...your filesystem code... },
    'Database'    => sub { ...your database code... }
});

您可以键入perldoc Benchmark以获得更完整的文档。