Оптимизация национальной базы данных ZIP+4 для быстрого поиска адресов

Я только что получил большой набор текстовых файлов (всего 8 ГБ), содержащих все диапазоны адресов в США. Набор состоит из:

  • 929 файлов ZIP+4, каждый из которых содержит почтовые адреса с уникальным трехзначным почтовым индексом. Например, файл 606 будет содержать только адреса с пятизначным почтовым индексом, начинающимся с 606. Общее количество записей в этих файлах составляет примерно 30 миллионов.

  • Файл City State, содержащий полный список почтовых индексов и соответствующих им городов и штатов.

Ключ города-штата можно использовать для присоединения файла города-штата к файлам ZIP+4.

Учитывая размер базы данных и отсутствие у меня опыта, я хотел получить некоторое представление, прежде чем начинать эту работу. Должны ли файлы ZIP+4 быть объединены в один файл-монстр, а затем проиндексированы с использованием почтового индекса или разделены трехзначным почтовым индексом, чтобы имя файла с трехзначным почтовым индексом можно было использовать в качестве критерия сопоставления блоков? Если последнее, то не будет ли это иерархической моделью базы данных? Могу ли я согласовать отношения с файлом City State, используя иерархическую модель?

Приведенное выше описание набора данных является огромным упрощением, но для целей этого вопроса подробное описание не требуется. Полное описание можно найти здесь.

Я использую Python и еще не выбрал СУБД. Любая помощь приветствуется!


python database-design postal-code
person user1185790    schedule 13.06.2013    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Если вы собираетесь использовать СУБД, вы в конечном итоге получите содержимое всех 929 файлов в одной базе данных, скорее всего, в нескольких таблицах. Я не могу рассказать вам больше о дизайне такой базы данных, поскольку вы не предоставляете достаточно подробностей о содержимом каждого из этих файлов. Точный макет будет представлять собой нормализованную форму ваших 30 миллионов строк, возможно, в нескольких таблицах. Производительность современных СУБД достаточно хороша для обработки данных такого масштаба, если (и только если) ваши индексы установлены правильно.

Существует очень мало причин не помещать эти данные в РСУБД. Единственная причина, о которой я мог подумать, - это полностью устранить необходимость в такой подсистеме, например. для упрощения развертывания вашего решения. Если вы действительно думаете об этом, то да, набор из 929 файлов может действовать как иерархическая база данных. Основное отличие от решения RDBMS заключается в том, что с таким набором плоских файлов вы можете разумно запрашивать свои данные только по одному ключу - вашему почтовому индексу (или любой его части).

person Hazzit    schedule 13.06.2013
comment
Хаззит, я тоже так понимаю ограничения. Я мог бы разбить адреса с уникальными пятизначными почтовыми индексами на отдельные текстовые файлы и расположить текстовые файлы в каталогах, содержащих уникальные трехзначные почтовые индексы. Таким образом, поиск адреса, содержащего почтовый индекс 60601, приведет к поиску каталога 606, а затем поиску текстового файла 60601. Но, как вы упомянули, я смогу запросить только один ключ - почтовый индекс. В случае несовпадения пятизначного почтового индекса мне нужно будет найти способы эффективного запроса по трехзначному почтовому индексу или городу. - person user1185790; 14.06.2013
comment
@user1185790 user1185790, если у вас есть вариант использования, для которого нужен другой ключ, вам обязательно следует использовать СУБД. - person Hazzit; 14.06.2013
comment
Спасибо Хаззит! Я воспользуюсь РСУБД и применю составные индексы к полям запроса. Возможно, один составной индекс, состоящий из пятизначного почтового индекса, адреса, другой, состоящий из города, адреса, и еще один, состоящий из трехзначного почтового индекса, адреса. - person user1185790; 14.06.2013
comment
@user1185790 user1185790 Не зная многого о вашем приложении, обратите внимание: простой (несоставной) индекс в почтовом индексе автоматически действует как индекс для его первых трех цифр. Простой индекс по городу, вероятно, единственный другой индекс, который вам понадобится. - person Hazzit; 14.06.2013