PHP Memcached and autocomplete

For search-form autocomplete, it is also a good idea to use PHP-Memcached prior of MongoDB, and MySQL.

Why memcached? Because PHP-Memcached does *NOT* interact with SQL; it directly operates data in cache, so very suitable for quick-retrieving: autocomplete, mis-spelling, session etc.

The PHP-Memcached autocomplete processing is probably like this:

if(! empty($_GET['key'])) {
 $key = trim($_GET['key']);
 // check Memcached first.
 $result = Memcached::Find($key);
 if($result) return $result;
 // not found in Memcached, then turn to MongoDB, then MySQL.
 else {
  // do call to MongoDB, MySQL sequently and return that result
 }
}

However, I discarded PHP-Memcached in my app after some bad experience. The reason I prefer to MongoDB other than PHP-Memcached are:

• MongoDB has a better monitoring GUI tool than Memcached:
  moadmin.php is better than phpmemcachedadmin.
  Since both of them are hard to track and debug, so a good monitoring GUI tool is very important during developing and maintaining.
• MongoDB stores persistent data, the data is kept physically in disk: hash files
• PHP-Memcached data is kept in memory; that means when Memcached server stop/restart, the data will lost.
• PHP-Memcached performance is not much higher than MongoDB;
  MongoDB is smart enough to store and optimize data, their performance are similar.
• Other reasons.
  such as MongoDB+Memcached make thing complicated;
  in CentOS 5.8, Perl Memcached module is very difficult to compile and transfer.
• So for a long and higher view, MongoDB is the better choice.

Summary

For search-form autocomplete feature, a good sequence for autocomplete probably be:

1. Sphinx (for large data)
2. PHP-Memcached (newer than PHP-Memcache)
3. MongoDB (File/Hash always a good choice).
4. MySQL

Among them, (1) and (2) can be ignored, (3) and (4) are necessary.

By the way, I extract some comments regarding on PHP-Memcached vs. MongoDB from web:

I use Mongo for everything that needs to be persistent (ie needs to be on a disk for later retrieval). I use memcached for incoming request data (between a few kb and a megabyte) that can be lost and does not need to be available beyond a few minutes.

using Memcache is more about reducing query load on the server than it is about speeding up queries.

A good memcache implementation basically just tries to keep the most common data in memory so that the database server can churn away on bigger stuff.