Comments on: Implementing efficient counters with MySQL http://www.mysqlperformanceblog.com/2007/07/01/implementing-efficient-counters-with-mysql/ Everything about MySQL Performance Sat, 21 Nov 2009 05:23:57 -0800 http://wordpress.org/?v=2.8.4 hourly 1 By: Hartym http://www.mysqlperformanceblog.com/2007/07/01/implementing-efficient-counters-with-mysql/comment-page-1/#comment-182983 Hartym Thu, 01 Nov 2007 10:24:10 +0000 http://www.mysqlperformanceblog.com/2007/07/01/implementing-efficient-counters-with-mysql/#comment-182983 Thanks for sharing, that's a very interesting post i'll use soon to optimise my pastebin. Thanks for sharing, that’s a very interesting post i’ll use soon to optimise my pastebin.

]]> By: Yet Another Blog » Blog Archive » Links - Mon Jul 16 2007 09:10AM http://www.mysqlperformanceblog.com/2007/07/01/implementing-efficient-counters-with-mysql/comment-page-1/#comment-145891 Yet Another Blog » Blog Archive » Links - Mon Jul 16 2007 09:10AM Mon, 16 Jul 2007 08:14:54 +0000 http://www.mysqlperformanceblog.com/2007/07/01/implementing-efficient-counters-with-mysql/#comment-145891 [...] Implementing efficient counters with MySQL [from MySQL Performance Blog] [...] [...] Implementing efficient counters with MySQL [from MySQL Performance Blog] [...]

]]> By: peter http://www.mysqlperformanceblog.com/2007/07/01/implementing-efficient-counters-with-mysql/comment-page-1/#comment-142942 peter Thu, 05 Jul 2007 18:32:04 +0000 http://www.mysqlperformanceblog.com/2007/07/01/implementing-efficient-counters-with-mysql/#comment-142942 Yep Sheeri, Insert delayed can be good but it can also be pretty nasty - because of this extra thread which gathers data overall performance can get worse than with standard insert. It can surely help however if you run into table lock issue, which can be avoided for log table easily. Yep Sheeri,

Insert delayed can be good but it can also be pretty nasty – because of this extra thread which gathers data overall performance can get worse than with standard insert.

It can surely help however if you run into table lock issue, which can be avoided for log table easily.

]]> By: Sheeri http://www.mysqlperformanceblog.com/2007/07/01/implementing-efficient-counters-with-mysql/comment-page-1/#comment-142936 Sheeri Thu, 05 Jul 2007 17:27:15 +0000 http://www.mysqlperformanceblog.com/2007/07/01/implementing-efficient-counters-with-mysql/#comment-142936 don't forget INSERT DELAYED -- that's a big win for batch inserting when you can approximate what "the count as of now" really is. don’t forget INSERT DELAYED — that’s a big win for batch inserting when you can approximate what “the count as of now” really is.

]]> By: sebcio http://www.mysqlperformanceblog.com/2007/07/01/implementing-efficient-counters-with-mysql/comment-page-1/#comment-142444 sebcio Tue, 03 Jul 2007 20:53:05 +0000 http://www.mysqlperformanceblog.com/2007/07/01/implementing-efficient-counters-with-mysql/#comment-142444 if your application is PHP you can use XCache and its API to provide nice counter. A small pseudo-code example could be found in its wiki: if (!xcache_isset("count")) { xcache_set("count", load_count_from_mysql()); } ?> This guest book has been visited times. if your application is PHP you can use XCache and its API to provide nice counter.
A small pseudo-code example could be found in its wiki:
if (!xcache_isset(”count”)) {
xcache_set(”count”, load_count_from_mysql());
}
?>
This guest book has been visited times.

]]> By: peter http://www.mysqlperformanceblog.com/2007/07/01/implementing-efficient-counters-with-mysql/comment-page-1/#comment-141982 peter Mon, 02 Jul 2007 15:53:30 +0000 http://www.mysqlperformanceblog.com/2007/07/01/implementing-efficient-counters-with-mysql/#comment-141982 guillaume, Sure. I kind of more viewed it for the single instance case more. But using another instance for this seems like a good idea especially to offload replication. As you do not show to many counters per page fetching them from another instance does not add a lot of overhead. And while counter is zero you do not need to store it so INSERT ON DUPLICATE KEY UPDATE can indeed be a lot of help. guillaume,

