Лучший способ справиться с базой данных 900 000 записей и почтовыми индексами?

Компания, с которой мы ведем бизнес, хочет каждый день предоставлять нам CSV-файл размером 1,2 ГБ, содержащий около 900 000 списков продуктов. Лишь небольшая часть файла изменяется каждый день, может быть, менее 0,5%, и на самом деле это просто добавляемые или удаляемые продукты, а не изменение. Нам необходимо показать списки продуктов нашим партнерам.

Это усложняет то, что наши партнеры должны видеть списки продуктов, доступные только в радиусе 30–500 миль от их почтового индекса. В каждой строке списка продуктов есть поле для определения фактического радиуса продукта (у некоторых всего 30, у некоторых - 500, у некоторых - 100 и т. Д. 500 - это максимум). Партнер с данным почтовым индексом, скорее всего, получит только 20 результатов или около того, а это означает, что будет масса неиспользованных данных. Мы не знаем заранее все почтовые индексы партнеров.

Мы должны учитывать производительность, поэтому я не уверен, что лучше всего сделать.

Должен ли я иметь две базы данных - одну с почтовыми индексами и широтой / долготой и использовать формулу Хаверсина для расчета расстояния ... а другую - фактическую базу данных продуктов ... и что мне тогда делать? Вернуть все почтовые индексы в пределах заданного радиуса и искать совпадения в базе данных продуктов? Для радиуса 500 миль это будет тонна почтовых индексов. Или написать функцию MySQL?

Мы могли бы использовать Amazon SimpleDB для хранения базы данных ... но тогда у меня все еще есть проблема с почтовыми индексами. Я мог бы создать два «домена», как их называет Amazon, один для продуктов, а другой для почтовых индексов? Однако я не думаю, что вы можете делать запросы в нескольких доменах SimpleDB. По крайней мере, я не вижу этого нигде в их документации.

Я полностью открыт для другого решения. Это не обязательно должен быть PHP / MySQL или SimpleDB. Просто имейте в виду, что наш выделенный сервер - это P4 с 2 ГБ. Мы могли бы обновить оперативную память, просто мы не можем вложить в это кучу вычислительной мощности. Или даже храните и обрабатывайте базу данных каждую ночь на VPS где-нибудь, где не было бы проблем, если бы VPS был невыносимо медленным, пока обрабатывается этот CSV размером 1,2 ГБ. Мы могли бы даже обрабатывать файл в автономном режиме на настольном компьютере, а затем удаленно обновлять базу данных каждый день ... за исключением того, что у меня все еще есть проблема с почтовыми индексами и списками продуктов, требующими перекрестных ссылок.


person Phil    schedule 07.06.2011    source источник
comment
вам следует опустить стену с текстом. Так как сейчас не так ясно, в чем ваша проблема и чего вы хотите добиться.   -  person dynamic    schedule 08.06.2011
comment
возможный дубликат Самый быстрый поиск расстояния с учетом широты / долготы?   -  person D'Arcy Rittich    schedule 08.06.2011
comment
Я предлагаю вам спросить их, можно ли получить ленту различий, а не полную ленту. Это, вероятно, будет меньше работы для обработки. Возможно, они легко справятся с этим.   -  person Brian    schedule 08.06.2011
comment
Проблема в том, как сохранить 900 000 записей, которые должны иметь перекрестные ссылки по радиусу почтового индекса, на сервере, на котором есть только Pentium 4 с 2 гигабайтами ОЗУ. Должен ли я обновить это и попытаться сделать это полностью в MySQL, или я использую Amazon SimpleDB? Если я сделаю это в MySQL, как лучше всего учесть близость почтовых индексов во второй базе данных, имея в виду, что я не могу просто вернуть все почтовые индексы в радиусе 500 миль без потери производительности? Или есть какое-то другое решение?   -  person Phil    schedule 08.06.2011
comment
@Phil: отредактируйте свой первый пост. Начни его опускать. Не размещайте больше стены с текстом   -  person dynamic    schedule 08.06.2011
comment
Объясните клиентам, что такое 'diff', и пусть они присылают только вывод diff. Лучше проанализировать несколько сотен килобайт данных, а не более 1 гигабайта.   -  person Marc B    schedule 08.06.2011
comment
Это не просто разовый вопрос, как написать такой-то запрос. Мне нужен совет, как лучше всего обрабатывать все эти данные.   -  person Phil    schedule 08.06.2011
comment
Если клиент не может / не может предоставить различия, не так уж сложно сохранить файл предыдущего дня и сгенерировать свой собственный diff.   -  person MarkD    schedule 08.06.2011


Ответы (2)


Вы можете изучить PostgreSQL и Postgis. Он имеет функции, аналогичные функциям пространственного индексирования в MySQL. , без необходимости использовать MyISAM (который, по моему опыту, имеет тенденцию к повреждению, в отличие от InnoDB).

В частности, с Postgres 9.1, который позволяет поиск k-ближайшего соседа запросы с использованием индексов GIST.

person Denis de Bernardy    schedule 07.06.2011
comment
MySQL (по крайней мере, моя версия: 5.5.13) также поддерживает InnoDB. - person John M.; 08.06.2011
comment
@John: насколько я читаю документы, пространственная функциональность существует во всех таблицах, но индексация (в том числе в 5.5) работает только с MyISAM. (Это очень похоже на полнотекстовое индексирование.) - person Denis de Bernardy; 08.06.2011
comment
@yes: не полнотекстовые индексы. Если подумать, я не уверен, что он поддерживает оператора, но я был бы удивлен, если это не так. - person Denis de Bernardy; 08.06.2011

Что ж, это действительно интересная проблема.

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

Что касается второго, то это больше моя область знаний. Вы можете сделать так, чтобы ваш клиент загрузил вам CSV-файл в том виде, в котором он сейчас есть, сохранить копию вчерашнего и запустить ее с помощью утилиты diff, или вы можете использовать Perl, PHP, Python, Bash или любые другие инструменты, которые у вас есть, чтобы найдите строки, которые изменились. Передайте их во второй блок, который обновит вашу базу данных. Я имел дело с клиентами с проблемами в этом направлении, и сценарий, как правило, является лучшим выбором. Если вам нужна помощь в организации вашего сценария, он всегда доступен.

person Bob_Gneu    schedule 07.06.2011