Какой подход лучше в журнале - файлы или БД?

Question

Хорошо, вот сценарий. У меня есть утилита, которая обрабатывает тонны записей и соответственно вводит информацию в базу данных.

Он работает с этими записями в многопоточных пакетах. Каждый такой пакет записывает в один и тот же файл журнала для создания трассировки рабочего процесса для каждой записи. Потенциально мы можем делать около миллиона записей в день.

Должен ли этот журнал быть внесен в базу данных, находящуюся на другом сервере? Соображения:

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

Есть ли какие-либо оптимизации, которые могут быть выполнены при любом подходе?

Спасибо.

Answer 1

Интересный вопрос, если вы решите войти в базу данных, где вы регистрируете ошибки подключения к базе данных?

Если я регистрируюсь в базе данных, у меня всегда есть дополнительное местоположение журнала (файл, журнал событий и т. Д.) На случай ошибок связи. Это действительно облегчает диагностику проблем позже.

Answer 2

Одна вещь, которая приходит на ум, - это то, что вы можете записать каждый поток в свой собственный файл журнала, а затем выполнять ежедневный пакетный запуск, чтобы объединить их.

Если вы входите в базу данных, вам, вероятно, потребуется выполнить некоторую настройку и оптимизацию, особенно если БД будет находиться в сети. По крайней мере, вам нужно будет повторно использовать соединения с БД.

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

Answer 3

Или как насчет входа в очередь? Таким образом, вы можете отключить опросы, когда захотите войти в разные вещи. Это делает такие вещи, как переворачивание и архивирование файлов журнала очень легко. Это также хорошо, потому что вы можете добавлять опрашивающие устройства, которые регистрируют разные вещи, например:

• программа для поиска сообщений об ошибках и отправки их в вашу учетную запись FogBugz
• средство проверки, которое ищет нарушения прав доступа ('x попытался получить доступ к /foo/y/bar.html') к файлу "попытки взлома"
• и т.д.

Answer 4

Не уверен, что это поможет, но есть также утилита под названием Microsoft LogParser , которую вы можете использовать для анализа текстовых файлов журналов и использования их, как если бы они были базой данных. С сайта:

Log parser - мощный, универсальный инструмент, который обеспечивает универсальный запрос доступ к текстовым данным, таким как журнал файлы, файлы XML и файлы CSV, а а также ключевые источники данных на Операционная система Windows®, такая как Журнал событий, реестр, файл система и Active Directory®. Вы расскажите Log Parser какую информацию вы нужно и как вы хотите это обработать. Результаты вашего запроса могут быть пользовательский формат в текстовом выводе, или они могут быть сохранены для более специальные цели, такие как SQL, SYSLOG или график. Большая часть программного обеспечения предназначена для выполнить ограниченное количество конкретные задачи. Log Parser is разные ... количество способов это может использоваться ограничено только потребностями и воображение пользователя. Мир - это ваша база данных с журналом Parser.

Я сам не использовал программу, но она кажется довольно интересной!

Answer 5

Я второй ответ здесь, зависит от того, что вы делаете с данными .

У нас есть два сценария:

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

2. Мы регистрируем всю нашу диагностику и отладочную информацию в файл. Нам не нужно действительно «делать предварительные расчеты» для него и для ТБХ, нам это даже не нужно часто, поэтому мы просто регистрируем и архивируем большую часть.

Я бы сказал, что если пользователь что-то с ним делает, то войдите в БД, если он для вас, то файла, вероятно, будет достаточно.

Answer 6

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

Answer 7

Есть способы обойти ограничения ведения журнала файлов.

Вы можете всегда начинать каждую запись в журнале с какого-либо идентификатора потока и извлекать отдельные идентификаторы потока. Или другой файл журнала для каждого потока.

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

Answer 8

База данных - так как вы упомянули несколько потоков. Синхронизация, а также фильтрованный поиск - мои причины для моего ответа.
Посмотрите, есть ли у вас проблемы с производительностью, прежде чем переходить к файлам
"Кнут: преждевременная оптимизация - корень всего зла", в этой книге я больше ничего не узнал ...

Answer 9

Мне нравится ответ Гая. Поместите все операторы журнала в потокобезопасную очередь, а затем обработайте их оттуда. Для БД вы можете их пакетировать, скажем, 100 операторов журнала в одном пакете, а для файла вы можете просто направить их в файл по мере поступления в очередь.

Файл или БД? Как говорят многие другие; это зависит от того, для чего вам нужен файл журнала.

Answer 10

Я думаю, это во многом зависит от того, что вы делаете с файлами журналов впоследствии.

Из двух операций запись в файл журнала будет быстрее - особенно если вы предлагаете запись в базу данных на другом сервере.

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

Если вы используете каркас журналирования, такой как log4net, он часто предоставляет простые способы перенаправления ввода в файл или базу данных на основе файла конфигурации.