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

44

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

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

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

— Ясир
источник

10

Итак, как бы вы регистрировали ошибки БД (например, БД недоступна), если ваша система журналирования записывает в БД?

— Марьян Венема

17

@Marjan Как бы я регистрировать ошибки файловой системы, если она не удается ?!

— Ясир

5

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

— Марьян Венема

2

@Yasir: отправьте все сообщения журнала на сервер системного журнала перед входом в файловую систему :)

— Брайан,

1

@MarjanVenema что если игра бессмысленна. Что делать, если локальный диск заполнен, ваша регистрация не будет выполнена, но приложение и ОС могут продолжать работу. Если вы входите на удаленный сервер БД, вы все равно сможете войти. Есть плюсы и минусы для хранения журнальных сообщений, и что лучше всего зависит от того, что вы пытаетесь получить из журналов. Извините, я позволю стаду вернуться к журналу файлов - единственный верный путь.

— Энди

37

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

— user281377
источник

1

Я попробовал этот эксперимент, и он не удался. СУБД основана на идее, что данные записываются относительно редко по сравнению с тем, сколько раз они читаются. Ведение журнала в основном наоборот. Ты пишешь все время и читаешь редко. Это отличный способ раздражать вашего администратора.

— JimmyJames

1

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

— user281377

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

— JimmyJames

№ 4 на самом деле не проблема. DELETE FROM dbo.Log WHERE LogDate < today minus 2 weeks

— Роберт Харви

@ RobertHarvey Это работает хорошо, пока вы не попробуете его в среде с высокой нагрузкой, где такие массовые операции могут вызвать серьезные проблемы без дополнительных мер предосторожности. Повторите журналы, заполняющие ваше дисковое пространство, отмена табличного пространства становится слишком полной, репликация становится очень занятой репликацией удаления и т. Д.

— user281377

16

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

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

— gbjbaanb
источник

Но у меня есть путаница для этого. Мой блокнот, WordPad, Gedit или Notepad ++ или любой веб-браузер не будут рады открыть файл размером 4 ГБ. Однако тот же браузер сможет показать мне список из тысячи страниц, каждая из которых содержит 500 напечатанных записей. Правильно?

— Ясир

7

@Yasir, потому что вы используете редакторы, которые пытаются загрузить весь файл в память. Попробуйте использовать более умный редактор, способный «транслировать» большой файл. Vim хороший пример.

— Нахли

6

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

— unholysampler

5

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

— Энди

2

@ gbjbaanb Я не нашел это переоцененным, и, честно говоря, вы предлагаете использовать линии меток, вырезать и вставлять для запроса, это шутка. Это не просто поиск, мы проанализировали тенденции, чтобы найти серверы, у которых было больше проблем, чем у других, какие ошибки чаще всего встречали пользователи и т. Д.

— Энди

15

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

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

— tdammers
источник

3

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

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

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

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

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

— unholysampler
источник

Очевидно, что любой и все может потерпеть неудачу, если мы не будем осторожны. Но по этому вопросу я ссылался на программиста высокого уровня. В качестве простого примера, программист может захотеть разделить значения, используя определенный символ. Таким образом, его / ее регулярное выражение будет работать как шарм, но потерпит неудачу, когда тот же символ содержится в блоке значений. Таким образом, ему нужно позаботиться о похожих случаях, и ему не нужно думать о них, если он сохранял в БД. Кроме того, не могли бы вы посмотреть мой комментарий к ответу gbjbaanb?

— Ясир

1

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

— unholysampler

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

— Энди

2

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

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

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

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

— Жюль
источник

1

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

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

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

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

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

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

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

— Ли Райан
источник

0

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

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

Вкратце:

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

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

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

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

— ojrask
источник

-2

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

— noonex
источник

1

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

— Адам Цукерман,

В самом деле? SqlLite увеличивает сложность астрономически? И хотя веб-серверу обычно не требуется БД, многие LOB-приложения уже используют его, поэтому никаких дополнительных затрат там нет.

— Энди

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

— noonex

@ И прежде всего, SQLite - это не RDBMS в классическом виде - это «встроенная RDBMS». И да - требование SQLite для ведения журналов значительно усложнит работу.

— noonex

1

@noonex Вы просто произвольно проводите различие между встроенным и полным сервером, а СУБД - нет. SqlLite обеспечивает соответствие ACID, что на самом деле является основой RDBMS. И это сильно увеличивает сложность? Я могу только представить, что вы не работали ни с чем, кроме самых тривиальных приложений. Наконец, хорошая работа, полностью игнорирующая мою точку зрения о том, что многим LOB-приложениям все равно нужна база данных.

— Энди

-4

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

Скорость.

— С. Лотт
источник