Какой подход к ведению журнала лучше - файлы или БД?
Хорошо, вот сценарий. У меня есть утилита, которая обрабатывает множество записей и соответственно вводит информацию в базу данных.
Он работает с этими записями в многопоточных пакетах. Каждый такой пакет записывает в один и тот же файл журнала для создания трассировки рабочего процесса для каждой записи. Потенциально мы могли бы делать около миллиона записей в журнал в день.
Следует ли преобразовать этот журнал в базу данных, расположенную на другом сервере? Соображения:
- Очевидным недостатком записи нескольких потоков в один и тот же файл журнала является то, что сообщения журнала перемешиваются друг с другом. В базе данных их можно сгруппировать по идентификатору партии.
- Производительность - что еще больше замедлит пакетную обработку? запись в локальный файл или отправка данных журнала в базу данных на другом сервере в той же сети. Теоретически файл журнала работает быстрее, но есть ли здесь ошибка?
Есть ли какие-либо оптимизации, которые можно сделать при любом подходе?
Спасибо.
Ответы 10
Я думаю, это во многом зависит от того, что вы потом делаете с файлами журнала.
Из двух операций запись в файл журнала будет быстрее, особенно если вы предлагаете запись в базу данных на другом сервере.
Однако, если вы затем пытаетесь регулярно обрабатывать и искать файлы журнала, лучшим местом для этого будет база данных.
Если вы используете структуру ведения журнала, такую как log4net, они часто предоставляют простые способы перенаправления ввода в файл или базу данных на основе файла конфигурации.
База данных - поскольку вы упомянули несколько потоков. Причина моего ответа - синхронизация, а также отфильтрованное извлечение.
Посмотрите, есть ли у вас проблемы с производительностью, прежде чем переходить на файлы
«Кнут: Преждевременная оптимизация - корень всех зол» В этой книге я не продвинулся дальше ... :)
Есть способы обойти ограничения ведения журнала файлов.
Вы всегда можете начинать каждую запись журнала с какого-либо идентификатора потока и извлекать идентификаторы отдельных потоков. Или отдельный файл журнала для каждого потока.
Раньше я входил в базу данных в отдельном потоке с более низким приоритетом. Я должен сказать, что возможность запросов очень важна, когда вы пытаетесь выяснить, что пошло не так.
Я поддерживаю другие ответы здесь, зависит от того, что вы делаете с данными.
У нас есть два сценария:
Большая часть журналов ведется в БД, поскольку пользователи-администраторы для продуктов, которые мы создаем, должны иметь возможность просматривать их в своем красивом маленьком приложении со всеми навороченными функциями.
Мы записываем всю нашу диагностику и отладочную информацию в файл. Нам не нужно по-настоящему «приукрашивать» его и TBH, нам это даже не часто нужно, поэтому мы просто регистрируем и архивируем по большей части.
Я бы сказал, что если пользователь что-то с ним делает, то войдите в БД, если это для вас, то файла, вероятно, будет достаточно.
Как насчет записи в файл базы данных, скажем, в базу данных SQLite? Я думаю, что он может обрабатывать многопоточную запись - хотя это также может иметь свои собственные накладные расходы на производительность.
На ум приходит одна вещь: каждый поток может записывать в свой собственный файл журнала, а затем выполнять ежедневный пакетный запуск для их объединения.
Если вы регистрируетесь в базе данных, вам, вероятно, потребуется выполнить некоторую настройку и оптимизацию, особенно если база данных будет находиться в сети. По крайней мере, вам нужно будет повторно использовать соединения с БД.
Кроме того, есть ли у вас какие-либо особые потребности иметь журнал в базе данных? Если все, что вам нужно, это "grep", то я не думаю, что вы многого добьетесь, войдя в базу данных.
Интересный вопрос: если вы решите войти в базу данных, где вы регистрируете ошибки подключения к базе данных?
Если я регистрируюсь в базе данных, у меня всегда есть вторичное расположение журнала (файл, журнал событий и т. д.) На случай ошибок связи. Это действительно упрощает последующую диагностику проблем.
Не уверен, что это помогает, но есть также утилита под названием Microsoft LogParser, которую вы предположительно можете использовать для анализа текстовых файлов журналов и использования их, как если бы они были базой данных. С веб-сайта:
Log parser is a powerful, versatile tool that provides universal query access to text-based data such as log files, XML files and CSV files, as well as key data sources on the Windows® operating system such as the Event Log, the Registry, the file system, and Active Directory®. You tell Log Parser what information you need and how you want it processed. The results of your query can be custom-formatted in text based output, or they can be persisted to more specialty targets like SQL, SYSLOG, or a chart. Most software is designed to accomplish a limited number of specific tasks. Log Parser is different... the number of ways it can be used is limited only by the needs and imagination of the user. The world is your database with Log Parser.
Сам программой не пользовался, но она интересная!
А как насчет входа в очередь? Таким образом, вы можете отключать поллеры, когда захотите войти в разные вещи. Это упрощает такие вещи, как перенос и архивирование файлов журналов. Это также приятно, потому что вы можете добавлять поллеры, которые регистрируют разные вещи, например:
- опросчик, который ищет сообщения об ошибках и отправляет их в вашу учетную запись FogBugz
- опросчик, который ищет нарушения доступа ('x пытался получить доступ /foo/y/bar.html') к файлу 'попытки взлома'
- и Т. Д.
Мне нравится ответ Гая. Поместите все операторы журнала в потокобезопасную очередь, а затем обработайте их оттуда. Для DB вы можете объединить их, скажем, 100 операторов журнала в одном пакете, а для файла вы можете просто передать их в файл по мере их поступления в очередь.
Файл или БД? Как говорят многие; это зависит от того, для чего вам нужен файл журнала.
LogParser работает хорошо. Однако это не самая быстрая вещь в слове с действительно большим файлом. lizardl.com/… Log Parser Lizard - это красивый графический интерфейс, работающий поверх LogParser.