[Zope] SQLSession vs FSSession for ultra-high scalability and speed.

[chas]

Thank you very much for the comprehensive and speedy reply, J.

>Let me give it a try (or just dump all of what I know).

Much more than I expected - and greatly appreciated. Thank you.

>First of all it looks like you are going to want ZEO. If you don't 
>know ZEO, get to know ZEO, it fits perfectly with what you want for 
>the frontline servers.

Wow, has it been released for public consumption yet ? 
(I've been out of the Zope-loop for a while unfortunately)
But yes, I had ZEO in mind for keeping the application 
logic on the frontline servers in sync.

>As for the database, MySQL is hands down the fastest, but certainly 
>not the most robust in terms of features. Oracle is great if you have 
>$10,000 and a full time DBA but PostgreSQL 7.0 is really your best 
>bet. You might also want to take the money you were going to spend on 
>the DB2 and put it right back into DB1 and house everything there. 
>Just get a beefy machine, RAID it up for redundancy and call it a day.

Will definitely be getting RAID for the application data.


>The other idea that I have been playing around with in terms of 
>redundancy is to build something into the Zope code for the ZSQL 
>Methods that can go into a "cached" mode if your database dies. I 
>have only begun to play with this, but in theory since, Zope can 
>cache all your common data that comes from SQL you could, in effect, 
>bring down the SQL database and have Zope continue to work with the 
>cached data. I think all that it would involve (and I am sure that I 
>am simplifying the hell out of this) is to have Zope know that the 
>SQL database is no longer there (look for an error) and just turn the 
>"Maximum time (seconds) to cache results" to unlimited until the 
>database was restored.
>
>Has anyone else thought about this or played with this idea?

I think in most cases, if the DB dies, it's game over until
it goes up again.


>Graham Chiu wrote:
>It may be the way I designed my site, but if the database serving
>SQLSessions had to be taken down for maintenance, my site became
>inaccessible.

Same would happen to my site. Rather than try to build around 
that, I think I'll try to keep the DB up instead - since I won't
have much functionality without sessions.

>Based upon this experience, I would therefore now prefer to use
>different database engines for the main database and for the session
>tables.  And since for sessions, all you really want is speed without
>any fancy SQL transactions, then MySQL for the session data seems an
>appropriate use.

Exactly what I was hoping - thank you for the confirmation :)



>Graham Chiu wrote:
>>
>>Steve Alexander wrote:
>>I seem to recall from the MySQL vs Postgres thread a while ago that
>>MySQL was fastest in mostly-reading situations, whereas Postgres was far
>>better when there is quite a lot of writing as well as reading.

Interesting. I would have thought that MySQL won in writes b/c it
doesn't have the transaction overhead. Then again, Postgres 7 seems
to have updated the ante a lot.

>>If this is true, the Postgres should be a better choice for a
>>session-data DBMS.
>
> For SQLSessions, you only write the session data once, and read multiple
> times.  So, that would suit MySQL ?

I guess it depends what you're doing with your session object.
We'll be changing the properties of the session object as the 
user traverses the site, so the session object will have to be
updated (ie. updated on the RDB).


Thank you all for your help. 

chas