http://localhost:1313/tags/storage/ Recent content in Storage on UberMongoose Hugo en-us Sun, 15 Dec 2013 07:20:02 +0530 http://localhost:1313/post/pessimistic-vs-optimistic-concurrency/ Sun, 15 Dec 2013 07:20:02 +0530 http://localhost:1313/post/pessimistic-vs-optimistic-concurrency/ <p>Concurrency is when multiple jobs see incremental progress within the same time period. It may be that the concurrency is parallel where both jobs progress together at the same time or time sliced wherein parts of both jobs are done one after the other by a single processor. Whichever the case concurrency creates problems for shared resources. When there is only one job executing at a given point in time the resource can be viewed as consistent on any access. However when there is more than one job executing then care must be taken to ensure that the resource is consistent across both jobs. Consider the classic example of 2 jobs which both increment a single counter.</p> http://localhost:1313/post/redis-vs-azure/ Sat, 12 Oct 2013 09:32:22 +0530 http://localhost:1313/post/redis-vs-azure/ <p><img src="http://localhost:1313/images/azure-vs-redis.png" alt=""></p> <p>Redis and Azure table storage have a lot in common. Both have no schema’s enforced on the objects that they store. Both have limited complex query capabilities and both are touted as being “post SQL” storage. However there is one major difference between the two that tends to dampen comparisons and that is how they deal with concurrency.</p> <p>Redis deals with concurrency by queuing requests and handling them one at a time. This allows for single instance Redis servers to deliver impressive performance and a bunch of nice features like set intersections and unions. On the down side this limits the scalability of a single Redis instance because you are stuck with just 1 thread doing the actual work.</p>