Your data fits in RAM • Hacker News Board

Re: Your data fits in RAM

#121

Post by joelwilliamson » Thu, May 21, 2015, 1:36 PM UTC

e12e wrote: post #69

FooBarWidget wrote: post #19

Earlier quoted context omitted.

Complexity, sure. But cost? I thought a single 1 TB RAM server is more expensive than 10x 100 GB RAM servers. And many people don't want to deal with physical hardware. Dealing with physical hardware increases operational complexity too. They want to rent a virtual/cloud server. Which provider allows you to rent a virtual server with 1 TB RAM?

I took a look around for "high-ram" servers, and it seems one I can buy today, is HP ProLiant DL580 Gen9. With just 256 GB of ram, it clocks in at 540.995,- NOK (71.5k USD). It has 96 ram slots, and I can't seem to find anything bigger than 32 GB DDR4 RAM, and rounding the price up 96x32GB comes to roughly 672.000,- NOK (~90k USD). Adding that up (throwing away the puny ram installed), gets us to a little over double…

Dell sells servers with 96x64GB RAM. There is a huge (7x) premium for the 64GB DIMMs instead of 32GB, so it runs around 500k, with almost the entire price going to RAM.

Re: Your data fits in RAM

#122

Post by br0s » Thu, May 21, 2015, 1:37 PM UTC

And if your data doesn't fit into the RAM of a single machine you can buy a few more and use vSMP (http://www.scalemp.com/) to create a shared memory single system image.

Re: Your data fits in RAM

#123

Post by lukegb » Thu, May 21, 2015, 1:38 PM UTC

polite_wine wrote: post #111

Sorry for the simple question but if you store it in ram what is the strategy for when the server is turned off?

