Оптимизация MySQL против множества плоских файлов и использования жесткого диска

Question

Я хочу запустить алгоритм машинного обучения в качестве своего кода для исследования конечных игр, который, таким образом, далеко не доказан и не опубликован для целей анализа текста. Текст уже получен, но был извлечен из формата warc, полученного из Common Crawl. Я нахожусь в процессе подготовки данных для целей машинного обучения, и одной из задач анализа, которая является желательной, является IDF-анализ частоты инверсных документов корпуса перед запуском в собственное приложение ML.

Насколько я понимаю, для работы IDF каждый файл должен представлять одного докладчика или одну идею - как правило, короткий абзац текста ascii, не намного длиннее, чем твит. Проблема в том, что я очистил около 15 миллионов файлов. Я использую Strawberry Perl в Windows 7 для чтения каждого файла и разбиения по тегу, содержащемуся в документе, так что каждый комментарий из рассматриваемых социальных сетей попадает в элемент массива (и на более строго типизированном языке будет типа строка).

Отсюда возникают проблемы с производительностью. Я позволил своему сценарию работать весь день, и он прошел через 400 000 входных файлов за 24 часа. Из этих входных файлов создается около 2 миллионов выходных файлов, представляющих по одному файлу на спикер HTML-разорванного текста с помощью модуля Perl HTML :: Strip. Когда я смотрю на свою систему, я вижу, что использование диска на моем локальном диске с данными очень велико - существует огромное количество текстовых записей ASCII, намного меньше, чем 1 КБ, каждая из которых встраивается в сектор размером 1 КБ моего локального диска. HDFS в формате NTFS.

Стоит ли пытаться остановить выполнение, настроить базу данных MySQL на моей домашней системе, настроить текстовое поле в базе данных длиной не более 500-1000 символов, а затем повторно запустить сценарий perl так, чтобы он выскальзывает входной html-файл, разбивает его, HTML-разметывает, затем готовит и выполняет вставку строки в таблицу базы данных?

В целом - переключение с формата вывода файла, который представляет собой огромное количество отдельных текстовых файлов, на формат, который представляет собой огромное количество вставок в базу данных, будет проще на моем жестком диске / быстрее записать в долгосрочной перспективе из-за какая-то магия кэширования или использования ОЗУ / дискового пространства в СУБД?

Answer 1

Whow!

Несколько лет назад у нас были огромные проблемы в популярных cms. По равнине в основном хорошие показатели. Но он меняется вниз, когда появляются боковые проходы.

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

1-й) Я использовал время для установления прямой адресной точки. У каждого есть свой набор плоских файлов.

2) Я сделал рамдиск. Будьте уверены, что у вас достаточно для вашего проекта!

3-й) Для резервного копирования я использовал rsync и renundance, которые я сжал / распаковал на Ramdisk в tar.gz

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

Окончательный выпуск приводит к обработке из:

PHP / MySQL> 5 секунд Perl / HDD ~ 1,2 сек Perl / RamDisk ~ 0,001 сек

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

Жесткий диск будет жить намного дольше, ваш рабочий процесс может быть оптимизирован с помощью прямой адресации. Это доступно с других этапов. Скажем, вы можете работать на этой основе и из других скриптов. Как вы полагаете, обработка данных в R, извещатель из оболочки или что-то еще ...

Ошибки буферизации, такие как MySQL, больше не нужны. Ваш процессор больше не зацикливается.

Answer 2

Файловую систему можно интерпретировать как иерархическое хранилище значений ключей, и она часто используется в таких программах Unix. Однако создание файлов может быть довольно дорогостоящим, в зависимости от используемой ОС и файловой системы. В частности, различные файловые системы значительно различаются в зависимости от масштаба времени доступа с количеством файлов в одном каталоге. Например. см. производительность NTFS и большие объемы файлов и каталогов и Как вы справляетесь с большим количеством маленьких файлов? : «Производительность NTFS сильно снижается после 10000 файлов в каталоге».

Таким образом, вы можете увидеть значительные преимущества, перейдя от псевдобазы данных, использующей миллионы маленьких файлов, к «реальной» базе данных, такой как SQLite, которая хранит данные в одном файле, что делает доступ к отдельным записям более дешевым.

С другой стороны, 2 миллиона записей - это не так много, предполагая, что издержки файловой системы не могут быть для вас ограничивающим фактором. Попробуйте запустить программное обеспечение с тестовой рабочей нагрузкой и использовать профилировщик или другие средства отладки, чтобы узнать, на что тратится время. Это действительно open(), который занимает так много времени? Или есть другая дорогостоящая обработка, которая может быть оптимизирована? Если есть этап предварительной обработки, который можно распараллелить, он один может значительно сократить время обработки.