Large caches ...
pavel.francirek at firma.seznam.cz
Mon Jul 4 02:02:30 PDT 2005
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
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.
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:
> 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,
More information about the memcached