Самый быстрый иерархический гео-адрес, поиск данных по наименее дорогому оборудованию? NoSQL или SQL?

Question

У меня есть 350000 город адреса с широтой и долготой значений, например:

2500 HardToSpellName Street NW (квадрант), Город, Район, Страна

Казалось бы, что лучшая структура данных будет JSON-файл в основном в обратном порядке и иметь пользователь ввести запрос в таком порядке:

Country.State.City.Quadrant.StreetType - все это повторяется много раз

Затем переключитесь на ввод данных гражданского номера, как номер легко для заклинания;) Из вышесказанного мы будем применять t поиск для заполнения «Автозаполнения» в названии улицы, поскольку он подвержен орфографическим ошибкам.

Запрос данных всегда один и тот же, один адрес ввода получает результат Lat/Long.

Это хорошая идея? Сколько записей было бы разумным? Как бы вы преобразовали таблицу (csv) в дерево JSON?

Является основной причиной использования NoSQL более низкой стоимости аппаратного обеспечения/хостинга?

Answer 1

Я думаю, что лучшая идея состоит в том, чтобы ограничить потенциальный результат множеством как можно меньше записей, используя вход пользователя. Это может быть достигнуто с помощью комбинированного индекса [Страна, Состояние, Город, Квадрант, Тип StreetType], если пользователи должны ввести условия поиска в этом порядке.

Индекс позволит фильтровать «Страна», если это первый и единственный введенный вход. Если страна выбрана и введено «Государство», запрос индекса приведет к ограничению результатов отчетами для введенной комбинации страны и штата и т. Д. В общем, чем больше у вас критериев, тем дальше вы можете использовать его, чтобы сузить результаты. Требование состоит в том, что вы используете некоторый отсортированный индекс и только запрашиваете индексированные атрибуты слева.

Когда введен последний критерий (StreetType), набор результатов, вероятно, уже довольно мал, поэтому вы можете вернуть все названия улиц из него в приложение и создать и автоматически заполнить поле ввода. Вы можете альтернативно расширить индекс, чтобы он также охватывал названия улиц. Это позволит вам эффективно получить алфавитный список названий улиц (и координат) для критериев поиска.

Насколько я понял, данные могут быть помещены в плоский стол, потому что все записи имеют одинаковую структуру. Затем отсортированный индекс может быть создан для атрибутов, подлежащих индексированию. Любая реляционная база данных должна поддерживать это.

Для этой цели вы также можете использовать базу данных документов NoSQL, и она также должна работать нормально.

Чтобы решить, какое из лучших решений, я думаю, вы также должны учитывать свою нагрузку и другие факторы, например. - У вас есть обновления данных и как часто? нужна ли транзакционная изоляция для чтения и обновления? - какие другие операции должны выполняться внутри базы данных? - можете ли вы жить с плоской структурой таблицы или вам действительно нужны иерологические данные, гибкие схемы?