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

Question

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

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

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

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

Любой совет?

Answer 1

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

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

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

Answer 2

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

Я не понимаю, зачем вам вообще нужна БД. Похоже, все, что вам нужно, это просмотреть данные. Держите журналы в самом «сыром» состоянии, затем обрабатывайте их, а затем создавайте tarball для каждого дня.

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

Answer 3

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

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

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

Answer 4

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

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

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

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

Answer 5

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