The idea is more that when you process data, if you can fit it all in memory (and you don't need lots of CPU power, etc, etc, etc) then just use one machine and don't worry about "clusterising" it.

If you're expecting growth in the size of your dataset (beyond growth in RAM size availability), then, well, maybe don't just use a single machine. Same goes for a whole bunch of similar "it's too large for a single machine" considerations.

Storing data should probably still be persisted to disk, and backed up.

Re: Your data fits in RAM

#124

Post by jules » Thu, May 21, 2015, 1:38 PM UTC

brianwawok wrote: post #95

falcolas wrote: post #72

Earlier quoted context omitted.

Amazon offers some bloody huge servers... 32 core, 256GB RAM, and 48TB HDD space. d2.8x large

That is 4k a MONTH for 256gb of ram. If you could do the same job on a fleet of 8-16GB servers.. you can get a lot more CPU for a lot less dollars. Depends if you really need everything on 1 machine or not (as of course nothing will beat same machine in memory locality)

Not true, 8x16GB costs as much as 1x256 on Amazon. The issue here is that Amazon is hilariously expensive in general. Hetzner will rent you a 256GB server for €460 per month. Or you can buy one from Dell for $5000. These are not high numbers, in 1990 you paid more than that for a "cheap" home computer. For the price of a floppy drive back then you can now get a 32GB server.

Re: Your data fits in RAM

#125

Post by TorKlingberg » Thu, May 21, 2015, 1:39 PM UTC

dredmorbius wrote: post #105

baldfat wrote: post #55

Earlier quoted context omitted.

> 0. Spreadsheet is all you need. I HATE when people use Spreadsheets to do anything besides simple math. http://lemire.me/blog/archives/2014/05/23/you-shouldnt-use-a... TL:DR your work is not reproducible and we can't see what you did to get to your numbers. A million examples of why this is bad. Also > 1. Python script is good enough You mean Python with pandas and numpy? I use R which is also a great choice > 2. J…

Sadly, I recall those arguments against spreadsheet computation being made in the early 1990s. People simply won't learn. Ray Panko, University of Hawaii. http://panko.shidler.hawaii.edu/SSR/ http://panko.shidler.hawaii.edu/SSR/ Goes back to 1993: http://panko.shidler.hawaii.edu/SSR/auditexp.htm

There is even a European Spreadsheet Risks Interest Group: http://www.eusprig.org/

Re: Your data fits in RAM

#126

Post by swalsh » Thu, May 21, 2015, 1:42 PM UTC

This is good marketing, but you know what would be even better marketing? Give me access to that server for a week. Let me setup a demo of my biggest customer, and then run my tasks. We've started (and are in progress) of investing thousands of dollars in moving to Azure. A server this large is not something I can buy, and experiment on easily. Hard numbers would convince my superiors that its a better solution, but they're not going to give me $10k to do the experiment.

Re: Your data fits in RAM

#127

Post by Retric » Thu, May 21, 2015, 1:43 PM UTC

cornellphds wrote: post #51

Smerity wrote: post #36

It's probably worth extending "Your data fits in RAM" to "Your data doesn't fit in RAM, but it does fit on an SSD". So many problems will still work with quite reasonable performance when using an SSD instead. By using a single machine with an array of SSDs, you also avoid the complexity and overhead of distributed systems. My favourite realization of this: Frank McSherry shows how simplicity and a few optimisations…

This is classic case of "Algorithm/Problem Selection" if your algorithm/problem is tailored to a task such as PageRank, surely a single threaded highly optimized code will beat a cluster designed for ETL tasks. In real organizations where there are multiple workflows/algorithms, distributed systems always win out. Systems like Hadoop take care of Administration, Redundancy, Monitoring and Scheduling in a manner that…

Some things take 1 second on 1 machine beefy machine or 6 hours on a cluster due to latency issues. And yes I do mean 20,000 times slower, though 2,000 is far more common due to latency inside a datacenter being around ~500,000 ns vs ~100 ns for main memory vs 0.5 nm from L1 cache.

PS: Not that most systems are built around these kinds of edge cases, but 'just use a cluster' is often not a good option unless each node is sufficiently beefy.

Re: Your data fits in RAM

#128

Post by jacquesm » Thu, May 21, 2015, 1:46 PM UTC

vidarh wrote: post #85

acqq wrote: post #64

Earlier quoted context omitted.

Ditto for computationally intensive work: if it is CPU dominated, more CPU's calculating in parallel will be of advantage, even if the data could fit some RAM. There's no a single simple answer, but sure, whenever less computers are enough, less should be used. The recent problem is, some people love "clouds" so much today that they push there the work that could really be done locally.

Part of the problem is that a lot of problems that are CPU dominated on a single system becomes IO dominated once you start distributing it at very low node counts without very careful attention to detail.

Re: Your data fits in RAM

#129

Post by 3pt14159 » Thu, May 21, 2015, 1:49 PM UTC

polite_wine wrote: post #111

Sorry for the simple question but if you store it in ram what is the strategy for when the server is turned off?

There are multiple strategies that are usually handled by the database that you use. For some databases a hard power off will lose the uncommitted data, for more durable ones it waits until the write is confirmed.

Generally though, these posts are geared towards machine learning people that don't really have "live" data as frequently.

Re: Your data fits in RAM

#130

Post by jacquesm » Thu, May 21, 2015, 1:51 PM UTC

swalsh wrote: post #126

This is good marketing, but you know what would be even better marketing? Give me access to that server for a week. Let me setup a demo of my biggest customer, and then run my tasks. We've started (and are in progress) of investing thousands of dollars in moving to Azure. A server this large is not something I can buy, and experiment on easily. Hard numbers would convince my superiors that its a better solution, but…

That's how accidents are made. If you can't spend a small fraction of the budget for the solution to experimentally verify that it is in fact the optimum solution you may very well be leading the company down a road that will cost them significantly more. It's not up to the writer of the article to provide you with the tools to run your least-cost-analysis, that's up to you and your bosses! (After all, you're the beneficiaries.)