Redis: the AK-47 of databases

The title randomly reminded me of the AK-47 quote from Lord of War (an actually decent Cage film, and definitely a good bit of monologue):<p><i>Of all the weapons in the vast soviet arsenal, nothing was more profitable than Avtomat Kalashnikova model of 1947. More commonly known as the AK-47, or Kalashnikov. It's the world's most popular assault rifle. A weapon all fighters love. An elegantly simple 9 pound amalgamation of forged steel and plywood. It doesn't break, jam, or overheat. It'll shoot whether it's covered in mud or filled with sand. It's so easy, even a child can use it; and they do. The Soviets put the gun on a coin. Mozambique put it on their flag. Since the end of the Cold War, the Kalashnikov has become the Russian people's greatest export. After that comes vodka, caviar, and suicidal novelists. One thing is for sure, no one was lining up to buy their cars.</i><p>Only tangentially related :) but I thought worth sharing. Anyone care to write a redis version?

<p><pre><code> &#62; In the spirit of full disclosure, I’m a newb to Redis. My &#62; knowledge is basically the contents of this post (at the &#62; time of writing). I don’t use it in production (yet). &#62; Likewise I’m no expert in AK-47s (I’ve never even fired &#62; one) or guns in general. I’m aware via notoriety alone. </code></pre> Fantastic quote. So you're hardly familiar with either component of your simile, but you'll post it anyway? I really don't expect <i>New Yorker</i>-esque editing from bloggers, but that's simply not very substantial writing.<p>No wonder people make fun of the so-called "NoSQL movement."

"According to AK-47 legend, assault rifles were not popular because of their tendency to consume large amounts of ammo. The Soviets embraced the idea and simply supplied their troops with more ammo. Kinda like Redis and RAM."<p>That's obviously just a legend. This debate was actually carried out in the 2nd half of the 19th century, starting with the Civil War. (Many repeating rifle designs were offered to the Union. Quartermasters repeatedly shut them down on account of expected difficulties with ammo supply. After much time and effort, a few repeating rifles made it through, particularly to the cavalry, where they proved quite decisive in the last year of the war. See Five Forks, for instance.)

Being the AK-47 of databases is not a bad way to be known.<p>That said I hope the author will revisit the topic when he has more knowledge of the subject matter, such as when using it in production for a while on a fair sized project with a lot of users. That's where the rubber meets the road, first impressions tend to gloss over the areas where the meat is.

Eek. Locking the entire data set to perform transactions? Isn't that so... MyISAM? Does rolling the transaction back work? The optimistic lock is not a great solution either: instead of deadlocking while waiting for a lock to be released, you are now stuck in a while (!saved) loop. Imagine two web pages trying to update the same resource at the same time.<p>Also this part of the config:<p><pre><code> save 900 1 save 300 10 save 60 10000 </code></pre> is not at all obvious. Maybe it's better documented in the sample config.

Factual incorrectness aside, and even speaking as a person that doesn't have much to do with anything other than SQL RDBMSes: this style of presentation piqued my interest in Redis. Seeing how fast and easy it was to get up and running, seeing how simple the protocol was, and getting a smattering of its features in this very terse format was effective on me.

The author needs to know more about databases before claiming something is the AK-47 of the subject. It kinds of reminds me of those guys who think they are gurus just because they know some rarely used Linux commands, while in fact they don't have good understanding of OS. :)

The information about transactions in this article is wrong. Read the redis docs he actually points to for an accurate description.<p>This article should not get upvoted.

"The entire dataset is in RAM."<p>How can they guarantee that, when RAM is little more than a disk cache on modern operating systems? Is there a syscall that prevents specified pages of virtual memory from being paged out to disk? Or is Redis implemented as a kernel module?

In another comment, someone compared the PUB/SUB feature of Redis to ZeroMQ. Can the PUB/SUB feature of Redis function as a queue system for many common uses, or is there another significant difference that sets a full queue implementation apart? I ask because I am not particularly familiar with Redis, my queue usage has been fairly simple so far and I would enjoy simplifying my technology stack by combining the two if it makes sense.

Redis is great for small things. Massive scale players in the write-heavy owrld can rarely consider it in its current form.

"Pub/Sub is a unique and useful feature."<p>Pub/sub exists in a multitude of different pieces of software. ZeroMQ has a pub/sub feature. PostgreSQL has the NOTIFY/LISTEN command which is also a Pub/Sub channel allowing all those listening to be notified of certain events.<p>This is by no means unique to Redis. It is very useful, so I'll agree with that!

I served in the bulgarian army with this weapon, and it was very easy to handle. That's all I can say<p>But every weapon was a bit off, so you had to get used to it (I guess that might be the same for all weapons).

The total number of the AK-type rifles made worldwide during the last 50 years is estimated at 90+ millions. Does the title implies that Redis will handle this amount of values too?

This one of very few google hits for the phrase "get the juxt".

AK of DBs should be used for some Russian DB! or Chinese...<p>okay okay. i hereby patent the definition 'an iPhone of databases' :)