Tell me more ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 6 down vote favorite

I am in the process of implementing a small web application using memcached for caching objects and sql server for database persistence.

In all the projects I have done before I have done inserts/updates in the web thread itself. In this project I want to implement asynchronous inserts and updates. I will use memcached http://en.wikipedia.org/wiki/Memcached to capture changes and an external service (windows service) to persist the changes in db.

I understand premature performance tuning is evil but this is just a test project to learn memcached.

Has anybody done this before. What are the disadvantages of using this ?

share|improve this question
I would not have chosen memcache. It lacks some basic durability and consistency guarantees that are probably necessary for your use case (but are not necessary for its primary use cases). – Rein Henrichs Oct 28 '11 at 5:57
What are the other caching mechanism I can look into – NRS Oct 28 '11 at 6:13
You aren't using a cacheing mechanism at all. You're writing to memcache and then eventually persisting those changes using some service. That's not how cacheing works. – Rein Henrichs Oct 28 '11 at 17:14

2 Answers

up vote 1 down vote accepted

This approach greatly changes the ACID guarantees of your application. If your memcached server goes down, you lose all changes since your last database synch with no way of recovering them. Out of the box, memcached will throw out old values when it runs out of RAM. If your app is write-heavy, this could mean losing data between synchronization.

You can improve the chances of data making it into the database by adding redundancy to your memcached layer, but it still doesn't create a solution with the same guarantees as a relational database. This isn't always a disadvantage. Some NoSQL approaches are consciously trading ACID guarantees for performance and scalability. There's even some math behind it in Brewer's CAP Theorem.

Regardless, most non-ACID NoSQL solutions guarantee eventual consistency. That's something your current approach doesn't provide and most users won't live without. If you lose my order, enlightening blog post, or witty comment, I'll likely find a different software provider.

share|improve this answer
up vote 1 down vote

The disadvantage is that you're using distributed systems.

The advantage is that you're using distributed systems.

Knowing the strengths, weaknesses and potential gotchas with distributed systems is something that is key for anyone wanting to move into high traffic applications, whether they're web based or not. It changes the way that you think about your system architecture.

Using distributed systems will make your applications much more complex than they would be otherwise.

Are you building this small application as an excercise in understanding distributed systems? If not, I'd venture to say that you're hitting a nail with a sledgehammer and most likely signing yourself up for a ton of headaches that you would otherwise avoid.

share|improve this answer
I am building this application as an exercise to understand distributed system. I plan to migrate this to aws – NRS Oct 28 '11 at 3:39

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.