Splitting CoreData up for a faster query time

1
votes

I have a huge core data database of longitudes and latitudes for paths on a map.

I have an object called a way which consists of an ordered set of Nodes (lon,lat). I also store the enclosing box around the way (minLon, minLat, maxLon, maxLat ...).

Data Model

My query finds all the ways in a particular region of the map:

NSPredicate *predicate = [NSPredicate predicateWithFormat:
    @"minLon < %f AND maxLon > %f AND minLat < %f AND maxLat > %f",
        maxLon, minLon, maxLat, minLat];

Its dam slow!

My idea to speed up the query is to split the data by square regions somehow (Multiple tables? Multiple .sqllite files? Create a hash of the location?) so there is less data to search though.

How can I do this?

1
iphonesqliossqlitecore-data

1 Answers

5
votes

  1. You could speed up the query by storing the min/max values in your Way entity as scaled integers instead of floats. Pick a scaling factor that gives you an acceptable area resolution, use it to prescale the values when you store them and use the same scale factor when you do the query.

  2. You could also look at adding a quadtree data structure to your core data model to home in on Ways in the desired area.

  3. SQlite will bail out at the first test that fails in a compound predicate so put the cheapest test first.

  4. Also look at enabling indexing for those 4 attributes.

To be honest though, I'm surprised that this is slow. How many total Ways do you have in your database and how many typically in an area that you want to query?

Have you tried turning on SQL debugging to see what query is actually run against the database? (hint: add -com.apple.CoreData.SQLDebug 1 as a command line argument in your Scheme editor for the Run behaviour)