Хранение многих файлов журнала

У меня есть система, которая получает файлы журналов из разных мест через http ( > 10k производителей, 10 журналов в день, ~ 100 строк текста каждый).

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

Мой вопрос: какой лучший способ их хранить?

Плоские текстовые файлы (с надлежащей блокировкой), один файл за каждый загруженный файл, один каталог в день/производитель
Плоские текстовые файлы, один (большой) файл в день для всех производителей (проблема здесь будет индексированием и блокировкой)
Таблица базы данных с текстом (MySQL является предпочтительным по внутренним причинам) (pb с удалением БД, поскольку удаление может быть очень длинным!)
Таблица базы данных с одной записью на строку текста
База данных с окантовкой (одна таблица в день), позволяющая простую очистку данных. (это разделение. Однако версия mysql, к которой я имею доступ (т.е. поддерживается внутри нее), не поддерживает ее)
Основанный на документах DB à la couchdb или mongodb (проблема может заключаться в индексировании/зрелости/скорости приема)

Любые советы?

Ответ 1

Я бы выбрал самое первое решение.

Я не понимаю, зачем вам вообще нужна БД. Кажется, все, что вам нужно, - это проверять данные. Храните журналы в самом "сыром" состоянии, затем обрабатывайте их, а затем создавайте архив за каждый день.

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

Ответ 2

(Отказ от ответственности: я работаю над MongoDB.)

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

Что касается стабильности, многие люди уже используют MongoDB в производстве (см. http://www.mongodb.org/display/DOCS/Production+Deployments). У нас есть еще несколько функций, которые мы хотим добавить, прежде чем перейти к 1.0.

Ответ 3

Я бы написал один файл для каждой загрузки и один каталог/день, как вы сначала предложили. В конце дня запустите обработку по файлам, а затем tar.bz2 в каталог.

tarball по-прежнему будет доступен для поиска, и, вероятно, будет довольно небольшим, так как журналы обычно могут сжиматься довольно хорошо.

Для общих данных вы говорите о 1 ГБ [исправлено 10 МБ] в день без сжатия. Вероятно, это сжимается до 100 МБ или меньше. Я видел 200-кратное сжатие в моих файлах журналов с помощью bzip2. Вы можете легко хранить сжатые данные в файловой системе в течение многих лет без каких-либо проблем. Для дополнительной обработки вы можете писать сценарии, которые могут искать сжатый tarball и генерировать больше статистики.

Ответ 4

Так как вы хотели бы сохранить их, чтобы иметь возможность вычислять разное. статистику по ним в ночное время, экспортировать их (упорядочено по дате поступления или первой строке контента)... Вы ожидаете 100 000 файлов в день, в общей сложности 10 000 000 строк:

Я бы предложил:

Храните все файлы в виде обычных текстовых файлов, используя следующий формат: yyyymmdd/manufacturerid/fileno.
В конце дня очистите базу данных и загрузите все текстовые файлы за день.
После загрузки файлов было бы легко получить статистику из базы данных и разместить их в любом формате. (может быть, даже другая база данных "статистики" ). Вы также можете генерировать графики.
Чтобы сэкономить место, вы можете сжать ежедневную папку. Поскольку они являются текстовыми файлами, они хорошо сжимаются.

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

Ответ 5

По моему опыту, одна большая таблица выполняет намного быстрее, чем несколько связанных таблиц, если мы говорим о решении базы данных. В частности, операции записи и удаления. Например, разделение одной таблицы на три связанные таблицы снижает производительность в 3-5 раз. Это очень грубо, конечно, это зависит от деталей, но, как правило, это риск. Ухудшается, когда объемы данных становятся очень большими. Лучший способ, IMO, хранить данные журнала не в плоском тексте, а в структурированной форме, так что вы можете делать эффективные запросы и форматирование позже. Управление файлами журналов может быть больно, особенно когда их много, и из многих источников и мест. Ознакомьтесь с нашим решением, IMO может сэкономить вам много времени на разработку.