# Mysql mem-tables vs. memcached

**URL:** <https://www.ruby-forum.com/t/mysql-mem-tables-vs-memcached/50437>\
**Category:** Rails\
**Created:** [December 16, 2005, 10:28am UTC](https://www.ruby-forum.com/t/mysql-mem-tables-vs-memcached/50437 "2005-12-16T10:28:09Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![pete](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/3ab097/32.png) [@pete](https://www.ruby-forum.com/u/pete)\
**Post date:** [December 16, 2005, 10:28am UTC](https://www.ruby-forum.com/t/mysql-mem-tables-vs-memcached/50437/1 "2005-12-16T10:28:09Z")

</div>

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

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

Who got experience on that?

Best regards  
Peter

---

<div class="post-metadata">

**Author:** ![pete](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/3ab097/32.png) [@pete](https://www.ruby-forum.com/u/pete)\
**Post date:** [December 16, 2005, 2:02pm UTC](https://www.ruby-forum.com/t/mysql-mem-tables-vs-memcached/50437/2 "2005-12-16T14:02:22Z")

</div>

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  
divulguer.”

“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  
code.  
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.”

---

<div class="post-metadata">

**Author:** ![pete](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/3ab097/32.png) [@pete](https://www.ruby-forum.com/u/pete)\
**Post date:** [December 16, 2005, 4:30pm UTC](https://www.ruby-forum.com/t/mysql-mem-tables-vs-memcached/50437/3 "2005-12-16T16:30:06Z")

</div>

Pete wrote:

> but requires extra effort in your code.
> 
> Who got experience on that?

Hi,

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.

Jason

---

<div class="post-metadata">

**Author:** ![pete](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/3ab097/32.png) [@pete](https://www.ruby-forum.com/u/pete)\
**Post date:** [December 16, 2005, 5:48pm UTC](https://www.ruby-forum.com/t/mysql-mem-tables-vs-memcached/50437/4 "2005-12-16T17:48:40Z")

</div>

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.
