Как обновить базу из ~ 25 000 музыкальных файлов?

Question

Обновление:

Я написал рабочий сценарий, который завершает эту работу в течение разумного периода времени и выглядит достаточно надежным. Он полностью написан на PHP и основан на идее array_diff (), предложенной сахарином (так что, спасибо сахарину!).

Вы можете получить доступ к исходному коду здесь: http://pastebin.com/ddeiiEET

У меня есть база данных MySQL, которая является индексом mp3-файлов в определенном каталоге вместе с их атрибутами (т. Е. Title / artist / album).

Новые файлы часто добавляются в каталог музыки. На данный момент он содержит около 25 000 файлов MP3, но мне нужно создать задание cron, которое просматривает его каждый день или около того, добавляя любые файлы, которые он не находит в базе данных.

Проблема в том, что я не знаю, как лучше / наименее обременительный способ сделать это. Я предполагаю, что запрос MySQL должен был бы выполняться для каждого файла в каждом запуске cron (чтобы проверить, уже ли он проиндексирован), поэтому сценарий неизбежно займет некоторое время, чтобы запустить (что нормально; это автоматизированный процесс). Однако из-за этого моего обычного языка выбора (PHP), вероятно, будет недостаточно, поскольку он не предназначен для запуска таких долгосрочных сценариев (или это ...?).

Очевидно, что это было бы неплохо, но меня не смущает удаление записей индекса для удаленных файлов (если файлы на самом деле удаляются, это всегда ручная очистка, и я не против просто зайти в базу данных вручную, чтобы исправить индекс).

Кстати, это было бы рекурсивно; файлы в основном расположены в структуре Artist / Album / Title.mp3, однако они не упорядочены подобным образом, и скрипт наверняка должен будет иметь возможность извлекать теги ID3 для новых файлов. Фактически, в идеале, я бы хотел, чтобы скрипт извлекал теги ID3 для каждого файла при каждом запуске, и либо добавлял новую строку в базу данных, либо обновлял существующую, если она изменилась.

Во всяком случае, я начинаю с нуля с этого, поэтому сначала думаю, что это самый основной совет (например, какой язык программирования использовать - я готов выучить новый, если необходимо). Большое спасибо!

Answer 1

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

Если все, что вам нужно, это повысить скорость вашего текущего кода, я бы порекомендовал вам проверить, что ваши данныеправильно проиндексированы.Это делает запросы намного быстрее, если вы ищете по индексу таблицы.Если вы ищете столбцы, которые не являются ключевыми, вы можете изменить настройки.Вы также должны избегать использования «SELECT *» и вместо этого использовать «SELECT COUNT», поскольку mysql будет возвращать целые числа вместо объектов.

Вы также можете делать все в нескольких запросах MySQL, но это увеличит сложность вашего PHP-кода.Вызовите массив с информацией обо всех файлах $ files.Выберите данные из БД, где файлы в БД соответствуют файлу в $ files.Примерно так.

"SELECT id FROM MUSIC WHERE id IN ($files)"

Считайте возвращенный массив и отметьте его как $ db_files.Затем найдите все файлы в массиве $ files, которые не отображаются в массиве $ db_files, с помощью array_diff ().Назовите отсутствующие файлы $ missing_files.Затем вставьте файлы из $ missing_files в базу данных.

Answer 2

Какой тип двигателя вы используете?Если вы используете MyISAM, вся таблица будет заблокирована при обновлении таблицы.Но, тем не менее, 25 тыс. Строк не так много, поэтому, в основном, через (максимум) несколько минут, они должны быть обновлены.Если это InnoDB, просто обновите его, поскольку он заблокирован на уровне строк, и вы все равно сможете использовать свою таблицу при его обновлении.

Кстати, если вы не используете полнотекстовый поиск по этой таблице,Я считаю, что вы должны преобразовать его в InnoDB, так как вы можете использовать внешние индексы, и это очень помогло бы вам при объединении таблиц.Кроме того, он лучше масштабируется AFAIK.