If you are interested in helping test the upcoming version, please e-mail moostraxsupport@gmail.com.

Note: MoosTrax works on devices running iOS 4+.

iPhone Support/Help
MoosTrax iTunes Link

• View a list of all of your devices
• View the current location of any device on your account.
• Enhanced battery usage through the “Conserve Battery” feature.

The beta is still open, so send an e-mail to moostraxsupport@gmail.com to join.

I’m looking for beta testers…and then soon I’ll be pushing it to the App Store.

Applying for the beta

Please e-mail moostraxsupport@gmail.com with your iPhone’s UDID.

For information on finding the UDID, go here: http://www.geekology.co.za/blog/2009/07/how-to-check-your-iphones-udid-from-itunes/

Screenshots

I’ve been running a mobile GPS tracking service, MoosTrax (formerly BlackBerry Tracker), for a few years and have encountered a large amount of data in the process.

A user’s phone sends its location to the server and it is stored in a MySQL database. Each “location” entry is stored as a single row in a table.

Right now there are approximately 12 million rows in the location table, and things are getting slow now, as a full table scan can take ~3-4 minutes on my limited hardware. This means that if a user is pulling a location from history it could potentially block all other users (as the table is locked) access to the site until the query is complete.

Partitioning

Partitioning allows you to store parts of your table in their own logical space. With partitioning, you want to divide up your rows based on how you access them. If you partition your rows and you are still hitting all the partitions, it does you no good. The goal is that when you query, you will only have to look at a subset of the data to get a result, and not the whole table.

There are various ways in MySQL to partition a database, such as:

• RANGE – rows are partitioned based on the range of a column (i.e date, 2006-2007, 2007-20008, etc,.)
• HASH – hashes a column and depending on the result of the hash, has a different partition
• LIST, KEY

Choosing the partition type is important, so I looked at how my application looks up a user’s location.

Getting a user’s current location

Getting a users’s location history

At first, I thought about RANGE partitioning by date, and while I am using the date in my queries, it is very common for a query to have a very large date range, and that means it could easily span all partitions.

After a second look, it seemed that device_id might be the best, using the HASH partitioning type.

This means that all the locations would be partitioned equally by their device_id. This is great because MoosTrax is only looking at one device at a time, history or live tracking, and doesn’t aggregate the locations across devices or users.

Preparing to partition

First, to partition a table the column you want to partition by must be part of the primary key. I only had “id” in my primary key, so I modified it to include my partitioning column, device_id.

Drop the Primary Key

Partition the table

Now we are going to add our new primary key, and tell MySQL to partition, with HASH, by device_id. We also specify the option, partitions, to tell MySQL how many partitions we want it to use. I believe the limit is 1024.

FYI: Running the above may take a while depending on the size of your table.

Does it work?

MySQL has a command that we can run, explain partitions, that will let us specify a query, and MySQL will tell us if and how it is using partitioning to get the result.

Because we partitioned by device_id, let’s try a simple select with device_id in the where clause.

If you look at the result of the explain, you can see that MySQL only needs to use partition p1 to find our result..this is great! There are way less rows in the partition than in the whole table.

Now let’s try another query, that won’t use our partitioning column.

As you can see, MySQL would need to go through all 200 partitions to get the result. Fortunately, MoosTrax doesn’t use a query like that, as the device_id is always available. Therefore, if I am searching by date, I will also specify the device_id as well, so that MySQL will use the partition.

That’s better. Now its using our partitions correctly.

As long as you always use your partitioning column in your query, you will be able to take advantage of the partitioning.

The Result

After switching to partitioning, many queries are running much much faster than before. I couldn’t be happier.

If you want to read more about MySQL partitioning, check out the manual.

I will be adding push notifications soon so that when someone pulls up the Live Tracking page on the MoosTrax website, you will receive a notification on your iPhone requesting you to update your location. That is really all I can do for now, as background applications are still not permitted.

If anyone wants to help me test this first version, please email moostraxsupport@gmail.com.

Screenshots:

Email címem: chris@tech9computers.com

No automatic location updates

The iPhone OS does not allow applications to run in the background, which means MoosTrax cannot check your location and send it to the server at a fixed interval.

Push Notifications aren’t the whole solution

MoosTrax could send a push notification to your phone, telling it to send a location update to the server, but unfortunately it requires user interaction. It wouldn’t be too convenient to have your phone vibrating every few minutes asking you to update your location.

Manual updates

Initially, MoosTrax for iPhone will have support for sending location updates to the server manually when you open the application.

Stay tuned

Hopefully, within time, Apple will make the push notification functionality more advanced so that MoosTrax can be as powerful as it is on other platforms, such as Android and BlackBerry. For now, stay tuned for the iPhone application. I am waiting to be approved in the iPhone developer program and then you should see the application in the iTunes store soon.

A new BlackBerry client version has been released, version 0.3.3.

Also, existing Storm users that are experiencing update problems should raise their accuracy to 200 meters and see if that fixes the problem.