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

Databases at 14.4Mhz

blog.foundationdb.com

Post reply on HN
Print view View original

31–40 of 86 posts

Re: Databases at 14.4Mhz

#31

Post by dchichkov »

nlavezzo wrote: post #26
dchichkov wrote: post #24

Earlier quoted context omitted.

I'm not so sure. Have the latencies claimed by FoundationDB been measured on multi-key transactions? And if you need these guaranties, it seems like "Most of these operations can be implemented on top of the existing RAMCloud features". I would expect it to be possible to implement that and stay well withing the latency budget, provided that a single-key durable write is 100 times faster.

All of the transactions in the test noted in the blog are multi-key transactions. (20 key updates)

When claiming the 14.4MHz number, is that per 20-key update? Or a single key update in the 20-key update? And what's the latency on the 20-key update?

Re: Databases at 14.4Mhz

#32

Post by imanaccount247 »

Why the deliberately misleading comparisons? If you are doing something genuinely impressive, then you should be able to be honest about it and have it still seem impressive. One tweet is not one write. Comparing tweets per second to writes per second is complete nonsense. How many writes a tweet causes depends on how many followers the person who is tweeting has. The 100 writes per second nonsense is even worse. Do you just think nobody is old enough to have used a database 15 years ago? 10,000 writes per second was no big deal on of the shelf hardware of the day, nevermind on an actual server.

Re: Databases at 14.4Mhz

#33

Post by SpeckledJim1917 »

simcop2387 wrote: post #12
lttlrck wrote: post #3

"Or, as I like to say, 14.4Mhz." Sorry, I don't like that at all.

I would agree. While 14.4 million writes per second is impressive, it definitely doesn't fit the definition of the Hz unit (cycles per second).

Right, because a database write is not generally a periodic event. The unit they want is the becquerel - 14.4MBq might even sound more impressive because not so many people are familiar with that unit!

Re: Databases at 14.4Mhz

#34

Post by fry_the_guy »

Dave_Rosenthal wrote: post #19
hendzen wrote: post #9

This is very impressive, however... See this tweet by @aphyr: https://twitter.com/aphyr/status/542755074380791809 (All credit for the idea in this comment is due to @aphyr) Basically because the transactions modified keys selected from a uniform distribution, the probability of contention was extremely low. AKA this workload is basically a data-parallel problem, somewhat lessening the impressiveness of the high throu…

Actually, @aphyr's analysis is wrong. In fact it's actually worse that he says. There is an exactly 0% chance of conflicts between two transactions that each only write 20 random keys (as they do in this test). This is perhaps counterintuitive, but, because there are no reads, any serialization order is possible and therefore there is no chance of conflict. Equally wrong is his assumption that this has any bearing on…

Your definition of performance is a little weird.

Presumably you will want to retry conflicting transactions, so you generally would not count them towards your throughput.

For example if I commit 100 transactions per second, and 90% of them return conflicts, I am only successfully committing 10 transactions per second.

Re: Databases at 14.4Mhz

#35

Post by Dave_Rosenthal »

jchrisa wrote: post #27
bsaul wrote: post #10

Just watched the linked presentation about "flow" here : https://foundationdb.com/videos/testing-distributed-systems-... Is it really the first Distributed DB project to have built a simulator ? Because frankly, if that's the case, it seems revolutionary to me. Intuitively, it seems like bringing the same kind of quality improvement as unit testing did to regular software development. PS : i should add that this talk…

At Couchbase we have a plethora of simulators. Simulations of cluster topology changes, simulations of failure scenarios, simulations of workloads to estimate requried cluster sizes, etc. Here's one: https://github.com/couchbaselabs/cbfg

I think the difference is that FoundationDB has only one, and it's not an external simulation. The actual code that runs in production can also deterministically simulate a cluster of itself.

I do believe this is unique among publically-available distributed databases.

Re: Databases at 14.4Mhz

#36

Post by Dave_Rosenthal »

