ALL COVERED TOPICS

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

NAVIGATE MAIN CATEGORIES

Close

redis: All content tagged as redis in NoSQL databases and polyglot persistence

NoSQL Databases Adoption in Numbers

Source of data is Jaspersoft NoSQL connectors downloads. RedMonk published a graphic and an analysis and Klint Finley followed up with job trends:

NoSQL databases adoption

Couple of things I don’t see mentioned in the RedMonk post:

  1. if and how data has been normalized based on each connector availability

    According to the post data has been collected between Jan.2011-Mar.2012 and I think that not all connectors have been available since the beginning of the period.

  2. if and how marketing pushes for each connectors have been weighed in

    Announcing the Hadoop connector at an event with 2000 attendees or the MongoDB connector at an event with 800 attendeed could definitely influence the results (nb: keep in mind that the largest number is less than 7000, thus 200-500 downloads triggered by such an event have a significant impact)

  3. Redis and VoltDB are mostly OLTP only databases

Original title and link: NoSQL Databases Adoption in Numbers (NoSQL database©myNoSQL)


Redis Persistence Demystified

TL;DR:

even if Redis is an in memory database it offers good durability compared to other on disk databases.

But you must read the post for all the nitty-gritty.

Original title and link: Redis Persistence Demystified (NoSQL database©myNoSQL)

via: http://antirez.com/post/redis-persistence-demystified.html


In-Memory Key-Value Store in C, Go and Python

Graham King:

On paternity leave for my second child, I found myself writing an in-memory hashmap (a poor-man’s memcached), in Go, Python and C. I was wondering how hard it would be to replace memcached, if we wanted to do something unusual with our key-value store. I also wanted to compare the languages, and, well, I get bored easily!

Actually it’s very easy and doesn’t require any coding at all. Plus you’ll get a bit more than what you’d expect.

Original title and link: In-Memory Key-Value Store in C, Go and Python (NoSQL database©myNoSQL)

via: http://www.darkcoding.net/software/in-memory-key-value-store-in-c-go-and-python/


Reinventing Reliable Queues With Redis Lua Scripting

Salvatore Sanfilippo:

Redis 2.6 support for Lua scripting opens a lot of possibilities, basically because you can do atomically a lot of things that before required to pay a big performance hit.

In this blog post I want to show a pattern based on the scripting capability that can be used to implement reliable queues.

I know I might upset a few people, but this feels like reinventing some wheels. Having server-side scripting support in Redis makes it a possible good fit for many new use cases, so I don’t think there’s a need to reinvent solutions that can already address an even wider range of scenarios.

Original title and link: Reinventing Reliable Queues With Redis Lua Scripting (NoSQL database©myNoSQL)

via: http://antirez.com/post/250


Redis: Hell Yeah Take 2

Redmonk’s James Gavernor in a sort of a documented Redis? Hell yeah!:

Indeed mentions on HackerNews is just a sign of breaking the awareness threshold. But with awareness comes adoption. The only thing that remains to be established is the relevance of the HN community.

Original title and link: Redis: Hell Yeah Take 2 (NoSQL database©myNoSQL)

via: http://www.redmonk.com/jgovernor/2012/03/15/redis-utterly-killed-it-in-2010-check-out-the-growth-in-share-of-developer-conversation/


Redis Lua Scripting Is Badass

TJ Holowaychuk:

Lua is a great fit for Redis, they have similar philosophies, being simple, small, and fast.

Hell yeah! I almost can feel it!

Original title and link: Redis Lua Scripting Is Badass (NoSQL database©myNoSQL)

via: http://tjholowaychuk.com/post/19321054250/redis-lua-scripting-is-badass


NoSQL Security: Installing and Hardening Redis

Many useful pieces of advice—from the very basics to renaming commands—in Marc Wickenden post about securing Redis:

Redis doesn’t have much in the way of security so I knew that anyone who managed to pop the box could theoretically connect to the local Redis instance and mess around. I’ll take you through the steps I took to install and harden Redis, on a Debian Squeeze GNU/Linux box.

Archived.

Original title and link: NoSQL Security: Installing and Hardening Redis (NoSQL database©myNoSQL)

via: http://blog.7elements.co.uk/2012/03/installing-and-hardening-redis.html


Is Memcached a Dinosaur in Comparison to Redis?

Interesting comments on StackOverflow:

So, honestly - Is memcache really that old dinousaur that is a bad choice from a performance perspective when compared to this newcomer called Redis?

Here’s mine: feature-wise Redis has already overpasssed Memcached in almost all aspects. Redis 3.0 will bring Redis Cluster a distributed implementation of a subset of Redis standalone—check this for an detailed explanation of Redis Cluster. Production-wise though, Memcached will not be replaced so easy as so many services rely on it for quite some time.

Original title and link: Is Memcached a Dinosaur in Comparison to Redis? (NoSQL database©myNoSQL)

via: http://stackoverflow.com/questions/2873249/is-memcached-a-dinosaur-in-comparison-to-redis


Redis and MongoDB Can Work Together to Perform Distinct, Complex Queries

Cody Powell:

It turns out that, technically, I was correct. I could use MongoDB as a key-value store for caching, much like I could use my Mazda 3 as an amphibious assault vehicle. In practice, neither would be optimized for those use cases.

Use the same principle if you have to build MongoDB work queues.

Original title and link: Redis and MongoDB Can Work Together to Perform Distinct, Complex Queries (NoSQL database©myNoSQL)

via: http://architects.dzone.com/articles/redis-and-mongodb-can-work?mz=36885-nosql


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)


What Are 5 Mistakes to Avoid When Using Redis?

Jim Dennis answering in detail this question on Quora:

Here are a few things I’d suggest thinking about when you are considering using Redis:

  1. Choose consistent ways to name and prefix your keys.  Manage your namespace.
  2. Create a “registry” of key prefixes which maps each to your internal (perhaps wiki) documents for those application which “own” them.
  3. For every class of data you put into your Redis infrastructure: design, implement and test the mechanisms for garbage collection and/or data migration to archival storage.
  4. Design, implement and test a sharding (consistent hashing) library before you’ve invested much into your application deployment and ensure that you keep a registry of “shards” replicated on each server.
  5. Isolate all your K/V store and related operations into a your own library/API or service and absolutely enforce the use of that API/service with an unrelenting and mercilessly iron hand

My five:

  1. not knowing all data types and their corresponding operations supported by Redis and confusing it for a common key-value store
  2. not using smart keys (plus this and this)
  3. not having scripts to manage ranges of keys based on your naming strategy
  4. not using pipelines and MULTI/EXEC. On the other hand confusing Redis MULTI/EXEC/DISCARD with a relational database transactions
  5. not being aware of the MOM capabilities available in Redis (including both queues and PUB/SUB) and using something else to fake similar behavior.

What are your 5s?

Original title and link: What Are 5 Mistakes to Avoid When Using Redis? (NoSQL database©myNoSQL)


Induction: SQL? NoSQL? Explore, Query, Visualize

Matt Thompson‘s Induction is a free OS X application allowing access and visualization of data stored in PostgreSQL, MySQL, SQLite, Redis, and soon MongoDB.

Some are asking for a common NoSQL query language, some are trying to put a tabular format on top of NoSQL data, and some are building an indirection layer as a tool.

Original title and link: Induction: SQL? NoSQL? Explore, Query, Visualize (NoSQL database©myNoSQL)

via: http://inductionapp.com/