[Sato]

Not really.

Consider their scenario. 100,000 db operations and 50,000 updates per sec. In this case, simple cache costs more than without. Eviction is expensive.

Also, it's no surprise replication doesn't scale because Updates get propagated.

Not sure details, but they succeeded to relax the tight requirements of ACID transactions. So this is a good case when RDBMS(or traditional database) fails.

I guess their design is more like MMO, hope to hear from the guy.

[tyler]

No. Memcached on a reasonable server will do millions of requests per second. 50,000 updates per second is nothing for any modern cache.

Also, replication has nothing to do with whether or not "without a cache" is a meaningful statement. The point is that by holding their entire data set in RAM, they've nullified the need for a cache. Effectively, their database is their cache.

And considering the data isn't even written to disk for about 15 minutes, it's really more cache than database anyway.

[Sato]

"with no cache" means no cache in app server layer. I guessed that's how the guy uses the words "no cache".

Getting rid of cache out of app server layer has great benefit on a cloud. 

Having cache in app server layer needs synchronizations to keep data consistent. Scale out design was made before cloud era, when we have our own dedicated system on our site. LAN can afford expensive sync communications, but on a cloud?

Still makes sense if a scenario is read intensive.  But when update intensive?

That's why I see this interesting. Increasing memory is a cheap option on a cloud. So it's great if it scales by letting database utilize more memory. 

[jrirei]

You are right: "no cache" means no cache in the app layer, so no eviction logic and inconsistencies between an app-layer-cache and a database. And yes the best thing a cloud can offer is lots and lots of memory. That's where it's good. And I/O (disk & network) is where it's weak.

[Sato]

Thanks for jumping in, jrirei!