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
on 2005-12-16 10:28
on 2005-12-16 14:02
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."
on 2005-12-16 16:30
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
on 2005-12-16 17:48
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.