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

Cache is the new RAM

blog.memsql.com

Post reply on HN
Print view View original

1–10 of 97 posts

Re: Cache is the new RAM

#3

Post by brendangregg »

Yes. Or as I've said: memory is the new disk. This is why PMCs (performance monitoring counters) are more important than ever, to provide observability for cache and memory analysis. (I'd like some PMCs made available in EC2. :)

Re: Cache is the new RAM

#4

Post by maerF0x0 »

Amazon doesnt expose much of these statistics (how fast of ram do i get with a M3.large or a c3.med etc) . Does this mean real performance is for those who own their servers?

Re: Cache is the new RAM

#5

Post by wmf »

maerF0x0 wrote: post #4

Amazon doesnt expose much of these statistics (how fast of ram do i get with a M3.large or a c3.med etc) . Does this mean real performance is for those who own their servers?

RAM performance is the same for VMs and bare metal. And the ~1.5x performance difference between different grades of DRAM (e.g. 1333 vs. 1600 vs. 2133 MHz) is negligible compared to the massive cache-RAM and RAM-flash gaps.

And speaking of cache, lstopo (from the hwloc package) does work correctly under EC2.

Re: Cache is the new RAM

#6

Post by lallysingh »

maerF0x0 wrote: post #4

Amazon doesnt expose much of these statistics (how fast of ram do i get with a M3.large or a c3.med etc) . Does this mean real performance is for those who own their servers?

It's easy enough to find out. Create an array of linked-list nodes, and have them point to each other randomly (hint: std::random_shuffle w/an array of indices). Write a routine that traverses the list N times. Time the routine for larger lists. You should see a jump as your list gets larger than each stage of cache.

Re: Cache is the new RAM

#7

Post by temuze »

The database I want still doesn't exist.

Here's what I want:

- Easy sharding, a la Elasticsearch. I want virtual shards that can be moved node to node and an easy to understand primary/replica shard system for write/reads. I want my DB nodes to find each other with an easy discovery system with plugins for AWS/Azure/Digital Ocean etc.

- Fucking SQL. I don't want to learn your stupid DSL. I want to give coworkers a SQL client a say "go! You already know how to use this!". If I want a new feature, then dammit, build on top of SQL the way PostgreSQL has. Odds are, regardless if its some JSON API or SQL, my language will have a client for it that will be superior than writing raw queries anyway.

- Easily pluggable data management systems. For example, if I do a lot of SUMs and I know I'm not doing writes very often, I want to use CStore. If I'm storing a bunch of strings, I want to able to index it anyway I please - maybe one index with Analyzer/Tokenizer X and another with Analyzer/Tokenizer Y - all in a nice inverted index. Good, I can make an autocomplete now. Oh, and sometimes I want a good ol' RDBMS.

- Reactive programming! It works well in the front end and it'd be amazing in the backend. For example, I want to make a materialized view that's the result of a query, but that gets updated as new rows get inserted or as the rows it uses gets updated. Let's call it a continuous view or something. Eventual consistency is fine. Clever continuous views can solve a lot of performance issues.

- I want to be able to choose if a table/db is always in memory or not. I don't care about individual rows - that sounds like someone else's problem.

- Easy pipelining - these continuous views mean that an insert can span a lot of jobs because one continuous view can be dependent on another. I want my database to manage all of this for me and I want to forget that Hadoop ever existed. I want to be able to give my database a bunch of nodes that are just for working jobs if need be. Maybe allow custom throttling for the updates of these "continuous views" so the queries don't get re-run every update if they're too frequent.

- While I'm at it, I want a pony, too. But I'd settle for this being open source instead.

There's a lot of possible directions for the DB world in the next decade. Me, I think the line between DBs and MapReduce/ETL/Pipelining is going to be blurred.

Re: Cache is the new RAM

#8

Post by lgeek »

wmf wrote: post #5
maerF0x0 wrote: post #4

Amazon doesnt expose much of these statistics (how fast of ram do i get with a M3.large or a c3.med etc) . Does this mean real performance is for those who own their servers?

RAM performance is the same for VMs and bare metal. And the ~1.5x performance difference between different grades of DRAM (e.g. 1333 vs. 1600 vs. 2133 MHz) is negligible compared to the massive cache-RAM and RAM-flash gaps. And speaking of cache, lstopo (from the hwloc package) does work correctly under EC2.

It may be the same in the sense that hypervisors don't explicitly limit it, but on a multicore host you're sharing memory bandwidth with the other guests, in the common(?) case when the host has more cores than a guest. You can also experience increased latency when there is access contention.

Re: Cache is the new RAM

#10

Post by Roboprog »

temuze wrote: post #7

The database I want still doesn't exist. Here's what I want: - Easy sharding, a la Elasticsearch. I want virtual shards that can be moved node to node and an easy to understand primary/replica shard system for write/reads. I want my DB nodes to find each other with an easy discovery system with plugins for AWS/Azure/Digital Ocean etc. - Fucking SQL. I don't want to learn your stupid DSL. I want to give coworkers a SQ…

Thank you. Doing a join on an SSD isn't as big a deal as on a spinning platter. Find the N regions of storage and pull 'em in. (replace tricky disk scheduling algos for simple FIFO or priority queue of requests)

Many of these denormalized "document" storage systems are likely to look like real legacy cluster-bombs in a few years.

Post reply on HN