Large caches ...

Pavel Francirek pavel.francirek at firma.seznam.cz
Mon Jul 4 02:02:30 PDT 2005


Hello,

you haven't seen MySQL (if ever) for at least 5 years , have you? (See
InnoDB for example). It develops so fast that "classic" DB engine users
(developers) cannot imagine (sorry for offtopic, I know that it is their
problem :-))

But biggest disadvantage of MySQL cluster (as far as I know) is that
every node has to have memory for whole data. So in this case it would
by quite expensive.

Pavel

On Sat, 2005-07-02 at 21:25 +0200, Hans-Juergen Schoenig wrote:
> David Phillips wrote:
> 
> >On 7/2/05, Hans-Juergen Schoenig <familiar at cybertec.at> wrote:
> >  
> >
> >>We are planning to develop an application on top of a very large in
> >>memory database. Basically the size of the application will be around
> >>100 - 400 gb (in memory). We will need a quite large server farm to
> >>achieve that. The problem now is: What happens if a server fucks up?
> >>What can we do to make this work 24x7? Rebuilding the cache from scratch
> >>is not an option as it is too large :(.
> >>    
> >>
> >
> >You might try MySQL Cluster:
> >
> >http://www.mysql.com/products/cluster/
> >  
> >
> 
> 
> This is the worst crap I have ever seen :).
> Even considering MySQL as a database is somehow strange - to me it is a 
> pseudo-sql frontend to a flat file but not a database ;).
> 
>     best regards,
> 
>        hans
> 



More information about the memcached mailing list