If you don't already know how to use Redis, it's hard to think of a technology that offers as good a return on time invested - you really can pick up everything you need to know about it in a few hours, and once you add it to your tool kit you'll find no shortage of problems that it can help solve.
Your post got me thinking: what other things can one learn that give ridiculously good return on time invested? Not just technologies, but anything. Here's an incomplete list:
* Graph flow: a lot of interesting problems can be solved efficiently by converting them to graph flow problems.
* Basic microeconomics: the world looks different once you understand it, and it's not that hard to learn. A cheap enlightenment boost!
* Monoid-cached trees. Guy Steele explains better than I could. Video and slides:
One complaint: Don't actually use the KEYS command. It's not very efficient. Instead, keep a set of all the keys you would want to delete. When you call KEYS, it has to do a linear scan of every key in the database, and since it is stored as a hash table there really isn't a way to optimize it. It's useful for inspecting things in redis-cli, but not much else.
but strings in most languages such as C, Python or Ruby are exactly random access sequences of bytes. And btw 'binary' is a form of encoding in a string. So Redis strings are strings ;) in a full sense.
I think that if calling what are strings, "strings", can generate confusion, go figure how much confusion can be created by calling them with another term...
They happen to be equivalent at a data storage level, but they're not semantically equivalent. I think the article explains the difference quite well to be honest.
Maybe a better term would be "scalar" like in vector calculus or Perl, to emphasize that the larger data structures consist of scalars arranged in some form.
> but strings in most languages such as C, Python or Ruby are exactly random access sequences of bytes.
This is true, but at least with Ruby it's widely regarded as an embarrassing design mistake. (Not that it's a mistake in Redis; a database has different goals from a language.)
#1 you rock for Redis. hail/praise/kudos (seriously!)
#2 I and a lot of other programmers tend to think of a string (for me, going back decades) as "a byte sequence which just happens to represent text, in some encoding". It's not merely a byte array. A byte array could be say an encoded image (PNG, GIF, etc.) or some other serialized object. That said, this distinction/confusion in terminology is not important. It pales in comparison to how awesome Redis is. :)
I love that this is so direct, and it's helped me learn more about redis.
Some of the explanations are a bit confusing though. I'm not sure I know what a List is - though I suspect, knowing JavaScript, Python, and PHP pretty well, I know what a List is. Descriptions like "If a hash is like a string with an extra field layer" are just plain confusing. Why not put it in terms of commonly understood programming languages? The examples are in Ruby, why not let us know which Ruby structures these most closely correspond to, for instance?
I do appreciate the particular names in the example text, however so I'm willing to overlook this.
There are obvious reasons for needing networking access, but even when you don't need it:
1) Redis is much more memory efficient than your average programming language.
2) Redis handles persistence and replication for you. Not a joke.
3) Accessing data with atomic operations on complex data types from your application using multiple threads can create more problems.
4) Your application is free of doing other stuff if you use a non blocking client, if you are asking Redis to do computationally intensive tasks.
5) There is no easy way to model Redis sorted sets, in many very high level languages, at the same speed, without writing a C extension.
Another benefit I run into is sidestepping the GIL in Python or Ruby. Instead of using multiple threads to manipulate data in-process, use multiple processes to manipulate the data in Redis.
I'd say it's like anything else. It depends how you are bound. If you can run them on the same machine, go ahead..but if you become resource bound, you split them up, then you shard...common scaling approach.
As for why not use native structures? You need to build persistence, transaction support, pub/sub api, thread awarness. Also, if you happen to use a generic data structure, like Java's HashSet, you probably won't get even close to the same level of performance.
My first questions about any new dev tool/tech are "Where does it run?" and "What is the primary interface for working with it?"
So I'd love to see the paragraph that begins "There are various ways to install Redis" expanded. In particular, what's the workflow between a) I just downloaded something called Redis, and b) I am issuing commands to learn along with these examples.
the #1 rule of Windows development/hosting is to NOT do Windows development/hosting. Bias to Linux, Mac or another Unix-like instead. Life will be so much better in so many ways.
In part 2, correct me if I'm wrong, but isn't the member you're adding for jobs a key? Isn't the code to see if it's already a member unnecessary? It shouldn't add duplicates since the member's value doesn't change (it's a key). Granted, it's unnecessary to re-add the key to the jobs sorted set as the code does, but the explanation doesn't seem right. On the other hand, you could call zadd again to change the score.
