MetaLocator.com has the power to host an Interface with over 1 million locations. This can take some careful planning to avoid any slowness or difficulty planning your implementation.
Work with your account representative and our support staff to get the most out of your MetaLocator subscription.
Overall, it is important to properly organize your data, and plan your interface configuration, especially the search and sort options. As row counts increase, planning and designing deliberately and with performance in mind is essential. The following tips can greatly improve performance of an Interface:
Avoid multiple filter combinations under Filter & Sort. Over 1 million records, using a maximum of 1 filter should be the goal. If you're creating a locator that should exclude or include records based multiple factors, create a single column in your data that reconciles those factors instead. For example, if creating a locator that shows only rows in Chile whose annual sales is greater than 1M, a faster approach is to create a column called Chile1M whose value is 1 only where the record is in Chile with annual sales is greater than 1M.
Avoid broad match keyword search. The keyword search accesses most columns in your data, looking for all variations of keyword search and is expensive to run. Instead, refine the search values to a single data column, and add that column to the Search form, and change the Display Type to "Text". This will reduce the performance impact of the search.
Avoid placing custom fields in the Search form using the default settings. MetaLocator will try to build a drop-down list of all values in your custom field, which is computationally expensive. Instead, change the Data Source to either Field Settings or Interface Settings and provide the values manually.
Once your Interface Design is finalized, request that the MetaLocator Support team create Database Indexes in your account that optimize your configuration. In very high-data volume environments, it is important that this request be made after interface configuration is fully complete and finalized. Database Indexes are selected based on the configuration and may not apply if the configuration changes.
Do not use the "Nearest Radius" option. Nearest calculates the closest location by evaluating the distance of every result in the system, which is very expensive over 1M locations.
Do not use the "Exclude Categories" filter setting. In general, avoid creating Interface Filters by Category per the first point above, however; Exclude Categories is particularly expensive.