Eh... there are things in here that bother me. Did Salvatore review this? (I'm prepared to be wrong about all of this, and intend this comment constructively). Did you get a take from the Redis mailing list about it? Some quick hits:
* Lists, sets, zsets and hashes are all means of constructing queries that act on data (or metadata) as well as key names; it's misleading to suggest that "keys are everything" in Redis.
* Sets aren't simply a way of storing things for which you don't want duplicates; they are the idiom in which flexible queries are constructed in Redis, period. redis sets : SQL joins :: register-operand instructions : C code.
* In the same vein: since probably the most important idiom in Redis is storing things indirected through keys (often incr ID keys) --- such that for instance you can index and query data through set math operations --- you might want to spend a chapter very early on explaining this idiom. It's not a weird hack to store "bob_friends=set(jack,jill,jim) bob=hash(name: bob, role: admin) &c" --- it's how you're intended to use Redis.
The very idea that one might need to store the same JSON blob in two keys so that users could be indexed both by name and ID suggests that the author hasn't really metabolized this idea. Nobody who works in Redis regularly would ever make that mistake; they'd give users an opaque incr id, and then index those ids by username in a separate key.
The idea that one might be worried about how much space those indexes consume is weird, since any other database would consume even more space to do its (much more heavyweight) indexing.
One might worry that readers new to Redis would get the impression that Redis is much more narrowly targeted than it in fact is.
In my experience, the difference between the first wave of users (the alpha geeks) and everyone else is huge. Alpha geeks are hugely passionate, they can easily digest programmers-documentation..they just get it. The group of users that comes after that is far more diverse and many of them need to be carefully and gently introduced to new technologies. For example, you might get people who want to learn Redis but won't be 100% sure about the set command from seeing something like "set users:leto '{....}'" and from reading an explanation.
The fact that I bring up duplicating values shouldn't tell you that I don't grok Redis. It should tell you that you and I differ in how we think new users will approach Redis and how the story needs to be told for them to better understand it.
I really do appreciate your feedback. Your example on set-usage is good and I'll look at adding it. But, for the rest, I think you are projecting your own understanding/knowledge onto the masses.
Short is good. I've been working on my own creative commons book (4th edition of my Java AI book), and you have me at least thinking of segmenting that into several mini-books (search, machine learning, etc.).
FWIW, I've gotten more positive feedback about the length of these than anything else. It isn't "thanks for making it free", or "thanks for making it good". It's always "thanks for making it short!" :)
Karl, since this is already written in Markdown, have you thought about putting it on Leanpub? Our books are in Markdown, and we generate PDF, EPUB and MOBI. We support variable price and a minimum price of $0 if you want, so readers can pay whatever they want as long as it's your minimum price. Royalties are 90% - 50 cents per copy. Finally, readers get automatic updates if you post new versions etc.
Karl, I read this twice over the weekend and it very much changed how I was thinking about Redis. Thanks for making it understandable and for having such a clear writing style.
* Lists, sets, zsets and hashes are all means of constructing queries that act on data (or metadata) as well as key names; it's misleading to suggest that "keys are everything" in Redis.
* Sets aren't simply a way of storing things for which you don't want duplicates; they are the idiom in which flexible queries are constructed in Redis, period. redis sets : SQL joins :: register-operand instructions : C code.
* In the same vein: since probably the most important idiom in Redis is storing things indirected through keys (often incr ID keys) --- such that for instance you can index and query data through set math operations --- you might want to spend a chapter very early on explaining this idiom. It's not a weird hack to store "bob_friends=set(jack,jill,jim) bob=hash(name: bob, role: admin) &c" --- it's how you're intended to use Redis.
The very idea that one might need to store the same JSON blob in two keys so that users could be indexed both by name and ID suggests that the author hasn't really metabolized this idea. Nobody who works in Redis regularly would ever make that mistake; they'd give users an opaque incr id, and then index those ids by username in a separate key.
The idea that one might be worried about how much space those indexes consume is weird, since any other database would consume even more space to do its (much more heavyweight) indexing.
One might worry that readers new to Redis would get the impression that Redis is much more narrowly targeted than it in fact is.