Brief introduction
With the rapid popularization of various mobile terminals in recent years, location-based Services (LBS) and related applications are more and more, and one of the most basic technologies to support these applications is based on the location of information processing. My project is also engaged in the development of related systems, we are using a combination of Symfony2+doctrine2 odm+mongodb.
We have written these technical points in the hope that we can explain in detail how to use MongoDB to query and process geographical information through the introduction and case of this article. At the beginning of the article, we will also introduce some of the scenarios that the industry typically uses to process geographic information and compare them, giving readers a step-by-step understanding of the advantages of using MONGODB queries and processing geographic information.
This article uses Symfony2 and DOCTRINE2 as the development framework for Web applications, and for readers who want to understand Symfony2 's database operations, they can understand and master the relevant technologies and usage methods.
1. LBS Application Characteristics
No matter what lbs apps are, a common feature is that their data contains more or less geographic information. How to query, process and analyze the information has become the most basic and key technical problem to support lbs application.
Because of the particularity of geographical information, there are often more difficult problems in development, for example: Because the user's location is not fixed, the user may move in a very small range, and the value of latitude and longitude will change; even in the same location, the location information obtained through the GPS device may be different. So if through latitude and longitude to get the surrounding information, it is difficult to do as the traditional database query and caching.
For this question, some readers may say that there are other solutions, yes, for example, only a few decimal points fixed by the latitude index, such as by the matrix of the user divided into a fixed small area (can refer to the Geohash), etc., although can be around a bend solution, But more or less operate more trouble, will sacrifice some precision, and even can not achieve the optimization of performance, so can not be counted as the best solution.
And in recent years, directly supporting the geographical operation of the database, its operation friendly, high performance characteristics are also beginning to be we pay attention to, the leader of which is MongoDB.
What are the advantages of MONGODB in the processing of geographic information? Below we use a simple case to compare the differences between the various technical scenarios for geographic information processing.
2. Comparison and analysis of several geographic information processing schemes
1. Determine functional requirements
For any LBS application, it may be an essential feature for the user to look around for friends, and we take this feature as an example to see the differences and differences between the various solutions.
We assume that the following functional requirements are available:
Show the People Near Me
Sort by near to far
Show distance
2. Possible technical programmes
To eliminate some of the technology that is not common and difficult to implement, we list the following scenarios:
Based on MySQL database
Using Geohash index, based on MySQL
MySQL Space storage (MySQL spatial Extensions)
Use MongoDB to store geographic information
Let's analyze each of these options.
Scenario 1: Based on MySQL database
MySQL is very easy to use. For most sites that already use MySQL, there is no migration or deployment cost to use this scenario.
And in MySQL query "nearest person" also need only one SQL,
SELECT ID, (6371 * acos (cos (radians ()) * cos (radians (LAT)) * cos (radians
(LNG)-radians ( -122)) + sin (r Adians (Panax)) * sin (radians (LAT)))) as distance
from places has distance < ORDER by Distance LIMIT 0, 1 00;
Note: This SQL query is the target near the coordinates of the LAT,LNG, and in the order of distance, the distance unit in SQL is kilometer.
But the disadvantage of using SQL statements to query is obvious, each SQL is computationally large, and performance can be a serious problem.
Don't give up, we're trying to do some optimizations on this SQL.
You can abstract a circular area into squares, as shown in the following figure