On Mon, Nov 29, 2010 at 5:17 PM, Chris Withers <ch...@simplistix.co.uk> wrote:
> On 26/10/2010 11:27, Shane Hathaway wrote:
>> On 10/26/2010 04:04 AM, Anton Stonor wrote:
>>> In order to scale an application using RelStorage I was thinking about
>>> seperating reads and writes accross databases. Writes would go to a
>>> Mysql master and the app would read from one or more Mysql slaves.
>> If you mean that you intend to set up some clients to write to a master
>> database, while other clients only read from asynchronous replicas, then
>> yes, you'll be in good shape. You should be able to get amazing
>> scalability that way.
> Wouldn't this require zero replication lag?
> Even if the read replicas had only a second or two delay (or spike
> delays caused by large writes?), would there not potentially be quite
> serious problems?
What I think shane meant was to have clients that only read data (eg
anonymous users) so they can read old data without causing problems
and clients that edit content use the primary database.
Seems to be a bad way to improve performance, the only advantage I
would see from using cache is if you somehow have logged in users that
don't edit data and have most/all of the pages dependent on the logged
user, for example a forum.
For more information about ZODB, see the ZODB Wiki:
ZODB-Dev mailing list - ZODB-Dev@zope.org