none
DocumentDB or Azure Search for spatial data? RRS feed

  • Question

  • Hello.

    Assuming I have a dataset that consists of the position of 1M points that change location over time, which would be the best store for them? I know that both Azure Search and DocumentDB support spatial queries so I'm curious to know when I should choose one over the other.

    Thanks.

    Friday, April 8, 2016 1:24 PM

Answers

  • It comes down to the kinds of queries, frequency of updates, and your latency and consistency requirements. Note that DocumentDB is a persistent database whereas Azure Search is designed for rich querying but not as a primary database. You'd typically use Azure Search with DocumentDB instead of choosing one over the other.

    DocumentDB is built for fast/low latency reads, proximity queries, and writes, and consistent updates to the index. Search is typically higher latency, but supports full text querying, faceting, and other capabilities. For example, if you need ST_DISTANCE and ST_WITHIN (within radius and polygon), you could use just DocumentDB, but if you want full-text with spatial querying, you'd need Search + DocumentDB.

    Can you please share details on your requirements?

    • Marked as answer by Han, MSFT Friday, April 15, 2016 9:33 PM
    Saturday, April 9, 2016 2:43 PM
  • For that kind of scenario seems like DocumentDB fits better.

    I'd use Azure Search if you are provinding text search or facets/filters or some kind of custom scoring (like, these cars are more important than these others because of X, Y , Z).

    If you are just filtering by a time slice, DocumentDB is cheaper and probably easier to implement.

    If later, you want to provide full search capabilities (like, searching for car details or filtering by brand/make), you can implement Azure Search as an Index over your DocumentDB data easily with Indexers.

    • Marked as answer by Han, MSFT Friday, April 15, 2016 9:33 PM
    Monday, April 11, 2016 2:56 PM

All replies

  • It comes down to the kinds of queries, frequency of updates, and your latency and consistency requirements. Note that DocumentDB is a persistent database whereas Azure Search is designed for rich querying but not as a primary database. You'd typically use Azure Search with DocumentDB instead of choosing one over the other.

    DocumentDB is built for fast/low latency reads, proximity queries, and writes, and consistent updates to the index. Search is typically higher latency, but supports full text querying, faceting, and other capabilities. For example, if you need ST_DISTANCE and ST_WITHIN (within radius and polygon), you could use just DocumentDB, but if you want full-text with spatial querying, you'd need Search + DocumentDB.

    Can you please share details on your requirements?

    • Marked as answer by Han, MSFT Friday, April 15, 2016 9:33 PM
    Saturday, April 9, 2016 2:43 PM
  • My dataset consists of positions of cars along the day. The number of cars is about 100k, but I only get these positions daily, in batch.

    As for the kinds of queries that I will need, I want to produce a map in which I can see the positions of the cars being updated as I use the time slider. So, "at this time, give me all the cars present in this area of the map". Something like that.

    Monday, April 11, 2016 9:30 AM
  • For that kind of scenario seems like DocumentDB fits better.

    I'd use Azure Search if you are provinding text search or facets/filters or some kind of custom scoring (like, these cars are more important than these others because of X, Y , Z).

    If you are just filtering by a time slice, DocumentDB is cheaper and probably easier to implement.

    If later, you want to provide full search capabilities (like, searching for car details or filtering by brand/make), you can implement Azure Search as an Index over your DocumentDB data easily with Indexers.

    • Marked as answer by Han, MSFT Friday, April 15, 2016 9:33 PM
    Monday, April 11, 2016 2:56 PM
  • Thanks!
    Monday, April 11, 2016 3:48 PM