fry_the_guy wrote: post #34
Dave_Rosenthal wrote: post #19

Earlier quoted context omitted.

Actually, @aphyr's analysis is wrong. In fact it's actually worse that he says. There is an exactly 0% chance of conflicts between two transactions that each only write 20 random keys (as they do in this test). This is perhaps counterintuitive, but, because there are no reads, any serialization order is possible and therefore there is no chance of conflict. Equally wrong is his assumption that this has any bearing on…

Your definition of performance is a little weird. Presumably you will want to retry conflicting transactions, so you generally would not count them towards your throughput. For example if I commit 100 transactions per second, and 90% of them return conflicts, I am only successfully committing 10 transactions per second.

That's true: a large conflict rate would eat into your budget because clients would be retrying.

Of course most real world workloads are (hopefully!) no where near 90% conflicts. If you had a 90% transaction conflict rate you could expect FoundationDB performance to drop by about 30-60% due to retries (and, worse news, you would need to rethink your architecture).

Re: Databases at 14.4Mhz

#37

Post by jrochkind1 »

imanaccount247 wrote: post #32

Why the deliberately misleading comparisons? If you are doing something genuinely impressive, then you should be able to be honest about it and have it still seem impressive. One tweet is not one write. Comparing tweets per second to writes per second is complete nonsense. How many writes a tweet causes depends on how many followers the person who is tweeting has. The 100 writes per second nonsense is even worse. Do…

it's just a comparison to give you a sense of what those numbers look like, order of magnitude comparisons. I didn't find it misleading, and didn't think it meant that you'd be able to run twitter on their db on one commodity server. But it's an order of magnitude estimate to give you a sense of the scale.

Re: Databases at 14.4Mhz

#38

Post by jrochkind1 »

simcop2387 wrote: post #12
lttlrck wrote: post #3

"Or, as I like to say, 14.4Mhz." Sorry, I don't like that at all.

I would agree. While 14.4 million writes per second is impressive, it definitely doesn't fit the definition of the Hz unit (cycles per second).

"Hertz" just means "per second". It can be anything per second, there are no units in the numerator. It just a measure of frequency, anything per second.

http://en.wikipedia.org/wiki/Hertz

If anything you are counting is happening 14.4 million times a second, then that thing is happening at 14 megahertz. It's just a unit. If there are 14.4 million writes per second, then the writes are occuring at 14.4 mega hertz. That's just the definition of hertz.

Haha, Google agrees, check it out: https://www.google.com/?q=4+per+second#q=4+per+second

Re: Databases at 14.4Mhz

#39

Post by shortstuffsushi »

landryraccoon wrote: post #23
shortstuffsushi wrote: post #15

As someone who has no idea about the cost of high-scale computing like this, is $150/hr reasonable? It seems like an amount that's hard to sustain to me, but I have no idea if that's a steady, all the time rate, or a burst rate, or what. Or if it's a set up you'd actually ever even need -- seems like from the examples they mention (like the Tweets), they're above the need by a fair amount. Anyone else in this sort of…

Per the article, it's about 1/20th the cost that Google would charge you for the same number of writes.

I had seen that as well, actually. Is this the kind of data or transaction level that might only be expected for a Google level throughput?

Re: Databases at 14.4Mhz

#40

Post by emn13 »

felixgallo wrote: post #6

This looks very interesting and congratulations to the FoundationDB crew on some pretty amazing performance numbers. One of the links leads to an interesting C++ actor preprocessor called 'Flow'. In that table, it lists the performance result of sending a message around a ring for a certain number of processes and a certain number of messages, in which Flow appears to be fastest with 0.075 sec in the case of N=1000 a…

There's got to be some mistake there somewhere - on your part, or on theirs - because there's no way erlag improved from 1.09 seconds to 34 microseconds on pretty much any benchmark between 2010 and 2014. Even the factor 1000 (the message count) isn't enough to account for that difference - something's fishy.
Post reply on HN