IP2Location geolocation data helps users to detect the location of persons by their IP addresses. With just the IP address, their physical locations like city, state and country can be easily determined. There are many uses for such data in online advertising, marketing as well as security applications.
To make it easy for users to integrate the IP2Location data into their own websites or applications, IP2Location has provided 2 main methods of consuming the geolocation data. The first method is via the IP2Location database in the form of either a CSV (comma-separated values) file or a BIN binary data file. In addition to the database method, users can also opt to make RESTful calls to the IP2Location Web Service (API service) to get the data they need.
Choosing the database route
If you’re going with the database route, you have the option of loading the CSV file into a relational database like MySQL, SQL Server, PostgreSQL or Oracle. Then you can make SQL queries from your website or application.
There are pros and cons of this method of getting your geolocation data. Below we have listed some of them:
- Easy to integrate no matter what programming language you’re using.
- A well-tuned relational database can perform very well under heavy load, especially with proper indexing and caching enabled.
- Depending on your infrastructure, the database can be scalable.
- Cost is fixed.
- Need to download the latest data monthly and perform importing into database server.
- May have disruption during the database update since the table needs to be dropped and recreated.
- Another server is needed to run the relational database (assuming you have it separate from your main server).
- The loaded data requires gigabytes of storage with additional storage needed during updates.
Now, let’s take a look at the BIN database file. As mentioned above, IP2Location provides data in either a CSV file or a BIN binary file. The BIN binary file is a proprietary format that IP2Location have created to be queried using various Software Development Kits (SDKs). Again, there are pros and cons with using the BIN file.
- No installation or import necessary.
- Can be easily queried using the SDKs provided by IP2Location.
- Some SDKs like .NET and Java have memory mapped file capability which allows for super-fast geolocation queries.
- Highly portable as it is just a data file. Can copy to any website or deploy with your application.
- Fixed pricing.
- Require replacing the data file every month with the latest.
- Require the use of SDKs by your website or application.
- The data file can be quite huge if you go for the higher-end database.
- Using the SDKs with memory mapped file enabled consumes lots of contiguous RAM.
- Large number of queries may cause file handle exhaustion in SDKs that are using file I/O to read the BIN.
Choosing the API route
The alternative to the database method is calling the IP2Location Web Service. This REST-based API can return the same data as you would get if you were using the databases. Let’s see what are the good and bad of using the API.
- Can be easily integrated into most programming languages.
- REST-based which is light enough compared to XML-based APIs.
- Fast queries with the nearest server responding to your requests.
- Nothing to install.
- No storage required.
- No updates required as every query will contain the latest data.
- Pay-per-use model is costly if performing lots of queries.
- Personally identifiable info such as IP address is sent to various regions, making data privacy compliance much harder.
- There might be web service outages if servers go down.
- Network latency varies depending on your location, hence time-sensitive applications may suffer.
There is no right or wrong way to consume IP2Location geolocation data. It all depends on your infrastructure, budget and requirements. Hopefully, the above can make it easier for you to decide which way is best for you and your organization.