Location, Location, Location. We all carry around devices that can provide our specific location from almost any place on earth. If we treat this location as data, it can be a powerful tool. Applications and solutions that are location aware are not necessarily new and are becoming more common every day. Uber, Tinder, and Expedia are just a few examples of applications that leverage location. How developers use a geographical location in their applications varies depending upon the use case. Elasticsearch, MongoDB, PostgresSQL, and MySQL all have support for geospatial indexing in some way. With more solutions requiring “real-time” location, these solutions may either be complex to incorporate or not be performant enough to meet the requirements.
Redis 3.2 Capabilities
With the upcoming Redis 3.2 release (3.2RC Release Notes link), Redis users will now be able to perform geographical commands natively in Redis. Commands that will now be supported in Redis include:
Different geographic solutions that work with Redis have been around for a while but this is the first time that geo commands have been incorporated into Redis itself. For example, there was the redis-geo work that Matt Stancliff did some time back that got the conversation going in earnest. With Redis being an in-memory/highly performant datastore and super simple to use, this creates for a very powerful development tool that is extremely accessible. The possibilities that this creates for developers of all skill levels is huge.
Why Now – Before Redis 3.2 is released
Part of our vision at ObjectRocket is to improve by an order of magnitude the way developers store, retrieve, and manage data. We see these geographic capabilities as a great opportunity for our customers and the Redis community at large. We want to get 3.2RC instances into customer’s hands quickly so that they can start experimenting, ideating, and getting comfortable with the new functionality. Being that these instances will be provided as “Early Access” (link to what that means), they are not intended for Production environments. Right now, you can only provision smaller instance sizes as part of they early offering (.5G, 1G, and 2.5G). As soon as Redis 3.2 is released as “stable”, we will remove the “Early Access” tag and make it part of our standard Redis provisioning process.
The types of use cases that this functionality can apply to varies greatly. Everything from location matching to “Internet of Things” solutions come to mind. In order to seed your thinking a bit, here are some examples of where Redis geographic functionality could be used.
- Find hotels or restaurants that are close to a persons location
- Social matchmaking sites
- Transportation services
- Traffic analysis
- Package shipment tracking
- Endurance event or race tracking
Some of these are obvious and already exist today. Innovation can be limited by the tools that we have available at that point in time. When our tools change, the possibilities change. We are most excited to see the use cases that are not obvious being generated from now having these features in Redis. Bill Anderson (our in house Redis “Mad Scientist”) has put together a great tutorial with a use case that highlights Redis’ geo capabilities in order to get the creative juices flowing.
As you can see, we are excited about adding these GEO capabilities to our managed Redis product and seeing what our customers develop. Once the “Release Candidate” is removed from Redis 3.2 and it becomes stable, we will get it added to our standard product offering in all instance sizes. Until then, have fun with this new capability and let us know you create.