Вопрос по logging, language-agnostic, database – Хранение многих файлов журнала

10

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

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

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

Flat text files (with proper locking), one file per uploaded file, one directory per day/producer Flat text files, one (big) file per day for all producers (problem here will be indexing and locking) Database Table with text (MySQL is preferred for internal reasons) (pb with DB purge as delete can be very long !) Database Table with one record per line of text Database with sharding (one table per day), allowing simple data purge. (this is partitioning. However the version of mysql I have access to (ie supported internally) does not support it) Document based DB à la couchdb or mongodb (problem could be with indexing / maturity / speed of ingestion)

Любой совет ?

не совсем, ответ на то, что я спрашиваю, сильно влияет на развитие makapuf
Это вопрос системного администратора, что означает, что он принадлежит на дочернем сайте "Ошибка сервера" serverfault.com tylerl

Ваш Ответ

5   ответов
4

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

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

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

2

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

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

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

& quot; Вы говорите о 10 МБ в день без сжатия & quot; Нет, это 10 М ЛИНИЙ (10 000 пользователей * 10 файлов * 100 строк) в день. Если строка, скажем, 100 байтов, она больше 1 ГБ / день makapuf
1

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

Я предлагаю:

  1. Store all the files as regular textfiles using the following format : yyyymmdd/producerid/fileno.
  2. At the end of the day, clear the database, and load all the textfiles for the day.
  3. After loading the files, it would be easy to get the stats from the database, and post them in any format needed. (maybe even another "stats" database). You could also generate graphs.
  4. To save space ,you could compress the daily folder. Since they're textfiles, they would compress well.

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

0

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

Я проверю ваше решение. makapuf
Спасибо, но идея заключается в том, что таблицы не будут связаны друг с другом, например, по дням производства. Таким образом, запись в него изменит только одну таблицу. И удаление по дням будет реализовано как удаление таблицы. makapuf
8

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

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

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

Похожие вопросы