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

Question

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

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

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

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

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

Спасибо.

Answer 1

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

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

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

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

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

Answer 2

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

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

Answer 3

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

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

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

Answer 4

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

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

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

Answer 5

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

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

Answer 6

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

Answer 7

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

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

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

Answer 8

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

Answer 9

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

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

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

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

Answer 10

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

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