| From the point of view of durability there are no problems in using Redis as a primary data store, make sure to use AOF with fsync everysec setting. However if you should do it or not depends on the data you need to store, and even more in the kind of queries you want to run against the data set. If you end with a complex schema in order to support SQL-alike queries it is a bad idea. If you want to query data in a very Redis-API-obvious way, it is a good idea. A few remarks about not correct ideas expressed in different posts here: 1) Redis transactions are not good since there is no rollback: not true since in Redis query errors can only happen in the case of a type mismatch more or less, so when you have a MULTI/EXEC block if there are no obvious bugs in your code you are going to see all the commands executed. 2) Redis durability is weak. Not true since with AOF + fsync it offers a level of durability that is comparable to many other data stores. Depends on the actual configuration used of course. Your usual MyISAM table for sure is not more durable than Redis AOF + fsync everysec just to make an example. Replication can add another level of durability of course. 3) RDB persistence instead is a weak durability configuration, but works for many applications where in the case of a bad event to have 15 minutes of data lost is a viable option. So if you, for instance, are planning to use Redis to store your meta data, you can avoid having this same dataset duplicated in other places.
Redis is also pretty solid in providing solutions to backup your data. For instance while you use AOF + fsync you can still call BGSAVE and create a compact .rdb file to backup. You'll always be able to restore the data set from the RDB file. That said I think that in most complex applications using Redis + an on disk and "more query friendly" data store makes a lot of sense. Redis + Mongo, Redis + Mysql, Redis + Riak and so forth are very interesting configurations IMHO. |