Sure. I kind of more viewed it for the single instance case more. But using another instance for this seems like a good idea especially to offload replication.

As you do not show to many counters per page fetching them from another instance does not add a lot of overhead.

And while counter is zero you do not need to store it so INSERT ON DUPLICATE KEY UPDATE can indeed be a lot of help.

]]> By: peter http://www.mysqlperformanceblog.com/2007/07/01/implementing-efficient-counters-with-mysql/comment-page-1/#comment-141980 peter Mon, 02 Jul 2007 15:50:10 +0000 http://www.mysqlperformanceblog.com/2007/07/01/implementing-efficient-counters-with-mysql/#comment-141980 Jay, Robin wrote that not me. I mentioned Archive as possible candidate for temporary log table. Jay, Robin wrote that not me.

I mentioned Archive as possible candidate for temporary log table.

]]> By: Jay Pipes http://www.mysqlperformanceblog.com/2007/07/01/implementing-efficient-counters-with-mysql/comment-page-1/#comment-141976 Jay Pipes Mon, 02 Jul 2007 15:12:22 +0000 http://www.mysqlperformanceblog.com/2007/07/01/implementing-efficient-counters-with-mysql/#comment-141976 Hi Peter! You wrote: "When implementing a ‘log’ table and a ‘counts’ table which is regenerated every so often it would be nice to have a ‘Constant DB’ (CDB, see: http://cr.yp.to/cdb.html) storage engine, wouldn’t it? It has limited features (write once, read many - no updates) but it provides fantastic read/write performance." What about ARCHIVE? No updates, good read and write performance... Cheers, and BTW, I 100% agree with everything you say in this article; I've been including this information in my slides for a while now. -jay Hi Peter!

You wrote: “When implementing a ‘log’ table and a ‘counts’ table which is regenerated every so often it would be nice to have a ‘Constant DB’ (CDB, see: http://cr.yp.to/cdb.html) storage engine, wouldn’t it? It has limited features (write once, read many – no updates) but it provides fantastic read/write performance.”

What about ARCHIVE? No updates, good read and write performance…

Cheers, and BTW, I 100% agree with everything you say in this article; I’ve been including this information in my slides for a while now.

-jay

]]> By: guillaume http://www.mysqlperformanceblog.com/2007/07/01/implementing-efficient-counters-with-mysql/comment-page-1/#comment-141965 guillaume Mon, 02 Jul 2007 14:27:27 +0000 http://www.mysqlperformanceblog.com/2007/07/01/implementing-efficient-counters-with-mysql/#comment-141965 The other idea is to use a dedicated database instance for view summaries. It works quite well. And after all you don't re-read the value every time. Just use ON DUPLICATE KEY UPDATE instead! The other idea is to use a dedicated database instance for view summaries. It works quite well. And after all you don’t re-read the value every time. Just use ON DUPLICATE KEY UPDATE instead!

]]> By: Robin http://www.mysqlperformanceblog.com/2007/07/01/implementing-efficient-counters-with-mysql/comment-page-1/#comment-141848 Robin Mon, 02 Jul 2007 09:31:32 +0000 http://www.mysqlperformanceblog.com/2007/07/01/implementing-efficient-counters-with-mysql/#comment-141848 Not really contributing to the discussion, but maybe someone gets inspired to write a new storage engine ;) : When implementing a 'log' table and a 'counts' table which is regenerated every so often it would be nice to have a 'Constant DB' (CDB, see: http://cr.yp.to/cdb.html) storage engine, wouldn't it? It has limited features (write once, read many - no updates) but it provides fantastic read/write performance. Shouldn't be too difficult to implement something like that as cdb's API is similar to bdb. Ofcourse update, replace & delete wouldn't be supported in such an engine, as it is 'constant'. Not really contributing to the discussion, but maybe someone gets inspired to write a new storage engine ;) : When implementing a ‘log’ table and a ‘counts’ table which is regenerated every so often it would be nice to have a ‘Constant DB’ (CDB, see: http://cr.yp.to/cdb.html) storage engine, wouldn’t it? It has limited features (write once, read many – no updates) but it provides fantastic read/write performance.
Shouldn’t be too difficult to implement something like that as cdb’s API is similar to bdb. Ofcourse update, replace & delete wouldn’t be supported in such an engine, as it is ‘constant’.

]]>