i readed some nosql features at mysql and mariadb (a mysql trunk) they are starting some nosql/cache solutions, could be nice check it i know that oracle company is a 'problem'/'solution' to mysql open source version, check others trunks, mariadb is a nice trunk and is more 'opensource' with some interesting features the memcache + db solution is nice, but i think in futures a more unified solution will exists just wait or develop it =)
2012/5/22 Jakub Łopuszański <[email protected]>: > Well this is already deployed to a production system and works just great. > The reason this is faster is that in some situations you can not easily > shard a database as some queries would cross shards boundaries. Of course > this means that a regular DB will not scale unless you change your queries. > On the other hand a cache is easier to distribute/shard/scale. > It is also easier (and in fact I do that on production) to have a memcache > runing on each frontend machine (while this would be a strange idea to put > shards of database on frontends which are usually diskless). > Of course one could argue, that you should just avoid complicated queries > and shard everything, but even then, the cost of communicating over network > between a frontend and mysql backend can be larger than a cost of a single > multiget to a memcached (even if the network latency is similar, I believe > that network stack of memcahed is one of the fastest). > > In my particular example I have 6 frontend diskless machines, each running > apache2 and memached, and single database and single global memcached. Most > queries are resolved without any network communication at all, as they > result in local cache hit. > > I think that developers of mysql have no way (or incentive) to build as > powerfull cache into a database, as no single database has not as much RAM, > not as many network cards and not as many CPUs as a cloud of 55 memcaches > used in nk.pl > > > W dniu piątek, 11 maja 2012 19:57:58 UTC+2 użytkownik Perrin Harkins > napisał: >> >> On Fri, Apr 27, 2012 at 6:14 PM, Jakub Łopuszański <[email protected]> >> wrote: >> > Hi, I'd like to share with you an algorithm for cache invalidation that >> > I've >> > came up with, and successfully implemented in a real world application. >> >> This may be a silly question, but have you benchmarked your cached >> application against just going straight to the database? I've always >> had the impression that keeping a perfect cache of a database that >> beats it in performance was not possible because the overhead of cache >> invalidation (both in the cache and in the application) would ruin the >> performance gains on reads. Caches usually beat database performance >> by sacrificing accuracy (e.g. allowing race conditions and non-ACID >> behavior) and freshness of data. >> >> To put it another way, if it was possible to have an up-to-date cache >> that outperforms an RDBMS with the same data, wouldn't the makers of >> that RDBMS simply build that cache into their product? >> >> - Perrin -- Roberto Spadim Spadim Technology / SPAEmpresarial
