Почтовый индекс (ZIP) по всему миру (не только США) оптимизированная структура данных (не SQL, CSV или Google API) для долгого и латового поиска
Кто-нибудь знает структуру базы данных, такую как этот http://www.maxmind.com/app/geolitecity которая оптимизирована для сверхбыстрого поиска длинных и длинных широковых баз на основе параметров ZIP или (город, штат, страна)?
База данных Maxmind не поддерживает какой-либо другой поиск, кроме IP-поиска, по крайней мере, на мой взгляд. Так что, если вы знаете, как сделать это желательно на Java, я весь слух.
Это не должна быть база данных типа SQL, файл CSV или решение Google API. Ты просто медленный. Особенно, если вы хотите предложить результаты поиска, отсортированные по расстоянию.
Платные решения также вариант. Структура данных не должна быть бесплатной.
2 ответа
Я не верю, что есть такой "быстрый" способ сделать это. Я создал API геокодирования для канадских почтовых индексов, и мы ищем два индекса почтовых кодов: один отсортирован по широте, а другой - по долготе. Вы можете создать некоторую сферическую геометрию и разработать ограничивающий "прямоугольник", который будет соответствовать всему на заданном радиусе, но вам все равно придется вернуться назад и выполнить измерение расстояния от точки к точке, используя Vincenty или Haversine или ваш алгоритм выбора расстояния между вашими источниками. и каждый почтовый индекс вы найдете.
Благодаря всемирной базе данных ваша математика усложняется тем, что вы можете пересечь меридианы и экватор.
Вам понадобится какая-то схема кодирования, которая позволит вам работать в радианах, поскольку это то, что требуется большинству хьюристиков для расчета расстояний.
Это может быть сделано очень быстро с любым механизмом базы данных, который поддерживает двумерные индексы... и mysql поддерживает неограниченные измерения, насколько я знаю... это просто... вы используете двумерный индекс, чтобы ограничить свой набор результатов разумным размер очень быстро... затем вы проверяете свой набор результатов с помощью алгоритма вычисления высокой точности, если вам нужно... не сложно... за исключением того, что вам может понадобиться или два списка вместе, если они пересекают линию долготы 180/-180, делая 2d index просто... index (широта, долгота) ... этот индекс работает только для пар широта или широта, долгота... он не будет работать только для одной долготы... если вам нужен дополнительный индекс для индекса долготы (долгота) .... Я выбираю приблизительный квадрат оценки и закругляю углы, если я забочусь о них....
если у вас есть почтовый индекс или город, с которого можно начать... почтовые индексы - это всего лишь 1-й индекс... нет проблем, чтобы это произошло быстро... просто используйте индексный индекс (zip) ... и если ваш жесткий диск слишком медленно, найдите твердотельный накопитель, чтобы исключить время поиска... или используйте огромный оперативный памяти и кешируйте всю таблицу... это не сложная проблема в любом случае
если это не достаточно быстро для вас, использование службы someones не поможет, так как у вас есть сетевые издержки... вам придется хранить ваши данные непосредственно в ram/ssd и создать свою собственную систему 2-d /1-d индексации, если вы нужно (не сложно) ... этот маршрут, вероятно, может превзойти sql в 10 раз или около того, потому что у движка sql много накладных расходов.... Я полагаю, кто-то может предложить сервис, работающий на вашей собственной машине, но На самом деле, это далеко не победит sql, потому что вам все равно придется пройти через кучу обручей, чтобы запросить их службу. sql и 2-d индексы с твердотельным накопителем будут чертовски быстрыми, вам не нужно обрабатывать данные самостоятельно, если вы не являетесь почтовым отделением, сортируя 10000 почтовых отправлений в секунду на одном компьютере, обслуживающем данные. тогда вам придется написать свои собственные процедуры управления данными.