Comments on: memcached and the client: Database UDFs http://blog.northscale.com/northscale-blog/2009/11/memcached-and-the-client-database-udfs.html Insights and opinions on NoSQL, membase, and memcached Tue, 07 Sep 2010 23:43:47 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: NorthScale’s Memcached Data Management Technology Attracts Zynga And Others | Startup Websites http://blog.northscale.com/northscale-blog/2009/11/memcached-and-the-client-database-udfs.html/comment-page-1#comment-4 NorthScale’s Memcached Data Management Technology Attracts Zynga And Others | Startup Websites Wed, 17 Mar 2010 09:18:28 +0000 http://blog.stage.rs.northscale.com.php5-8.dfw1-2.websitetestlink.com/northscale-blog/2009/11/memcached-and-the-client-database-udfs.html#comment-4 [...] memcached and the client: Database UDFs – NorthScale Blog [...] [...] memcached and the client: Database UDFs – NorthScale Blog [...]

]]> By: Matt Ingenthron http://blog.northscale.com/northscale-blog/2009/11/memcached-and-the-client-database-udfs.html/comment-page-1#comment-15 Matt Ingenthron Thu, 26 Nov 2009 04:47:20 +0000 http://blog.stage.rs.northscale.com.php5-8.dfw1-2.websitetestlink.com/northscale-blog/2009/11/memcached-and-the-client-database-udfs.html#comment-15 I understand what you mean about the DB being over worked, but if you're using a cache you're already lessening that MVCC overhead for all of the selects by servicing those requests from the distributed cache. The only "extra work" usually in play with the UDF is that related to modifying data.<br><br>Yes, handling it all from the application is an excellent approach and write-through caches can be nice (with some advantages and disadvantages). Sometimes it's hard to teach all of the components of an app the new tricks though, so having the DB capabilities too sure can help.<br><br>Besides, that blog doesn't describe everything one may do with Database UDFs. I understand what you mean about the DB being over worked, but if you're using a cache you're already lessening that MVCC overhead for all of the selects by servicing those requests from the distributed cache. The only “extra work” usually in play with the UDF is that related to modifying data.

Yes, handling it all from the application is an excellent approach and write-through caches can be nice (with some advantages and disadvantages). Sometimes it's hard to teach all of the components of an app the new tricks though, so having the DB capabilities too sure can help.

Besides, that blog doesn't describe everything one may do with Database UDFs.

]]> By: Ashwin Jayaprakash http://blog.northscale.com/northscale-blog/2009/11/memcached-and-the-client-database-udfs.html/comment-page-1#comment-16 Ashwin Jayaprakash Thu, 26 Nov 2009 00:33:44 +0000 http://blog.stage.rs.northscale.com.php5-8.dfw1-2.websitetestlink.com/northscale-blog/2009/11/memcached-and-the-client-database-udfs.html#comment-16 Letting the Database update the Cache seems like a bad idea. The DB is already overworked in most cases which is why there is a Cache. Also, the DB sometimes does not even have access to the Application+Cache network.<br><br>Why not delete have a Write-through Cache that is always updated/deleted first and then let the cache update the DB? Or perhaps do both from the client itself? Letting the Database update the Cache seems like a bad idea. The DB is already overworked in most cases which is why there is a Cache. Also, the DB sometimes does not even have access to the Application+Cache network.

Why not delete have a Write-through Cache that is always updated/deleted first and then let the cache update the DB? Or perhaps do both from the client itself?

]]>