9 ms·
Redis: the AK-47 of databases
- mono 16y agoThe 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?
- malkia 16y agoI served in the bulgarian army with this weapon, and it was very easy to handle. That's all I can say 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).
- IgorPartola 16y agoEek. 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. Also this part of the config: save 900 1 save 300 10 save 60 10000 is not at all obvious. Maybe it's better documented in the sample config.
- code_duck 16y agoAccording to the first comment, the part about locking the whole data set for MULTI is not accurate. Only the connection calling that is stalled, which makes perfect sense.
- IgorPartola 16y agoAh: http://redis.io/commands/multi http://redis.io/commands/multi. So the problem with this approach is that there are no consistent reads. If I say: MULTI get foo # Returns 'abc' set foo 'abcd' # (as in application code said foo += 'd') EXEC while another process sets foo to 'xyz' between my get and set, I just overwrote that value. No serializable transactions.
- lukesandberg 16y agoim not exactly sure about that but i know that at least for integers there are atomic update commands and that for strings there are atomic append commands. so for this you would really just want to do: APPEND foo d or for more complex situations you could do use WATCH instead of MULTI so that you can get the intermediate results. so for your example: WATCH foo GET foo ->value //calculate new_value MULTI SET foo new_value EXEC now if at any other operation (not part of this connection) modifies foo then the transaction will be aborted. GET foo -> value //application logic to update value GETSET foo new_value ->prev then prev will contain the value of foo at the time it was set, so you can then use application logic to roll back or redo the transaction
- deleted 16y ago[deleted]
- liuliu 16y agoRedis is single-thread one-process program. Since the execution only happens when EXEC command received, such scenario cannot exist.
- antirez 16y agoMULTI/EXEC is completely atomic and transactional. You can perform just writes inside the block. If you want atomicity with reads in the middle, you need to use WATCH/MULTI/EXEC that uses an optimistic locking algorithm.
- IgorPartola 16y agoAh, that makes sense. I imagine allowing atomic reads without WATCH would complicate the code quite a bit.
- antirez 16y agoIndeed, not very Redis-ish :) With WATCH is very easy. WATCH this keys. Perform your reads. Prepare to write in a transaction. If at least one key was modified in the meantime the transaction will fail.
- xd 16y agoMyISAM doesn't support transactions.
- IgorPartola 16y agoMy point exactly. MyISAM supports locking the entire table, performing the actions you want to perform and releasing the lock. And there is no rollback, if something goes wrong. The only thing this guarantees is that you have exclusive access to the data. Seems to me that this is what MULTI does as well. EDIT: looks like there is rollback support: http://redis.io/commands/discard http://redis.io/commands/discard
- pietern 16y agoIt's called optimistic for a reason. You assume there is low contention and configure your client to have random back off.
- jcromartie 16y agoMaybe not, but I found the docs in about 10 seconds. http://redis.io/topics/persistence http://redis.io/topics/persistence
- antirez 16y agoWarning, the documentation was not updated with the current behavior! Now I clearly state in the doc that transactions are reflected also in the append only file, so there is no chance of partial reply. Transactions are also applied to the master -> slave link, so also slaves will either have the full transaction or nothing. Thanks to @garybernhardt on twitter for noticing this problem.
- deleted 16y ago[deleted]
- MichaelStubbs 16y agoThe configuration options you have quoted are made extremely obvious in the sample configuration and are explained very well. See: # Save the DB on disk: # # save <seconds> <changes> # # Will save the DB if both the given number of seconds and the given # number of write operations against the DB occurred. # # In the example below the behaviour will be to save: # after 900 sec (15 min) if at least 1 key changed # after 300 sec (5 min) if at least 10 keys changed # after 60 sec if at least 10000 keys changed
- IgorPartola 16y agoMy point is the OP talks about how all the options are self-evident.
- jacquesm 16y agoBeing the AK-47 of databases is not a bad way to be known. 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.
- regularfry 16y ago> That's where the rubber meets the road, first impressions tend to gloss over the areas where the meat is. One hopes the meat is not between the rubber and the road. That would be unfortunate.
- jwr 16y agoThe information about transactions in this article is wrong. Read the redis docs he actually points to for an accurate description. This article should not get upvoted.
- fedd 16y agoand the title?
- ErrantX 16y agoThe 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): 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. Only tangentially related :) but I thought worth sharing. Anyone care to write a redis version?
- btipling 16y agoThis is somewhat related: http://i.imgur.com/Tz0m3.png http://i.imgur.com/Tz0m3.png
- jtdowney 16y agoIt reminded me of the AK-47 quote from Jackie Brown: AK-47. The very best there is. When you absolutely, positively got to kill every motherf@#$%r in the room, accept no substitutes.
- nickpinkston 16y agoI'll only be pedantic about them rarely being forged (mostly stamped) and definitely still having problems of overheating. Try firing one on full auto for more than one clip - better have gloves... They are great weapons though. I've never cleaned mine or had a jam. I hope this database is that good!
- leftnode 16y agoIf we're being pedantic, they use magazines, not clips :)
- jamesli 16y agoThe 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. :)
- simonw 16y agoWhat do you think he's missing? The comparison seems rather apt to me - Redis is shockingly simple and surprisingly effective compared to other persistence options.
- deleted 16y ago[deleted]
- adamtj 16y ago"The entire dataset is in RAM." 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?
- wingo 16y agoYour swap should be off, and there is mlockall(2). The kernel does let userspace have a /little/ fun on its own.
- antirez 16y agoRedis uses a memory layout that, unless the instance is completely idle, will make it very easy to touch every page even if there are just a few queries per second. So fare in two years we never saw an instance where there was a latency problem because part of the dataset was swapped on disk by the OS. This is why we currently don't use mlockall().
- mjgoins 16y agoThis one of very few google hits for the phrase "get the juxt".
- draebek 16y agoFactual 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.
- apl 16y ago> In the spirit of full disclosure, I’m a newb to Redis. My > knowledge is basically the contents of this post (at the > time of writing). I don’t use it in production (yet). > Likewise I’m no expert in AK-47s (I’ve never even fired > one) or guns in general. I’m aware via notoriety alone. Fantastic quote. So you're hardly familiar with either component of your simile, but you'll post it anyway? I really don't expect New Yorker-esque editing from bloggers, but that's simply not very substantial writing. No wonder people make fun of the so-called "NoSQL movement."
- mrkurt 16y agoExpert knowledge of an AK-47 wouldn't have improved the post and he managed to expose me to some bits of Redis that I wasn't previously aware of. That makes it more substantial than half the shit that ends up on Hacker News. :)
- sfphotoarts 16y agoI thought it was a well written article that was a good read. Possibly the author was demonstrating humility rather than ego.
- techiferous 16y agoConsider the blog post a conversation starter. You don't have to be an expert in a topic before you can start a useful online discussion about it.
- zach 16y agoYes, bloggers talk about things they just learned about rather than something they're 360-degree experts about. But that's good. It helps them -- it reinforces their learning and they certainly find out if they got something wrong -- and it helps us -- readers see a lot of articles pop up right when people are interested in and passionate about learning something, rather than months later when they know it all and have moved on. Early blogging is quick iteration of knowledge. Blog about something you learned today, not years ago.
- mxavier 16y agoYour last sentence is pretty flawed/ad-hominem. That being said, I do agree in the sense that the comment at the end of the post annoyed me and degraded the value of the article. Certainly, blog about whatever you want, but if you just picked up some new technology, don't write a link bait title and post it on HN. HN needs more breathless hype articles like I need a bullet in the head.
- zeteo 16y ago"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." 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.)
- iujyhgftrgh 16y agoThe British army only just relented - the new SA80 is the first fully automatic rifle to be standard issue.
- ZoFreX 16y agoThe LSW variant has always been fully auto and is 25 years old, and the L85 is to this day semi-automatic and is the main rifle in use in the British army. I don't see how they've "only just relented". Full auto isn't that useful anyway! The ability to empty your magazine in a second comes in handy less often than you'd think. In fact the US Army's M16 was changed from automatic to semi-automatic, so it seems there is a movement in the other direction.
- icegreentea 16y agoThat's not exactly true. The SA80 isn't exactly new. It was in use during the Falklands for example. And the British Army used a version of FN FALs before the SA80s were adopted, and those were also automatic rifles. Now, I'm pretty sure 'automatic' fire was burst limited. But that's pretty much nearly universally accepted as a good idea in main infantry rifles.
- iujyhgftrgh 16y agoIt was standard issue from about 1985/1986 - before that they used self loading rifles ie. one trigger - one round.
- fedd 16y agoAK of DBs should be used for some Russian DB! or Chinese... okay okay. i hereby patent the definition 'an iPhone of databases' :)
- dorkitude 16y agoRedis is great for small things. Massive scale players in the write-heavy owrld can rarely consider it in its current form.
- X-Istence 16y ago"Pub/Sub is a unique and useful feature." 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. This is by no means unique to Redis. It is very useful, so I'll agree with that!
- Periodic 16y agoIn 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.