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



Redis Guide: What Each Redis Data Type Should Be Used For

Salvatore Sanfilippo offers a very detailed answer to this question on StackOverflow. Just to give you a glimpse.

  • strings:
    • to avoid converting your already encoded data (JSON, HTML)
    • bitmaps and in general random access arrays of bytes
  • lists:
    • when you are likely to touch only the extremes of the list: near tail, or near head
    • capped collection of N items where usually we access just the top or bottom items, or when N is small
  • sets:
    • to check for existence or size of the collection in a very fast way
    • random elements peeking or popping
    • to represent relations (nb: sotrted sets might be more interesting)
  • hashes:
    • to represent objects, composed of fields and values
    • to represent linked data structures, using references
  • sorted sets:
    • maintain ordered lists of unique elements
    • describe relations
    • paginate the list of items and to remember the ordering
    • priority queues

In the list of top 5 mistakes to avoid when using Redis, I’ve listed not knowing all data types and their corresponding operations as being the top one. So I expect the examples above to come in very handy for a lot of new Redis users.

Original title and link: Redis Guide: What Each Redis Data Type Should Be Used For (NoSQL database©myNoSQL)