Hi Jim,

"The social networking sites are interesting -- very high volume with
a significant update load. The two that come to mind are Facebook
(uses massive MySQL read replication and memcached) and LinkedIn
(Oracle based). Both suffer from update propagation time, and both
are willing to do (and pay) for whatever it takes."

That makes your target more clear. For the benefit of other readers,
some details about LinkedIn are here:
http://hurvitz.org/blog/2008/06/linkedin-architecture
and some details about facebook are here:
http://highscalability.com/strategy-break-memcache-dog-pile
Facebook seems LAMP plus a huge memcached band-aid.

"I rather like the idea of associated a piece of data with a
connection request that can be hashed to a subset of servers in cloud
to establish a de facto node affinity to maximize cache efficiency.
Accomplishes the same thing as sharding without the programming
overhead (the data associated with connection request would be the
same data that identifies a shard)."

Yup, that is also the idea driving memcached.

"Beats me. I got my information from a former very senior technical
type almost a year ago. Maybe they've re-invented themselves since
then."

Nope, it was always like that. I think you might have been a victim
of some competitive disinformation.

"> RAC or WOO, that's the question.
I'm not talking about a single node database but a cloud. I don't
think there is any future for single node databases."

Huh? The RAC design pattern has proven to scale out to 50+ nodes...
how is that a single node database?

Some more thoughts tomorrow. BTW, nobody but us seems to be
interested in this discussion, so perhaps we should take it private
and not polute this newsgroup.

Paul