Почему файловая система предпочтительна для журналов вместо СУБД?

Вопрос должен быть понятен из его названия. Например, Apache сохраняет свои журналы доступа и ошибок в файлах вместо СУБД, независимо от того, насколько они используются в больших или малых масштабах.

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

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

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

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

3. Многие вещи, которые стоит регистрировать, происходят во время запуска, например, возможно, до того, как соединение с базой данных было установлено.

4. В обычной конфигурации новый файл журнала создается каждый день, старые файлы журнала сжимаются и хранятся в течение 2 недель, а затем удаляются. Нелегко сделать то же самое в СУБД.

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

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

Скорость - одна из причин; другие:

• Устранение точек отказа. Файловая система редко дает сбой в условиях, когда СУБД не будет, но в базах данных есть много и много ошибок, которые просто не существуют в файловых системах.
• Низкотехнологичная доступность. Если дела пойдут действительно плохо, вы можете загрузиться в спасательную оболочку или смонтировать диск в другой системе, и при этом у вас останется достаточно инструментов для проверки файлов журнала. Если это база данных, вы нигде не работаете с сервером баз данных.

Прежде всего.

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

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

Запись в текстовый файл имеет ряд преимуществ, наиболее важным из которых является

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

Вы поднимаете Apache специально, поэтому я буду обсуждать это подробно.

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

Когда я делал это, у меня также возникали проблемы с надежностью: если буфер записи сервера базы данных заполнен (что может случиться с mysql, если вы используете квоту файловой системы для пользователя, под которым он работает), он начинает ставить запросы в очередь, пока они не смогут чтобы продолжить, в этот момент Apache начинает ждать его завершения, что приводит к зависанию запросов на ваш веб-сайт.

(Конечно, теперь эта проблема может быть исправлена ​​- это было много лет назад)

Файловая система - это база данных. Это действительно более простая иерархическая база данных, чем реляционная СУБД, но, тем не менее, это база данных.

Причина, по которой запись в файловую систему популярна, заключается в том, что текстовые журналы хорошо сочетаются с философией Unix: «Текст - это универсальный интерфейс».

Unix разработал множество инструментов общего назначения, которые могут хорошо работать с текстовыми журналами. Не имеет значения, производятся ли текстовые журналы mysql, apache, вашим пользовательским приложением, сторонним программным обеспечением, которое давно не поддерживается, системный администратор может использовать стандартные инструменты Unix, такие как grep, sed, awk, sort, uniq, cut, tail и т. д., чтобы трал через логи все равно.

Если каждое приложение регистрирует свою собственную базу данных, одно в MySQL, другое в Postgres, другое в Elasticsearch, другое хочет войти в ELK, другое может войти только в MongoDB, тогда вам придется изучить двадцать различных инструментов для траления журналов каждого из них. применение. Текст - это универсальная среда, в которую каждый может войти.

Даже если вам удастся сделать так, чтобы все журналы передавались в одну базу данных, скажем, MySQL, вы можете обнаружить, что каждое приложение хотело бы вести журнал с разными схемами таблиц, поэтому вам все равно придется написать специальный инструмент для запроса журналов для каждого из них. применение. И если вы каким-то образом заполонили все приложения для входа в единую схему, вы, вероятно, обнаружите, что эта общая схема не может действительно рассказать вам полную историю каждого приложения, поэтому вам все равно придется разбирать тексты журналов в любом случае.

Вход в базу данных часто не делает вещи значительно проще на практике.

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

Давайте посмотрим на это в несколько слоев:

1. Машинный слой
2. Уровень операционной системы
3. Сервисный уровень
4. Прикладной уровень

Вкратце:

• На машинном уровне вы действительно не можете делать журналы, кроме как какие-то дампы.
• На уровне ОС вы можете вести логи, но на самом деле у вас есть только файловая система.
• Службы могут регистрироваться в файловой системе, но они не могут доверять другим службам, поэтому они не могут войти туда.
• Приложения могут войти в сервисы и файловую систему.

Тогда у нас есть подход на основе варианта использования:

Хотите ли вы регистрировать ошибки, специфичные для узла, в СУБД с горизонтальным масштабированием, где вам нужно выполнить дополнительную работу, чтобы найти ошибку конкретного узла, когда вы могли бы просто открыть крышку для одного узла и увидеть ее там? С другой стороны, ваше приложение, возможно, должно регистрироваться в СУБД для сбора ошибок и уведомлений на уровне приложения.

Что происходит, когда СУБД необходимо вести запись для себя, потому что в базу данных невозможно записать?

Сложность. Добавление RDBMS увеличит сложность всей системы астрономически. А умение управлять сложностью - это главное, что отличает программистов от производителей исходного кода.

Это скорость или ремонтопригодность или что-то еще?

Скорость.