On 11 May 2005, at 23:35, PFC wrote:
>
>
>
>> However, memcached (and for us, pg_memcached) is an excellent way
>> to improve
>> horizontal scalability by taking disposable data (like session
>> information)
>> out of the database and putting it in protected RAM.
>>
>
> So, what is the advantage of such a system versus, say, a
> "sticky sessions" system where each session is assigned to ONE
> application server (not PHP then) which keeps it in RAM as native
> objects instead of serializing and deserializing it on each request ?
> I'd say the sticky sessions should perform a lot better, and if
> one machine dies, only the sessions on this one are lost.
> But of course you can't do it with PHP as you need an app
> server which can manage sessions. Potentially the savings are huge,
> though.
Theres no reason it couldn't be done with PHP to be fair as long as
you could ensure that the client was always routed back to the same
machines. Which has it's own set of issues entirely. I am not
entirely sure that memcached actually does serialize data when it's
comitted into memcached either, although I could be wrong, I have not
looked at the source. Certainly if you can ensure that a client
always goes back to the same machine you can simplify the whole thing
hugely. It's generally not that easy though, you need a proxy server
of some description capable of understanding the HTTP traffic and
maintaining a central session lookup table to redirect with. Which
isn't really solving the problem so much as moving it somewhere else.
Instead of needing huge memcached pools, you need hardcore
loadbalancers. Load Balancers tend to cost $$$$$ in comparison.
Distributed sticky sessions are a rather nice idea, I would like to
hear a way of implementing them cheaply (and on PHP) as well. I may
have to give that some thought in fact. Oh yeah, and load balancers
software often sucks in annoying (if not always important) ways.
> On Google, their distributed system spans a huge number of PCs
> and it has redundancy, ie. individual PC failure is a normal thing
> and is a part of the system, it is handled gracefully. I read a
> paper on this matter, it's pretty impressive. The google filesystem
> has nothing to do with databases though, it's more a massive data
> store / streaming storage.
>
Since when did Massive Data stores have nothing to do with DBs? Isn't
Oracle Cluster entirely based on forming an enormous scalable disk
array to store your DB on?
