Tag

redis Archives - AWS Managed Services by Anchor

Aug 14 2013
1

RedAnt & Michelle Bridges 12WBT.com showcase tonight at Port 80

By | Company News | No Comments

Anchor is currently working alongside technical agency RedAnt to build a scalable hosting environment for Michelle Bridges 12WBT, that scales to service spikes of up to 50x regular traffic volumes. To do this, Redis has been implemented. Ben Still, Director of leading Ruby on Rails development house RedAnt, will be presenting in conjunction with the Management of 12WBT on what has enabled the incredible success of Australis’s most popular weight loss website. A major part of the technical presentation will revolve around the utilisation of Redis to cope with the massive sign up spikes that occur every 12 weeks. Several Anchor representatives also will be attending tonight’s Port80 Sydney event. With already over 100 people attending, make sure you RSVP now so you don’t miss out!       

Read More
May 09 2013
4

Second strike with Lightning!

By | Technical | 2 Comments

We put Kyoto Cabinet under the gun recently as a means to improve Redis. The Anchor Propulsion/Internet Laboratory validated Kyoto Cabinet as “fresh”, but extended live testing has revealed sub-optimal behaviour in some situations. To recap, we used Kyoto Cabinet to give Redis near-realtime disk persistence with a greatly reduced memory footprint; we called this “NDS” and published the code. Dirty keys are flushed from memory periodically into Kyoto Cabinet’s backing store. This works fantastically most of the time, but we’ve discovered that some operations cause a massive blowout in the on-disk files. Kyoto Cabinet is a key-value store. When you update a value in Kyoto Cabinet it can be rewritten in-place, unless the new value is longer than the old one. In this case, Kyoto Cabinet makes a new…

Read More
Apr 04 2013
2

Redis Rethought: Exciting Extremes with Larger-Than-Memory Datasets

By | Technical | 2 Comments

In a recent post we talked about Redeye, a way to manage a cluster of Redis shards. Sharding is important for pure storage capacity, but also to manage availability and performance, seeing as Redis can be CPU bound in a suffuciently large environment. This time we’re tackling the other side of the equation, simply being able to hold all your data without dropping it. You’ll recall that Redis is purely an in-memory datastore. This makes it amazingly fast, but volatile. To get around this you can have persistence across restarts using RDB and AOF files. The catch is that you’re ultimately limited by the amount of RAM you have available – if you have 500gb of data to store then you need 500gb of RAM, either in a single server…

Read More
Mar 28 2013
1

Limitations of BDB under concurrent access

By | Technical | No Comments

Berkeley DB (BDB) isn’t exactly the most glamorous database engine around, but it’s surprisingly widely deployed and feature rich. It’s designed for embedded use, so you’ll tend to find it integrated into a lot of applications if you go looking. One of our internal development efforts is evaluating various key-value databases as a secondary store to Redis. Because it’s accessed via in-code API calls instead of the network protocols that everyone’s familiar with, access semantics are quite different. BDB supports multiple simultaneous readers and writers, but the circumstances under which this is safe weren’t immediately clear.

Read More
Mar 07 2013
1

Flying with Redeye

By | Technical | No Comments

Several months ago we talked about extending the functionality of Redis, the popular noSQL key-value datastore. Since then we’ve taken things a bit further and we think it’s worth sharing. The Customer needs to store a lot of data in Redis, a few hundred GB at last check, and growing. Redis’ single-threaded nature means it doesn’t scale vertically without bounds though, you can only process so many thousands of transactions per second before you burn up a whole CPU. The solution is to shard your data and scale out horizontally across more CPUs and more RAM, so those hundreds of GB now live on a cluster of about a dozen independent Redis instances. Shard boundaries can’t be easily adjusted, so we created a large number of shards initially and let…

Read More
Jul 27 2012
0

Extending Redis to scratch an itch

By | Technical | No Comments

Redis has become one of the most popular “noSQL” datastores in recent times, and for good reason. Customers love it because it’s fast and fills a niche, and we love it because it’s well behaved and easy to manage. In case you’re not familiar with Redis, it’s a key-value datastore (not a database in the classic sense). The entire dataset is always kept in memory, so it’s stupendously fast. Durability (saving the data to disk) is optional. Data in Redis is minimally structured; there’s a small set of data types, but there’s no schema as in a traditional relational database. Thanks to some peculiarities in the way Redis is implemented, it can offer atomic transactions that are difficult to achieve in normal database products. That’s not to say it’s perfect…

Read More