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

11–20 of 97 posts

Re: Cache is the new RAM

#11

Post by wmf »

lgeek wrote: post #8
wmf wrote: post #5

Earlier quoted context omitted.

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.

True, if you want full and predictable memory/cache performance you need to rent a full-machine VM (usually 8xlarge) or bare metal.

Re: Cache is the new RAM

#12

Post by lerchmo »

farresito wrote: post #2

I've always found very unfortunate that memsql is not open source. It looks very interesting. VoltDB seems to fill a similar niche. Has anyone tried both?

I have tried VoltDB, it's nice for scaling low latency data access (realtime bidding / adserving is one use case it shines)

Re: Cache is the new RAM

#13

Post by jandrewrogers »

A couple points I would make with respect to the article:

- In-memory databases offer few advantages over a disk-backed database with a properly designed I/O scheduler. In-memory databases are generally only faster if the disk-backed database uses mmap() for cache replacement or similarly terrible I/O scheduling. The big advantage of in-memory databases is that you avoid the enormously complicated implementation task of writing a good I/O scheduler and disk cache. For the user, there is little performance difference for a given workload on a given piece of server hardware.

- Data structure and algorithms have long existed for supercomputing applications that are very effective at exploiting cache and RAM locality. Most supercomputing applications are actually bottlenecked by memory bandwidth (not compute). Few databases do things this way -- it is a bit outside the evolutionary history of database internals -- because few database designers have experience optimizing for memory bandwidth. This is one of the reasons that some disk-backed databases like SpaceCurve have much higher throughput than in-memory databases: excellent I/O scheduling (no I/O bottlenecks) and memory bandwidth optimized internals (higher throughput of what is in cache).

The trend in database engines is highly pipelined execution paths within a single thread with almost no coordination or interactions between threads. If you look at codes that are designed to optimize memory bandwidth, this is the way they are designed. No context switching and virtually no shared data structures. Properly implemented, you can easily saturate both sides of a 10GbE NIC on a modest server simultaneously for many database workloads.

Re: Cache is the new RAM

#14

Post by temuze »

Roboprog wrote: post #10
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.

Well, so long as I'm spitballing my dreamDB's "continuous views", then why not have a concept of "foreign documents"? Let's define "foreign documents" as a type of field that is an exact copy of a document in a separate table. This field gets updated when the original document is updated.

This could apply to denormalization really well! For example: let's say you have a table called "items", a table called "customers" and a table called "sales". A sales document is just a item foreign document + a customer foreign document + a date.

The item foreign document is literally an exact a copy of a document in your items table that gets updated whenever the original gets updated. So if you change the customer information, the customer information in the corresponding "sales" documents get updated.

This is a terrible example because it's not a useful/practical use case, but maybe it could be useful if you have enough data where this join is unreasonable.

You can use the same architecture to update your continuous views as you do for your foreign documents. And add the same syntax with throttling and whatnot.

Re: Cache is the new RAM

#17

Post by hcarvalhoalves »

> It’s been 65 years since the invention of the integrated circuit, but we still have billions of these guys around, whirring and clicking and breaking. It’s only now that we are on the cusp of the switch to fully solid-state computing.

Am I missing something, or should it read "hard disk" rather than "integrated circuit" here?

Re: Cache is the new RAM

#18

Post by sp332 »

hcarvalhoalves wrote: post #17

> It’s been 65 years since the invention of the integrated circuit, but we still have billions of these guys around, whirring and clicking and breaking. It’s only now that we are on the cusp of the switch to fully solid-state computing. Am I missing something, or should it read "hard disk" rather than "integrated circuit" here?

"These guys" refers to the hard drive in the picture just above that paragraph. It means: even though integrated circuits are old, we're just getting around to solid-state storage.

Re: Cache is the new RAM

#19

Post by dsp1234 »

temuze wrote: post #14
Roboprog wrote: post #10

Earlier quoted context omitted.

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.

Well, so long as I'm spitballing my dreamDB's "continuous views", then why not have a concept of "foreign documents"? Let's define "foreign documents" as a type of field that is an exact copy of a document in a separate table. This field gets updated when the original document is updated. This could apply to denormalization really well! For example: let's say you have a table called "items", a table called "customers…

Something like this is available in postgres, mssql, etc and is called a "materialized view" [0]. In the postgres case, you have to update the materialized view manually, but in the mssql case, the updates are done automatically when the origin data is updated.

[0] - http://en.wikipedia.org/wiki/Materialized_view

Re: Cache is the new RAM

#20

Post by judah »

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…

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

RavenDB[0] gets a lot of this right for the .NET stack.

RavenDB creates something very much like your continuous view -- called indexes[1] in RavenDB -- for every query you've run against it. Any successive queries aren't really queries at all, but are results from a pre-computed set.

When new data is inserted, the index gets updated asynchronously, leaving you with eventual consistency for your queries.

Raven creates these indexes automatically when you query it. It then maintains these indexes: long periods without querying an index will relegate the index to idle (updates on low priority), and eventually abandoned (no longer updated). This way, your app hot path -- the queries most often used -- remain the fasts, alleviating a lot of performance issues.

[0]: http://ravendb.net [1]: http://ravendb.net/docs/article-page/3.0/Csharp/indexes/what...

Post reply on HN