redis: All content tagged as redis in NoSQL databases and polyglot persistence
Couple of things I don’t see mentioned in the RedMonk post:
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.
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)
Redis and VoltDB are mostly OLTP only databases
Original title and link: NoSQL Databases Adoption in Numbers ( ©myNoSQL)
Salvatore Sanfilippo offers a very detailed answer to this question on StackOverflow. Just to give you a glimpse.
- to avoid converting your already encoded data (JSON, HTML)
- bitmaps and in general random access arrays of bytes
- 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
- 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)
- 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 ( ©myNoSQL)
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:
- Choose consistent ways to name and prefix your keys. Manage your namespace.
- Create a “registry” of key prefixes which maps each to your internal (perhaps wiki) documents for those application which “own” them.
- 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.
- 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.
- 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
- not knowing all data types and their corresponding operations supported by Redis and confusing it for a common key-value store
- not using smart keys (plus this and this)
- not having scripts to manage ranges of keys based on your naming strategy
- not using pipelines and MULTI/EXEC. On the other hand confusing Redis MULTI/EXEC/DISCARD with a relational database transactions
- 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? ( ©myNoSQL)