NoSQL Benchmarks NoSQL use cases NoSQL Videos NoSQL Hybrid Solutions NoSQL Presentations Big Data Hadoop MapReduce Pig Hive Flume Oozie Sqoop HDFS ZooKeeper Cascading Cascalog BigTable Cassandra HBase Hypertable Couchbase CouchDB MongoDB OrientDB RavenDB Jackrabbit Terrastore Amazon DynamoDB Redis Riak Project Voldemort Tokyo Cabinet Kyoto Cabinet memcached Amazon SimpleDB Datomic MemcacheDB M/DB GT.M Amazon Dynamo Dynomite Mnesia Yahoo! PNUTS/Sherpa Neo4j InfoGrid Sones GraphDB InfiniteGraph AllegroGraph MarkLogic Clustrix CouchDB Case Studies MongoDB Case Studies NoSQL at Adobe NoSQL at Facebook NoSQL at Twitter



Replacing your SQL store with Redis

Please don’t do this… it is wrong on so many levels:

Our goal is to get a ‘data store abstraction’ that we can use in our app. This abstraction must save and retrieve native Python objects. The first thing that comes to mind is just saving each value in an object as a string representation, the problem with this is that most application objects usually have native data structures such as dictionaries and objects such as integers – these will become strings and loose their original form.

Let me point a couple of issues:

  1. if you need a document database just use one! There are at least 2 solid stable solution around: CouchDB and MongoDB, and two more promising: RavenDB and Terrastore. If you plan to create your own on top of a key-value store, you are just repeating the last 30 years story of using relational databases for everything
  2. remember Redis is not just a key-value store. It has data structures, like lists, sets, and hashes/dicts. Learn the product before reinventing the wheel!

Original title and link for this post: Replacing your SQL store with Redis (published on the NoSQL blog: myNoSQL)