Question

Hey everyone I am building a website that needs to have the capability to store the physical location of a person and allow someone to search for other people within some radius of that location. For the sake of an example lets pretend it’s a dating website (it’s not) and so as a user you want to find people within 50 miles of your current location that meet some other set of search criteria.

Currently I am storing all of my user information in Azure Table Storage. However this is the first time I’ve ever attempted to create a geo-aware search algorithm so I wanted to verify that I am not going to waste my time doing something totally insane. To that end the idea for my implementation is as follows:

1. Store the longitude and latitude for the users location in the Azure Table
2. The PartitionKey for each entry is the state (or country if outside the US) that the person lives in
3. I want to calculate the distance between the current user and all other users using the haversine equation. I’m assuming I can embed this into my LINQ query?
4. Eventually I’d like to be able to get a list of all states/countries within the radius so I can optimize based on PartitionKey’s

Naturally this implementation strategy leads to a few questions:

1. If I do the haversine equation in a LINQ query where is it being executed? The last thing I want is my WebRole to pull every record from azure storage to run this haversine equation on it within the application process
2. Is the idea of doing this with Azure Storage totally crazy? I know there are solutions like MongoDB that have the capability to do spatial search queries built-in. I like the scalability of Azure but is there some better alternative I should investigate instead?

Thanks for the help in advance!

Answer 1

If you want the query to be fast against Azure tables, the query has to run against the partition key and row key. Also if you’re using LINQ to query Azure tables then you need to be careful about which functions you use. If the value can be calculated once for all row, LINQ will be clever and evaluate it before sending the query to AZT, however if it needs to be evaluated for each row, then you can only use those are those that Azure supports (which is a pretty short list).

You might be able to make this work if you want to use a bounding square for your area not a bounding circle. Store latitude in the PartitionKey and longitude in the RowKey and have a query that looks like this:

var query = from UserLocation ul
            in repository.All()
        where
            ul.PartitionKey.CompareTo(minimumLatitude) > 0
            && ul.PartitionKey.CompareTo(maximumLatitude) < 0
            && ul.RowKey.CompareTo(minimumLongitude) > 0
            && ul.RowKey.CompareTo(maximumLongitude) < 0
        select
            ul;

This is probably not as clever as you were hoping for though. If this is not going to work for you, then you’ll need to look at other options. SQL Azure supports geospatial queries if you want to stay within the Microsoft family.