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

RAM Is the New Disk

medium.com

Post reply on HN
Print view View original

41–50 of 74 posts

Re: RAM Is the New Disk

#41

Post by dis-sys »

zeusk wrote: post #29
vbezhenar wrote: post #24

May be with very high-end servers it is. But generally it's not. I can buy 4TB HDD For $200. I think, I'll have to add 2-3 zeros for 4TB RAM machine, and I'm not even saying only about RAM, I need some server motherboard, some server processor, while I can use 4TB RAM HDD with pretty much any computer. And SSD isn't going to be even with HDD in near future as well for $/Byte. So optimizing software for HDD won't go a…

NVMe drives which are approaching RAM speeds are a good compromise if RAM and server components are outside of your financial reach.

many NVMe drives on the market are useless jokes. try some from the now biggest semiconductor company, test their fsync() performance and don't get a heart attack for seeing those ugly numbers. ;)

Re: RAM Is the New Disk

#42

Post by 0xbear »

flukus wrote: post #33
0xbear wrote: post #12

And 99% of developers spend their entire careers without giving as much as a passing thought to cache locality. Quick, how long, in cycles, does it take to retrieve data from RAM? About 200 cycles. 200 cycles is a very long time if you miss cache often. Scattered RAM reads can be _slower_ than sustained linear disk reads (that is, once the disk actually gets around to reading, which takes a while).

90% of developers are working in languages where you can't really do much about cache misses, or doing so will at least involve some very non-idiomatic code. If you can't do much about the problem it's not really helpful to be thinking about it much.

I don't disagree. And for 90% of them worrying about cache locality or branch mispredictions on a daily basis would be a waste of time. It's fine to deliberately ignore such concerns. It's somewhat less fine to know absolutely nothing about how programs are actually executed, and what makes them go fast.

Re: RAM Is the New Disk

#43

Post by notpeter »

runeks wrote: post #30
tw04 wrote: post #11

The price of disk has dropped at nearly the same pace as ram. As has the cost of compute. At the same time data growth has increased faster than either has dropped... so I'm not really sure the price argument holds water. If I can buy ram at 1/100th the cost but I need to store 500x more data... that isn't a net win on cost. From ~$1000.00/gb to $0.03/gb http://www.mkomo.com/cost-per-gigabyte-update

It would be interesting to see that chart updated to 2017 data. It appears the downward slope becomes significantly less steep around 2009 (looks like the price dropped as much from 2006-2008 as it did in the five years 2009-2014), and I’d be interested in seeing how recent SSD prices affect this. As far as I can see, rotational HDD technology is at the end of its S-curve, whereas SSD technology is still relatively n…

Backblaze recently updated that data through Q2 2017 [1]. Hard drives have only dropped to $0.028/GB. For comparison SSDs are still ~$0.40/GB (~14x).

[1]: https://www.backblaze.com/blog/hard-drive-cost-per-gigabyte/

[2]: https://pcpartpicker.com/trends/internal-hard-drive/

Re: RAM Is the New Disk

#44

Post by old-gregg »

contingencies wrote: post #7

Well yes, I think RAM has been the new disk for awhile now, and not because (anecdote about database disk structures) or (any recent change to cost of RAM). If you use Linux, the fastest way to test how much faster your application is off disk is to simply make a filesystem in RAM, and run the whole thing from there. Because library-chasing to build a chroot is a hassle, I would recommend simply putting a container o…

I don't recommend this anymore. With a typical developer machine containing 16GB of RAM, and especially on Linux, you will that all of your daily-touched files are in FS cache after a few minutes of work. Even with default kernel settings Linux is pretty good with eating up all of your unused RAM for speeding up disk access.

Here's my anecdote based on 16GB workstation with NVMe SSD (Samsung 960 Pro):

Watching my project compile I occasionally open iotop in another terminal and don't see anything above occasional write flushes. To confirm, I did create a tmpfs volume and did not observe any improvement. `free` reported my buffers to be at ~4.7GB, which is basically all of my /bin, /usr and all of Golang sources+libs.

Re: RAM Is the New Disk

#45

Post by FeepingCreature »

old-gregg wrote: post #44
contingencies wrote: post #7

Well yes, I think RAM has been the new disk for awhile now, and not because (anecdote about database disk structures) or (any recent change to cost of RAM). If you use Linux, the fastest way to test how much faster your application is off disk is to simply make a filesystem in RAM, and run the whole thing from there. Because library-chasing to build a chroot is a hassle, I would recommend simply putting a container o…

