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

Question

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

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

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

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

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

Answer 1

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

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

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

Answer 2

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

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

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

Answer 3

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

Answer 4

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

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

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

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

Answer 5

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

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

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