Jump to content

Redis vs Memcache


n1concepts

Recommended Posts

Hi,

 

I have a situation where I need to develop code that:

 

1. can manage an constant and high amount of affiliate clicks and conversation stats (24/7).

 

Currently, this setup is operating with PHP (frontend) and MySQL (data storage).

 

Results: quickly seeing lag time due to the constant queries, updates, and/or inserts (backend forth to the db).

Note: all of the queries are looking for same (unchanged info - actually, the info will NEVER change so perfect for caching).

----

 

My question:

Is this better suited for Redis - which can handle both READ/WRITE operations or Memcache - which only READ.

 

I know Redis is the answer but I'm wanting to hear from someone that works w/Redis to know the following:

 

1. is Redis realiable enough to not have t worry about lost data - i read where it's not 100% but Redis clusters could be implemented to shard data (is this a good idea)? Any insight and/or examples of affiliate or click scripts links to review appreciated.

 

Thx!

Edited by n1concepts
Link to comment
Share on other sites

you do know that mysql has a query cache? have you checked if it is turned on and has enough memory available?

 

also, your series of performance questions indicates you likely have an issued in your application logic that you need to fix before you can worry about caching, otherwise you are just putting bandaids on top of a problem.

Link to comment
Share on other sites

Hey mac_gyver,

 

Yeah, I'm aware of all of that but I don't think (still) you see what I'm getting at...

There is no reason to perform (repeat) queries for same info so the objective is to cache that info which is what I've read and confirmed from multiple authorities.

 

Managing this in MySQL is just not the most efficient way to do this....

 

The application logic is what I'm looking to do w/Redis as that data never changes and serving via Redis oppose to querying MySQL just make sense (not just from my conclusion) but from all the info I've gathered (including examples from Dig, Facebook, etc...)

 

My question - here - was to see if anyone had actually worked w/it in this matter - that's all.

As always: I appreciate your input (thx!)

Link to comment
Share on other sites

If the data never changes, then why the bit about READ/WRITE vs READ-ONLY (for that matter, why do you think memcache is read-only?) since never changing data would by definition only need to be read?

 

Second, if the queries and results never change, then the mysql query cache should be providing a good caching option already if configured.

 

Thirdly, since you cache would essentially be read-only, your question about lost data would not really be particularly relevant. If for some reason the cache did loose the data, just re-query the database and re-add it to the cache.

 

It seems like either there is more to this problem than you are making known, or you're trying to over-engineer a solution to a problem that either doesn't exist or has been incorrectly-diagnosed.

Link to comment
Share on other sites

It would take too long to explain everything and i feel the responses are filled with ego - not sure why.

I just wanted to hear from someone that had experience w/Redis..... :)

 

Disregard providing help.

I will figure ut out... Thx

Edited by n1concepts
Link to comment
Share on other sites

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.