I don't recommend this anymore. With a typical developer machine containing 16GB of RAM, and especially on Linux, you will that all of your daily-touched files are in FS cache after a few minutes of work. Even with default kernel settings Linux is pretty good with eating up all of your unused RAM for speeding up disk access. Here's my anecdote based on 16GB workstation with NVMe SSD (Samsung 960 Pro): Watching my pro…

One memory leak and your cache is gone.

[edit] Not sure if ramdisks are pinned though.

Re: RAM Is the New Disk

#46

Post by AndyNemmity »

ericfrenkiel wrote: post #38
arielweisberg wrote: post #5

... I was the third engineer at VoltDB and spent six years making that bet. It's not a good bet. Maybe there are other factors, but if VoltDB could page out cold data to disk I think it would be at least 2x if not more successful. No one agreed with me so it never happened. I saw so many use cases go out the door because hey you know what? RAM is expensive and it's cheaper to page out cold data. The scale where that…

Yes, it's why we at MemSQL added a column store on disk in 2014. Memory-only is too limiting and has evolved to a notion of "memory-first."

Really a sort of odd choice though. I'd have gone the other way around with column store in memory, and row store on disk.

Not that I think that's ideal either though, having both in memory for hot used data, and the rest on disk is ideal. With an extremely easy to use setup that makes it essentially automatic, but with rules engines for finer grained tuning.

Re: RAM Is the New Disk

#47

Post by manigandham »

AndyNemmity wrote: post #46
ericfrenkiel wrote: post #38

Earlier quoted context omitted.

Yes, it's why we at MemSQL added a column store on disk in 2014. Memory-only is too limiting and has evolved to a notion of "memory-first."

Really a sort of odd choice though. I'd have gone the other way around with column store in memory, and row store on disk. Not that I think that's ideal either though, having both in memory for hot used data, and the rest on disk is ideal. With an extremely easy to use setup that makes it essentially automatic, but with rules engines for finer grained tuning.

MemSQL actually adds an in-memory rowstore to each columnstore for rapid ingest of new rows until they get compacted into a new segment. Columnstore data is pretty fast so it works well off disk compared to row stores which aren't as efficient.

SQL Server similarly has the hekaton in-memory tables + columnstore indexes and the latest version allows combining both for in-memory columnstores.

Re: RAM Is the New Disk

#48

Post by AndyNemmity »

manigandham wrote: post #47
AndyNemmity wrote: post #46

Earlier quoted context omitted.

Really a sort of odd choice though. I'd have gone the other way around with column store in memory, and row store on disk. Not that I think that's ideal either though, having both in memory for hot used data, and the rest on disk is ideal. With an extremely easy to use setup that makes it essentially automatic, but with rules engines for finer grained tuning.

MemSQL actually adds an in-memory rowstore to each columnstore for rapid ingest of new rows until they get compacted into a new segment. Columnstore data is pretty fast so it works well off disk compared to row stores which aren't as efficient. SQL Server similarly has the hekaton in-memory tables + columnstore indexes and the latest version allows combining both for in-memory columnstores.

I've used MemSQL, and it's rapid ingest by the default isn't ACID compliant, so it sort of depends on how you compare it.

The results of the columnstore data was pretty fast, and it's even faster in memory. Depends on what you're doing, and what the requirements are.

Was really impressed by MemSQL, and loved the wire compatibility with mysql, so don't take this as just a knock on MemSQL in anyway.

Re: RAM Is the New Disk

#49

Post by Pamar »

AndyNemmity wrote: post #31
arielweisberg wrote: post #5

... I was the third engineer at VoltDB and spent six years making that bet. It's not a good bet. Maybe there are other factors, but if VoltDB could page out cold data to disk I think it would be at least 2x if not more successful. No one agreed with me so it never happened. I saw so many use cases go out the door because hey you know what? RAM is expensive and it's cheaper to page out cold data. The scale where that…

Have spent 6 years I think working on SAP HANA. The one feature I've always asked for is seamless paging of even warmish data to disk. In memory is fast and awesome, but it doesn't have to be as mind boggling expensive as it is. Why are we all making the same mistakes?

I would really like to hear something about your experience with SAP HANA. Do you have a blog or anything you could share?
Post reply on HN