Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Redis: the AK-47 of databases

flazz.me

Post reply on HN
Print view View original

11–20 of 82 posts

Re: Redis: the AK-47 of databases

#11

Post by IgorPartola »

xd wrote: post #4
IgorPartola wrote: post #2

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. Also this part of the config: save 900 1 save 300 10 save 60 1…

MyISAM doesn't support transactions.

My 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

Re: Redis: the AK-47 of databases

#12

Post by IgorPartola »

code_duck wrote: post #3
IgorPartola wrote: post #2

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. Also this part of the config: save 900 1 save 300 10 save 60 1…

According 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.

Ah: 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.

Re: Redis: the AK-47 of databases

#13

Post by jtdowney »

ErrantX wrote: post #10

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): 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 o…

It 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.

Re: Redis: the AK-47 of databases

#14

Post by nickpinkston »

ErrantX wrote: post #10

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): 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 o…

I'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!

Re: Redis: the AK-47 of databases

#15

Post by lukesandberg »

IgorPartola wrote: post #12
code_duck wrote: post #3

Earlier quoted context omitted.

According 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.

Ah: 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.

im 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

Re: Redis: the AK-47 of databases

#16

Post by jamesli »

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. :)

Re: Redis: the AK-47 of databases

#17

Post by leftnode »

nickpinkston wrote: post #14
ErrantX wrote: post #10

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): 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 o…

I'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!

If we're being pedantic, they use magazines, not clips :)

Re: Redis: the AK-47 of databases

#18

Post by MichaelStubbs »

IgorPartola wrote: post #2

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. Also this part of the config: save 900 1 save 300 10 save 60 1…

The 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  
  #
  #   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

Re: Redis: the AK-47 of databases

#19

Post by [deleted] »

IgorPartola wrote: post #12
code_duck wrote: post #3

Earlier quoted context omitted.

According 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.

Ah: 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.

[deleted]

Re: Redis: the AK-47 of databases

#20

Post by adamtj »

"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?

Post reply on HN