When to use Redis instead of MySQL for PHP applications?

I've been looking at Redis. It looks very interesting. But from a practical perspective, in what cases would it be better to use Redis over MySQL?

Ignoring the whole NoSQL vs SQL debate, I think the best approach is to combine them. In other words, use MySQL for for some parts of the system (complex lookups, transactions) and redis for others (performance, counters etc).

In my experience, performance issues related to scalability (lots of users...) eventually forces you to add some kind of cache to remove load from the MySQL server and redis/memcached is very good at that.

I am no Redis expert, but from what I've gathered, both are pretty different. Redis :

• Is not a relational database (no fancy data organisation)
• Stores everything in memory (faster, less space, probably less safe in case of a crash)
• Is less widely deployed on various webhosts (if you're not hosting yourself)

I think you might want to use Redis for when you have a small-ish quantity of data that doesn't need the relational structure that MySQL offers, and requires fast access. This could for example be session data in a dynamic web interface that needs to be accessed often and fast.

Redis could also be used as a cache for some MySQL data which is going to be accessed very often (ie: load it when a user logs in).

I think you're asking the question the wrong way around, you should ask yourself which one is more suited to an application, rather than which application is suited to a system ;)

MySQL is a relational data store. If configured (e.g. using innodb tables), MySQL is a reliable data-store offering ACID transactions.

Redis is a NoSQL database. It is faster (if used correctly) because it trades speed with reliability (it is rare to run with fsync as this dramatically hurts performance) and transactions (which can be approximated - slowly - with SETNX).

Redis has some very neat features such as sets, lists and sorted lists.

These slides on Redis list statistics gathering and session management as examples. There is also a twitter clone written with redis as an example, but that doesn't mean twitter use redis (twitter use MySQL with heavy memcache caching).

MySql -

1. Structured data
2. ACID
3. Heavy transactions and lookups.

Redis -

1. Non structured data
2. Simple and quick lookups. for eg - token of a session
3. use it for caching layer.

Redis, SQL (+NoSQL) have their benefits+drawbacks and often live side by side:

• Redis - Local variables moved to a separate application
• Easy to move from local variables/prototype
• Persistant storrage
• Multiple users/applications all see the same data
• Scalability
• Failover
• (-) Hard to do more advanced queries/questions on the data
• NoSQL
• Dump raw data into the "database"
• All/most of Redis features
• (-) Harder to do advanced queries, compared to SQL
• SQL
• Advanced queries between data
• All/most of Redis features
• (-) Need to place data into "schema" (think sheet/Excel)
• (-) Bit harder to get simple values in/out than Redis/NoSQL

(different SQL/NoSQL solutions can vary. You should read up on CAP theorem and ACID on why one system can't simultaneously give you all)

According to the official website, Redis is an open source (BSD licensed), in-memory data structure store, used as a database, cache and message broker. Actually, Redis is an advanced key-value store. It is literally super fast with amazingly high throughput as it can perform approximately 110000 SETs per second, about 81000 GETs per second. It also supports a very rich set of data types to store. As a matter of fact, Redis keeps the data in-memory every time but also persistent on-disk database. So, it comes with a trade-off: Amazing speed with the size limit on datasets (as per memory). In this article, to have some benchmarks in comparison to MySQL, we would be using Redis as a caching engine only.

Read Here: Redis vs MySQL Benchmarks