考虑到dokuwiki不使用数据库，使用dokuwiki有什么坏处吗？

Question

我计划使用dokuwiki作为我的网站，但我的朋友告诉我，因为dokuwiki不使用数据库，并将数据存储在纯文本文件中，这将给我的主机带来很大的压力，因为我的网站增长，我最终支付了很多钱来维持它的生存。那是真的吗？存储方法有什么效果吗？

Answer 1

我创建了一个基于SQL的平面文件数据库，其执行速度比MySQL快5倍。太棒了！然而，我确实发现了一个弱点。我的iNodes用完了。乌奥普斯！！尽管如此，它还是支持了一个拥有160万多个网页的网站，而没有气喘吁吁。把它转移到MySQL实际上减缓了网站的速度。但是请记住，我过去经常为数据库编写代码，我知道自己在做什么。

两者各有优缺点。传统的基于SQL的关系数据库在存储数据和检索数据方面效率要高得多，并且需要更少的磁盘空间和更少的I/O操作。然而，这样做是有开销的。每件事都有一个转折点。这意味着对于较小的数据，关系数据库(如MySQL )可能不是一个好的解决方案。SQLite正是出于这个原因创建的。

还有一些基于SQL的平面文件数据库非常适合更小的需求。平面文件数据结构绝对没有任何问题。我的一些网站仍然完全使用这些结构，而且它们都部分使用这些结构。大多数基于平面文件的应用程序都是高效的。一个好处是，任何事情出错，修复数据都要容易得多。

所以最终，这个决定是基于你所需要的。如果您正在查看的应用程序能够很好地满足您的需要，那么就不必担心它了。派你的朋友去找一个左撇子螺丝刀，而你部署你的网站。

Answer 2

DokuWiki常见问题解答相当广泛。请参阅https://www.dokuwiki.org/faq:database

DokuWiki被设计用来保存各种文档。那么，当您的数据库或web服务器关闭，而再次打开它的文档只能通过这个web服务器或数据库访问时，您会做什么呢？呀！因此，DokuWiki将所有这些重要信息存储为纯文本，这些纯文本始终是可读的，即使您只保留了您心爱的服务器的一些磁带备份:-)。数据库与平面文件存储--让我们消除数据库管理系统(DBMS)是wiki信息的理想存储库的假设。这并不是说DBMS是错误的选择，只是说它不是唯一的选择，以DokuWiki的方式使用文件系统对wiki来说绝不是一个糟糕的选择。在继续阅读之前，请记住wiki数据的特性：

• 经常阅读，更新较少
• 混合和非结构化文本内容

文件系统是存储数据的非常有效的地方。这是DBMS可能会将其数据放在那里的地方。对于简单的检索，文件系统应该比DBMS更简单。一个构造良好的DBMS应用程序很可能会将其常见查询的结果缓存在文件系统中，以便更快地检索！此外，所有现代文件系统都会在内存中缓存经常访问的文件。读取这些数据甚至不会再击中磁盘。DokuWiki的大部分工作都是简单的检索--获取一个文件并显示其内容，可能需要进行一些处理。这非常适合于文件系统。数据库在处理高度结构化的数据时非常出色，在这些数据的小部分经常更新的地方也是如此。维基可不是那样的。搜索一个wiki或者更恰当地说，索引一个wiki以支持快速搜索是DBMS技术可以帮助wiki的一个领域。DokuWiki通过在wiki中创建一个包含三个或更多字母的“单词”列表来实现自己的索引。部分搜索比DB搜索慢，更难处理“高级搜索”，但是对于整个单词搜索来说，它是一个可行的解决方案(即，与wiki上的其他活动相比，结果是在合理的时间内显示的)。对于公共wiki来说，谷歌提供的索引服务比任何内部搜索都要好，这一点值得商榷。DBMS可以使跨越单个服务器阈值变得更容易。最简单的是，DBMS放在一个盒子上，web服务器/应用程序组件放在另一个盒子上。DokuWiki是否可以通过使用NFS挂载来允许多个本地远程(即局域网连接的)服务器访问wiki数据目录树，这是有争议的。对于数据必须驻留在多个服务器上的大型安装，应用程序不需要解决复制/同步问题，而是可以将它们交给合适的DBMS。文件系统存储还有其他优点。由于只有一个服务(Webserver)而不是两个服务(DBMS + Webserver)必须在服务器上运行，所以安装wiki更容易，服务器要求更低，容错性更高。备份和恢复数据或将wiki移动到另一台服务器只是复制文件的问题。在文件系统中使用您的wiki数据也可以方便地使用其他工具或脚本来读取或操作它。另请参阅：

• 关于平面文件优势的PMWiki文档

Answer 3

不使用DB有一些优点，包括：

• 最初更容易实现
• 更容易迁移到新服务器

当每个请求访问您的服务器时，它要么是对DB的命中，要么是对文件I/O的命中，这是一个很小的差别，IMO。

在这两种情况下，实际的CPU使用量和存储空间是相当相似的。