Mysql mem-tables vs. memcached

Could someone please elaborate on the technical differences and
impact of whether choosing memory-based tables in MySQL or using

I got this far on my own:
It seems that MySQL uses the NDB engine for transaction-safe memory
in a cluster. the memory storage engine seems to be faster but not
synchronizable by any means in a cluster. memcached seems to be
but requires extra effort in your code.

Who got experience on that?

Best regards

You can use pure ruby memory structure like hash or array and access
them via drb server.
it use lot off memory (but that cheap) and you have good performance,
and pure ruby object, no sql needed (like memcache).
If you have complex processing you can do that in the drb server unlike
with memcached, u dont touch the database, and its quite
fast for processing, but you depend on drb. if u need load balancing and
fail over, you can write a pool to do that .

Pete wrote:

but requires extra effort in your code.

“Ce message et toutes les pièces jointes sont des informations
strictement confidentielles et réservées au(x) destinataire(s). Ce
courriel n’a pas de valeur contractuelle et son contenu ne constitue ni
une acceptation, ni un engagement de la part de l’auteur et des sociétés
du groupe Serveur et Artprice, sauf dans le cas où cela aurait été prévu
avec le destinataire par un accord écrit. Le contenu de ce message et
les pièces jointes ne peuvent constituer une preuve au sens de l’article
1316-1 du Code Civil. L.auteur et les sociétés du groupe Serveur et
Artprice déclinent toute responsabilité au titre de ce courriel s’il a
été altéré, déformé, falsifié ou indûment utilisé par des tiers ou
encore s’il a causé tout dommage ou perte de toute nature. Si vous
n’êtes pas le bon destinataire, merci de nous contacter et de ne pas le

“This message including any attachments are confidential and privileged
material intended solely for the addressees. Its contents do not
constitute a commitment by groupe Serveur sas and Artprice SA, except
when provided for in a written agreement with the addressees. The
contents of this message cannot constitute neither the proof nor the
acceptance of any agreement as per article 1316-1 of the French civil
Groupe Serveur sas and Artprice SA shall not be rendered liable in any
manner whatsoever for the delay and/or loss in transit of this message,
for corruption, alteration, falsification, misuse or fraudulent use
(which may be made) of this message. If you receive this message in
error, please delete it and immediately notify the sender. If the reader
of this message is not the intended recipient, you are hereby notified
that any unauthorized use, copying or dissemination is prohibited.”

Pete wrote:

but requires extra effort in your code.

Who got experience on that?


mysql memory tables aren’t likely to lose data.

Memcache WILL lose data. It’s a cache, that’s what it does. memcache’s
purpose is to store a copy of frequently used data for fast access.
Don’t store anything that you don’t want to lose in memcache.


mySQL memory tables hold the information until the connection is
closed or the table is dropped. These are useful if you have a large
process and want to use a stored procedure to move/update data to keep
the network traffic low.

memCache was created as a proxy to the database for performance
reasons. Its to fill requests that would normally go to a database.
So, if every request on your website requires a row from the ‘members’
table it would be smart to cache that with memCache.

Why not just use in memory tables and forget memCache altogether?
Because when a site has so much traffic, like livejournal, and you
only have 1 database server to perform the transactions you need to
have a minimum number of requests to that server.

Plus, memCache is optimized for exactly this purpose, there is
probably less de/serializing work that has to occur than if you were
to use a database.