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

71–80 of 86 posts

Re: Databases at 14.4Mhz

#71

Post by ctdonath »

jrochkind1 wrote: post #38
simcop2387 wrote: post #12

Earlier quoted context omitted.

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. Th…

"Hertz" just means "cycles per second".

The reference is to frequency, not average or typical rate; there's a difference between a tone and pink noise.

Re: Databases at 14.4Mhz

#72

Post by jrochkind1 »

ctdonath wrote: post #71
jrochkind1 wrote: post #38

Earlier quoted context omitted.

"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. Th…

"Hertz" just means " cycles per second". The reference is to frequency, not average or typical rate; there's a difference between a tone and pink noise.

And in their test, they made writes at that frequency, right?

It is, however, commonly used for average frequency rates too, not just measurements of constant frequency. "Frequency" the word means how frequent something happens, right?

I don't know what the 'something' to measure frequency of in pink noise would be, but if there is something to count over time, you can measure it's frequency.

"Frequency is the number of occurences of a repeating event per unit time" says wikipedia. https://en.wikipedia.org/wiki/Frequency

However, it is true that "In some fields, especially where frequency-domain analysis is used, the concept of frequency is applied only to sinusoidal phenomena, since in linear systems more complex periodic and nonperiodic phonomena are most easily analyzed in terms of sums of sinusoids of different frequencies." In some fields.

I have no idea why we're arguing about this except that we like arguing on the internet though.

Re: Databases at 14.4Mhz

#73

Post by ansible »

jedberg wrote: post #67
tinco wrote: post #65

Earlier quoted context omitted.

Perhaps to be able to recover without stressing other nodes? If a disk fails, your reads suddenly all go to 1 node in the replicaset. If then that same node also has to supply the data for the fresh harddrive, it might interfere with the read-performance and/or take a long time to restore full redundancy. Also, in theory the raid 5 configuration would have faster reads.

But then you might as well just use an RF of 3. You get all the benefits you listed above, plus more storage (5.7TB vs 4.5TB), and less configuration hassle. And greater horizontal scalability. And a RAID 5 will never be faster than a RAID 0 or a JBOD. :)

FDB has a substantial per-node license cost. It makes sense to beef up the hardware on individual nodes as much as possible first, then scale out to more nodes.

https://foundationdb.com/pricing

Re: Databases at 14.4Mhz

#74

Post by [deleted] »

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…

[deleted]

Re: Databases at 14.4Mhz

#75

Post by ctdonath »

jrochkind1 wrote: post #72
ctdonath wrote: post #71

Earlier quoted context omitted.

"Hertz" just means " cycles per second". The reference is to frequency, not average or typical rate; there's a difference between a tone and pink noise.

And in their test, they made writes at that frequency, right? It is, however, commonly used for average frequency rates too, not just measurements of constant frequency. "Frequency" the word means how frequent something happens, right? I don't know what the 'something' to measure frequency of in pink noise would be, but if there is something to count over time, you can measure it's frequency. "Frequency is the number…

I have no idea why we're arguing about this except that we like arguing on the internet though.

This.

Re: Databases at 14.4Mhz

#76

Post by felixgallo »

[deleted] wrote: post #74
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…

[deleted]

all your wishes are granted: https://github.com/aphyr

To be sure, he revels in the discomfort of others too much. But he's a young kid just finding his voice, and his contributions to practical distributed database discussions are pretty much without parallel. Just ignore the bluster and you'll learn something new from kyle every day, even if it's about his buttcheeks.

Re: Databases at 14.4Mhz

#77

Post by illumen »

Impressive.

However I think there's still plenty of room to grow.

320,000 concurrent sessions isn't that much by modern standards. You can get 12 million concurrent connections on one linux machine, and push 1gigabit of data.

Also, 167 megabytes per second (116B * 14.4 million) is not pushing the limits of what one machine can do. I've been able to process 680 megabytes per second of data into a custom video database, plus write it to disk on one 2010 machine. That's doing heavy processing at the same time on the video with plenty of CPU to spare.

PCIe over fibre can do many transactions messages per second. You can fit 2TB memory machines in 1U (and more).

Since this is a memory + eventually dump to disk database, I think there is still a lot of room to grow.

Re: Databases at 14.4Mhz

#79

Post by jedberg »

ansible wrote: post #73
jedberg wrote: post #67

Earlier quoted context omitted.

But then you might as well just use an RF of 3. You get all the benefits you listed above, plus more storage (5.7TB vs 4.5TB), and less configuration hassle. And greater horizontal scalability. And a RAID 5 will never be faster than a RAID 0 or a JBOD. :)

FDB has a substantial per-node license cost. It makes sense to beef up the hardware on individual nodes as much as possible first, then scale out to more nodes. https://foundationdb.com/pricing

It would be unfortunate if their pricing model drove poor architectural decisions, but in this case that doesn't apply.

I suggested getting more storage by using the same number of nodes differently.

Re: Databases at 14.4Mhz

#80

Post by jedberg »

jrallison wrote: post #69
jedberg wrote: post #62

Earlier quoted context omitted.

Why do you use RAID on your nodes if you have an RF==2?

A few reasons off the top of my head: 1) We're still interested in the nodes being as reliable as they can be. With RAID 5, we need two simultaneous disk failures to brick a node. With RAID 0 (to increase usable disk space), any of the 3 disks can brick the node. Even with 12 nodes and RF of 2, an order of magnitude more node failures would be more likely to disrupt our service. Perhaps this makes more sense in a lar…

I think you misinterpreted what I said. I explained it more clearly below. I suggested using the same 12 nodes but putting each one as a RAID 0, which would get you more reliability and more storage for the same cost. In your current config, two dead disks possibly bricks the system -- in the config I propose, you'd need four dead disks before anyone noticed.

What I'm suggesting is that you think of the cluster more holistically, since I assume your goal is a reliable cluster, not reliable nodes. As a nice bonus you get more "free" disk space.

Post reply on HN