1) You could serialize the Rowset->toArray() instead of the Rowset
object. But regardless, this solution works only if you always access
records by primary key, e.g. using the find() method. Otherwise, if you
query on some other expression, you'd need to fetch the result set
anyway before you can test if the rows in that result set are cached.
2) This seems good to me, I usually advise people to separate the
concept of their Model object from the implementation of a Zend_Db_Table
object. Your example shows that it's useful to write a Model class that
_uses_ a Zend_Db_Table object, but may also decide _not_ to do that if
it's already got the data it needs in cache.
3) Some databases have support for caching query result sets in memory.
You can increase the memory allocated to this. E.g. MySQL query cache
(http://dev.mysql.com/doc/refman/5.0/en/query-cache.html). The
advantage is that the RDBMS keeps track of when to bust the cache, e.g.
when any data operation occurs (from any client) that could affect the
query result. But it still requires a round-trip to the RDBMS to fetch
the result set, and you might find that using a local instance of
memached is quicker, depending on your system architecture.
Regards,
Bill Karwin
________________________________
From: Shawn Robinson [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 19, 2007 11:30 AM
To: fw-general@lists.zend.com
Subject: [fw-general] design decision for caching and databases
Hello,
I am building a site that needs to handle a lot of traffic
(thousand requests per second), so I want to have a high performance
system. I plan on using mysql as the backend store and memcache as the
caching layer. It looks like Zend_Db and Zend_Cache will be perfect for
this. There are some ways I am thinking of implementing it and was
wondering if anyone had best practices or an approach they really like.
Just to have an example to work with, say I have a library of books that
I want to allow users to browse. All the book information will be in a
mysql table and a class Book that will have functions like getTitle,
getAuthor, etc... The idea would be to check the memcache for the book
and if it exists use the information in the cache, if it doesn't exist
get it from the mysql database and then store it in memcache. If there
are any updates or new books, expire the cache.
Here are some approaches I was thinking....
1) Create a class Book that extends Zend_Db_Table_Abstract which
will allow easy access to the book table in the database. Then have a
Factory that I will ask for a book object. The factory will check the
memcache first to see if it exists and if so, then return the object
from the memcache (using serialization to store it). If it doesn't
exist, create a new instance of the Book object, store it in memcache
and then return it to the caller. The drawback with this approach is i
have found that serialize and unserialize is slow with objects
especially if they have a lot of member variables (remember, I need to
have this HIGHLY optimized).
2) Create a class Book that doesn't extend anything. In the
constructor, it will check the memcache to see if all the data is
populated already, like title, author, etc.. and if so, then do nothing.
If not, then make the sql queries to get the data and populate the
key/value pairs into memcache (instead of a big hash or object that has
to be serialized/unserialized). Whenever you call $book->getTitle(), it
will do a $cache->get( 'title' ). fyi - not exact syntax.
3) other?
Essentially, the idea is to have LOTS of memory to store LOTS of
books using memcache, so access is quick. Should I store the entire
book object in memory or just the data which the object can retrieve?
Thanks,
Shawn
