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

61–70 of 74 posts

Re: RAM Is the New Disk

#61

Post by Const-me »

sumanthvepa wrote: post #16

The problem with asking a programmer to keep track of the locality of their data, is that most modern programming languages make reasoning about locality hard to do. With the exception of C and C++. Even for those languages, unless all relevant data is in simple arrays, making assertions about locality is hard. For interpreted languages like Python or Javascript, figuring out RAM storage and access patterns of data i…

> Even for those languages, unless all relevant data is in simple arrays, making assertions about locality is hard.

It depends on the libraries you use. Take a look: https://github.com/Const-me/CollectionMicrobench

As you see, in practice, a good linked list is same or slightly faster than std::vector. And it’s consistently 2-3 times faster than equally linked std::list.

That’s not just synthetic tests. Recently, I’ve got 2.5x performance improvement in my app just by switching from std::unordered_map to CAtlMap with the same keys/values.

Theoretically, C++/11 fixes that with stateful allocators. Practically, I’ve not seen good open source ones with the performance comparable to CAtlPlex that powers these ATL node-based collections. I’m not even sure it’s possible. STL is too standardized and too old. It might be there’s no room in its allocators API for sufficient level of integration between a collection and it’s backing stateful allocator.

Re: RAM Is the New Disk

#62

Post by icebraining »

amelius wrote: post #58

If only programming languages supported "offsetted pointers", we could use mmapped files and store arbitrary data structures in them without hassle.

Many programming languages use references to other objects liberally. Wouldn't it be hard to keep it all contained so that you could restore it later?

Re: RAM Is the New Disk

#63

Post by fundabulousrIII »

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…

Every network access to disk based storage that can't be cached|copied to the your ram filesystem for the lifetime of your container is a performance hit and you can't scale with RAM backed storage without more phys memory. As a matter of fact when you run out of RAM in your (maybe incomplete) scenario you no longer have a working node. Zero sum.

DRBD is fine (used it for years) but it's not something that is one size fits all.

Re: RAM Is the New Disk

#64

Post by icebraining »

jlebrech wrote: post #50

with "serverless" applications you can read the whole app into memory and run it and then clear it for the next app, which i'm sure speeds things up.

That's not how it works; programs are kept "warm" for some time after each requests, or indefinitely (e.g. in App Engine you can choose dynamic or resident instances).

Re: RAM Is the New Disk

#65

Post by contingencies »

fundabulousrIII wrote: post #63
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…

Every network access to disk based storage that can't be cached|copied to the your ram filesystem for the lifetime of your container is a performance hit and you can't scale with RAM backed storage without more phys memory. As a matter of fact when you run out of RAM in your (maybe incomplete) scenario you no longer have a working node. Zero sum. DRBD is fine (used it for years) but it's not something that is one siz…

Every network access to disk based storage...

Rare for most services. Stuff like logs can be shuffled off elsewhere for a write, requiring no commit validation. Only DB/fileservers really require permanent storage with commit validation, writes are typically rare, and 100Gbps+ LAN on a PXE-based diskless cluster is not going to be introducing massive latency, especially if you prioritize the VLAN or link multiple ports. Reads are typically cheap and cacheable.

that can't be cached|copied to the your ram filesystem for the lifetime of your container

IMHO most services and their dependencies will come in well under 512MB, so that's a non-issue.

you can't scale with RAM backed storage without more phys memory

By definition, one could say the same about anything... although to be fair you could still scale via compression, sharding, or another established strategy.

when you run out of RAM...

In a managed scenario a service container or VM would terminate or a significant degradation in response time would be detected, it would be taken out of the service pool and stop having traffic routed to it, be restarted, then be re-introduced to the pool. Ditto extra CPU load, broken network policies, anomalous block IO, etc. Leaving modern service-level architecture aside, basic heartbeat-style IP monitoring with reliable node-level failover has existed in open source since the 90s. There's really no excuse to wing this stuff on production systems today.

it's not something that is one size fits all

Nothing fits all!

Re: RAM Is the New Disk

#66

Post by fundabulousrIII »

contingencies wrote: post #65
fundabulousrIII wrote: post #63

Earlier quoted context omitted.

Every network access to disk based storage that can't be cached|copied to the your ram filesystem for the lifetime of your container is a performance hit and you can't scale with RAM backed storage without more phys memory. As a matter of fact when you run out of RAM in your (maybe incomplete) scenario you no longer have a working node. Zero sum. DRBD is fine (used it for years) but it's not something that is one siz…

Every network access to disk based storage... Rare for most services. Stuff like logs can be shuffled off elsewhere for a write, requiring no commit validation. Only DB/fileservers really require permanent storage with commit validation, writes are typically rare, and 100Gbps+ LAN on a PXE-based diskless cluster is not going to be introducing massive latency, especially if you prioritize the VLAN or link multiple por…

I find your production model very attractive and your assumptions about other usage(s) persuasive. You must be an expert!

Re: RAM Is the New Disk

#67

Post by manigandham »

AndyNemmity wrote: post #48
manigandham wrote: post #47

Earlier quoted context omitted.

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.

> by the default isn't ACID compliant

What do you mean?

Re: RAM Is the New Disk

#68

Post by arielweisberg »

FractalNerve wrote: post #53
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…

Given a time-series history of DRAM/SSD prices, by "what value" do you need to be able to buy 1TB RAM (or anything approaching RAM speeds) in order to make VoltDB and in-Memory Databases competitively advantageous? So, given this insider knowledge of yours, can we make a prediction by what date predicively DRAM/SSD-NVMe prices may make in-Memory Database Startups lucrative again? -- Offtopic: I feel empathy for you,…

So what happened that isn't shown in most analysis of RAM costs is that RAM didn't go down in cost that much for many people. For instance RAM in the cloud is still very expensive.

What is also not shown is that cold data is everywhere. You need to have it, but paying to put it in RAM generates zero value for a profit seeking business. So if you don't page out cold data you effectively throw yourself out of the running for a huge swath of use cases.

For a small deployment sure it's dwarfed by engineering costs. But infrastructure per engineering head count is trending towards more infrastructure per head and infrastructure cost matters to more businesses.

The other thing is that data volumes are also increasing at a rate competitive with RAM is decreasing in price. This is because there are new opportunities to make money using more data and this is a trend you can't really beat. The more data you can have the more use cases and lines of business get invented.

This is not a scientific analysis it's just conjecture based on anecdata from my time in the industry.

Re: RAM Is the New Disk

#69

Post by majewsky »

ars wrote: post #54
FeepingCreature wrote: post #45

Earlier quoted context omitted.

One memory leak and your cache is gone. [edit] Not sure if ramdisks are pinned though.

> Not sure if ramdisks are pinned though. Ramdisks will go to swap. A memory leak will force the entire ramdisk into swap, and reading it back into memory afterward is 10 to 100 times slower than reading normal files off of a disk.

> Ramdisks will go to swap.

Assuming that you have swap. I don't; I want my SSD to stay alive.

Re: RAM Is the New Disk

#70

Post by mavhc »

majewsky wrote: post #69
ars wrote: post #54

Earlier quoted context omitted.

> Not sure if ramdisks are pinned though. Ramdisks will go to swap. A memory leak will force the entire ramdisk into swap, and reading it back into memory afterward is 10 to 100 times slower than reading normal files off of a disk.

> Ramdisks will go to swap. Assuming that you have swap. I don't; I want my SSD to stay alive.

Does anyone have actual data on swap on SSDs in 2017?
Post reply on HN