Mimesis

Mimesis Container

What is Mimesis?

Mimesis is an Open Source PHP Key-Value Store (in a flat file format) designed to act as a backend for server-side scripts that require information storage and retrieval capabilities.

Instead of parsing SQL statements, Mimesis uses PHP's object-oriented constructs to provide a distinct class with various "database" manipulation methods. Using the NoSQL approach, data is given and produced as key-value pairs, or associative arrays.

Mimesis guarantees that information transactions are processed reliably by adhering to the following database theory principles:

What are the Existing Problems?

To understand the virtues of Mimesis it is necessary to delve into the various limitations that can be encountered by a server-side script.

  1. Free webhosts do not necessarily provide database accessibility.
  2. A database on a server may not be accessible at given times despite ready access to the script itself.
  3. There are some free webhosts that assign arbitrary file permissions (typically rwxrwxrwx or 777) to files uploaded to their servers regardless of those set by a script or an FTP program.
  4. Ensuring the atomic nature of locks across many systems is often overlooked on certain PHP database scripts.
  5. A large portion of databases scripted in PHP tend to read the entire database into memory and make manipulations to it there, then rewrite the entire database.
  6. All database data is typically stored in only one file.
  7. Many databases are known to typecast and size delimit database fields.
  8. Databases and their Management Systems tend to be monolithic.
  9. Cryptic methods of data storage.

1. No Database

The internet is a wonderful place for the free of exchange of ideas. However, with the word free there are typically limitations on just how much one gets. The need for Mimesis arises from the fact that there are many people who are still putting quality sites out on the net but doing so on free servers. Many will encounter that in order to get certain perks (such as no ads) they will often be denied access to a traditional database. Most free servers today do offer PHP support, and thereby Mimesis provides the way to get around the no database limitation.

2. Database Accessibility

How many times haven't we encountered a 'Service Temporarily Unavailable' page or 'unable to fetch query something something...'. Some of these cryptic messages occur because access to the database is denied at that particular instance in time. Mimesis runs alongside your scripts. So long as the script is accessible, so is your database.

3. File Permissions

When a file's permission flags are all set (i.e. rwxrwxrwx) it means anyone (including anyone visiting your site) can view the content of those files. Some scripts rely on setting a file's permission in order to keep its content hidden from the general public. For instance, something like a creative style sheet that you don't want others to have access to. Mimesis overcomes this by utilizing one of the much ignored features of PHP: comments. All good source code should contain comments, and the useful thing about comments in this case is that they are never displayed to the browser. Mimesis files terminate with the extension '.php' and their actual content starts with <?php /* and ends with */?>. This forces all content in-between to be non-viewable, even if the file can be accessed via the browser.

4. File Locking

Excerpt taken from the PHP function reference for flock:

"flock() will not work on NFS and many other networked file systems. Check your operating system documentation for more details.

On some operating systems flock() is implemented at the process level. When using a multithreaded server API like ISAPI you may not be able to rely on flock() to protect files against other PHP scripts running in parallel threads of the same server instance!

flock() is not supported on antiquated filesystems like FAT and its derivates and will therefore always return FALSE under this environments (this is especially true for Windows 98 users)."

There are also a great many other warnings present with the usage of flock in its function reference. What does this mean for scripts using flock as their primary file locking mechanism? That they cannot ensure reliability of locks across all systems.

According to this article utilizing the 'x' flag when executing an fopen does not ensure that the file will be created uniquely on NFS systems.

Mimesis overcomes these technicalities by instead creating locks using temporary directories to act as the mutex mechanism (directory creation is a consistent practice despite the file system in use).

5. Full Query and Overwrite

Researching other PHP DB's there is a trend that occurs fairly frequently within the code. In order to perform database manipulations, such as adding a new row of data, the entire database is loaded into memory. The reason for this is to increase speed. However, full database queries are often unnecessary and they increase the amount of time the script has to execute while reading the file. In the case where a very large database is present, the script itself may run out of available memory. The sister process to the full read is the full write, wherein the entire database is being rewritten into the file, in the case of a server malfunction you may end up with data loss or a completely unusable database.

The other method they use to overcome unstable data is to write the new database with all of its changes into another file and then rename that file to overwrite the older database. Its an effective technique for overcoming server crashes that might corrupt the database. If you have limited space and a large database, this method becomes ineffective as you may not have the available storage to create another copy of the database.

Mimesis on the other hand uses a heap method of file storage. It writes only what it needs to and appends it to the end of the file, thereby maintaining a history of changes to the database (it also provides a method for refreshing so the database doesn't become bloated with historical information).

6. Lone File Methodology

A typical database stores all of its information in one file. Which means that an update to the records in the database comes in one of three varieties:

While these are all effective techniques, they possibly affect a lot of data at one time. Mimesis solves this by appending new row data to the end of its files. This way when Mimesis needs to update a particular record it only affects that record's file; assuming the script experienced some sort of catastrophic failure, only that file would be affected and the all previous data in the file would remain unchanged.

Furthermore, if the file that contains the associative keys becomes damaged, it is still possible to entirely reconstruct the value pairs from the data file.

7. Typecasting and Size Delimiting

Databases need a great deal of forethought. This forethought is necessary in order to be certain of what needs have to be met by the database, and what exactly is going to be required where. PHP though has a loose typing code form, which means when you need something, you just create it on the fly. Mimesis emulates this in how it stores data, by using PHP's serialize and unserialize functions. This way, there is no need to regiment the type of data stored. Furthermore, Mimesis supports all data types of PHP including binary data.

8. Monoliths

Database implementations tend to have a monolithic approach (one man's opinion). Their query language, errors they return, and the whole management system itself is one hulking beast. Mimesis is the harmonious (or attempted harmony) of what are essentially much smaller functions. Every function that Mimesis uses, can actually be used of its own accord independent of the Mimesis class. If you look at the source code this will be easily noticeable. This coding methodology makes it easier to optimize Mimesis and to expand on it, not to mention much easier when seeking out errors.

9. Data Storage

Have you ever taken the time to actually open a database file with a simple text application? It's a very complicated set of binary data, which to the human eye looks like a lot of indiscernible characters (though on occassion you may actually recognize some of your data). I didn't like this "proprietary" approach to data storage. Rather I've coded Mimesis with a less cryptic (still a little cryptic) method of data storage. Such that if you should ever decide to switch to another database to store your data you can actually take a look at it, read it, understand it, and with some time and effort, write a script to translate it. This allows your data to always be transferrable even if you no longer have access to Mimesis or don't know that Mimesis was used to create said data.

How does Mimesis Disappoint?

Let's be frank. No system is perfect and everyone has their preferences. Mimesis has not been load tested. Therefore, I can make no claims as to how it would handle an EXTREMELY large data set (I have confidence that it would perform well).

Errors can occur in many places due to the large amounts of functions that are interacting with one another, and particularly since a great many of these functions involve reading/writing of files.

Mimesis is the product of my own effort and my own studies. Therefore, while it has all the best I can offer, it also has all the limits I have as a programmer. What I know also highlights that which I do not know.

What can I use Mimesis for?

I suppose if you arrived at this page you already know that you're going to require a database for something. Apart from the examples given in the Tutorials page, the possibilties are endless:

Just keep in mind that you use Mimesis at your own risk, and as per the license included in the source code:

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT OWNER/HOLDER "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR, COPYRIGHT OWNER/HOLDER, OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.