: Is there any downside to using dokuwiki considering it does not use database? I'm planing to use dokuwiki for my website but my friend told me since dokuwiki don't use database and store the

@Lengel546

The DokuWiki FAQ answers this question quite extensively. See www.dokuwiki.org/faq:database

DokuWiki was designed to hold documentation of all kinds. So what do you do when your database or your web server is down and the documentation to bring it up again is only accessible through this web server or database? Yikes! So DokuWiki stores all this vital information as plain text which is always readable, even if you only have some tape backups left of your beloved server :-).

Database vs. Flat File Storage

Let's dispel the assumption that a Database Management System (DBMS) is the ideal repository for wiki information. That isn't to say a DBMS is the wrong choice, just to say that it's not the only choice and that using the file system in the way that DokuWiki does is in no way a bad choice for a wiki.

Before reading on, remember the characteristics of wiki data:


read often, updated less often
mixed and unstructured text content


A file system is an extremely efficient place for storing data. That's where a DBMS is likely to put its data. For simple retrieval a file system should beat the pants off a DBMS. Its quite likely a well constructed DBMS application will cache the results of its common queries in the file system for faster retrieval!

Additionally all modern file systems cache frequently accessed files in memory. Reading this data will not even hit the disks anymore.

Much of a DokuWiki's work is simple retrieval - get a file and show its contents possibly with some processing. This is very well suited to a file system. Databases excel when dealing with highly structured data and also where small pieces of that data are updated frequently. Wikis aren't like that.

Searching a wiki or more properly, indexing a wiki to enable quick searching is an area where DBMS technology can assist a wiki. DokuWiki implements its own indexing by creating a list of every "word" of three or more letters in the wiki. Partial searching is slower than it would be with a DB and it is more difficult to handle "advanced searches", however for whole word searching it is a viable solution (i.e. the results are presented in a reasonable time when compared to other activities on the wiki). For a public wiki it's arguable that Google provides a better indexing service than any internal search could.

A DBMS can make it easier to cross the single server threshold. At its simplest, the DBMS is placed on one box and the web server / application component on another. It's arguable that DokuWiki could accomplish something similar by using NFS mounts to allow multiple locally remote (i.e. LAN connected) servers to access the wiki data directory tree.

For very large installations where the data will have to reside on multiple servers, instead of solving replication/synchronization issues the application can hand them off to a suitable DBMS.

Filesystem storage has other advantages as well. Because there is only one service (Webserver) instead of two (DBMS + Webserver) that has to be run on the server, installing the wiki is easier, the server requirements are lower and the fault tolerance is higher.

Backing up and restoring your data or moving the wiki to a different server is just a matter of copying files. Having your wiki data available in the file system makes it also easier to read or manipulate it with other tools or scripts.

See also:


PMWiki documentation on flat file advantages

Vote Up Vote Down

@Jamie184

I created a SQL based flat file database that performed 5x (times) faster than MySQL. Amazing!! However, I did find a weak spot. I ran out of iNodes. Ooopppsss!! Still, it supported a website with over 1.6 million web pages without huffing and puffing. Moving it to MySQL actually slowed the site down. But keep in mind that I used to write code for databases routinely and I know what I am doing.

There are pluses and minuses to each. Traditional SQL based relational databases are far more efficient in storing data and retrieving data and require less disk space and far less I/O to operate. However, there is overhead in doing so. There is a tipping point for everything. This means that for smaller data, a relational database such as MySQL may not be a good answer. SQLite was created for just this reason.

And there are still flat file SQL based databases that are perfect for smaller needs. There is absolutely nothing wrong with a flat file data structure. Some of my websites still use these structures entirely and all of them use these structures in part. Most applications based upon flat files are efficient. One benefit is that anything goes wrong, it is much easier to fix the data.

So in the end, the decision is really based upon what you need. If the application you are looking at does what you want well, then don't worry about it. Send your friend off to find a left-handed screwdriver while you deploy your site.

Vote Up Vote Down

@Nickens628

There are some advantages to not using a DB including:


easier to implement initially
easier to migrate to new servers


When each request hits your server it will then either be a hit to the DB or a hit to file I/O. That is rather a small difference, IMO.

In both cases, the actual CPU usage and storage space consumed is rather comparable.

Vote Up Vote Down