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