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?
They are great weapons though. I've never cleaned mine or had a jam. I hope this database is that good!
AK-47. The very best there is. When you absolutely, positively got to kill every motherf@#$%r in the room, accept no substitutes.
"According to Director Andrew Niccol in the DVD commentary, the guns were real guns rented from a real arms dealer, as it was cheaper for the production to rent 3,000 real guns than to rent 3,000 blank converted props. "
BTW, I highly recommend "The Gun" by C.J. Chivers. It's a fascinating historical treatise about this weapon.
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. 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. # 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 changedNow 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.
EDIT: looks like there is rollback support: http://redis.io/commands/discard
> 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."
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.
step 1. Someone posts something (anything will do) on a blog
step 2. HN tears it apart and reconstitutes it with some decent approximation of truth and usually a fair bit of insight.
Basically, the source content is just the jumping off point. The blogs serve as a focal point for directing the HN hive's attention for a while.
You could post a story titled "Sarah Palin is more influential than the Pope but less influential than the iPhone" and fill it with lolcat pictures and still get an interesting discussion here.
Why? Because smart people are awesome.
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.)
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.
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.
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?
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().
The kernel does let userspace have a /little/ fun on its own.
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.
One hopes the meat is not between the rubber and the road. That would be unfortunate.
This article should not get upvoted.
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!
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).
okay okay. i hereby patent the definition 'an iPhone of databases' :)