Чому файлова система віддається перевазі журналам замість RDBMS?

Питання має бути зрозумілим з назви. Наприклад, Apache зберігає свої журнали доступу та помилок у файлах замість RDBMS незалежно від того, наскільки великі чи малі масштаби вони використовуються.

Для RDMS нам просто потрібно писати SQL запити, і це зробить роботу, тоді як для файлів ми повинні визначити певний формат, а потім записати регулярний вираз або може бути парсерами для маніпулювання ними. І вони можуть навіть зазнати невдачі за певних обставин, якби велика турбота не була б оплачена.

Але, схоже, всі віддають перевагу файловій системі для ведення журналів. Я не упереджений жодним із цих методів, але хотів би знати, чому це практикується таким чином. Це швидкість чи ремонтопридатність чи щось інше?

1. Забагато речей може вийти з ладу з базою даних, і важливе значення має також реєстрація цих відмов.

2. Якщо у вас немає системи баз даних, яка дозволяє здійснювати автономні транзакції (або взагалі відсутні транзакції), для ведення журналу потрібно буде окреме з'єднання, тому відкат або фіксація в журналі не перешкоджає відкату чи фіксації в програмі.

3. Багато речей, які варті реєстрації, відбуваються під час запуску, тобто, можливо, до встановлення з'єднання з базою даних.

4. У випадку типової установки щодня створюється новий файл реєстрації, старі файли журналів стискаються та зберігаються протягом 2 тижнів, перш ніж врешті видаляються. Зробити те ж саме в RDBMS непросто.

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

Основні причини - швидкість та розмір, що дозволяє деяким відстежувати можливість створювати величезні, величезні якості ведення журналу - я пробирав гігабайти файлів журналів за розміром. Інша основна причина полягає в тому, що читання журналів має бути послідовним, реально не потрібно запитувати журнал, за винятком того, щоб знайти певну помилку або запис - і пошук-файл працює для цього чудово.

Швидкість - одна з причин; інші:

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

По-перше.

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

Операції з базою даних не можуть вийти з ладу, якщо ви не обережні?

Запис у текстовий файл має ряд переваг, найважливіший

• Текст читається людиною. Будь-хто може відкрити файл журналу з основним текстовим редактором і побачити, що таке повідомлення. Вам не потрібно розуміти, як організована база даних.
• Швидкість. Запис тексту на диск набагато швидше, ніж служба бази даних з'ясовує, куди йде текст у базу даних, записуючи її туди та забезпечуючи завершення транзакції.

Ви спеціально піднімаєте Apache, тож я детально це обговорю.

Apache можна налаштувати для входу в базу даних, хоча для цього потрібен зовнішній плагін . Використання такого плагіна може полегшити аналіз журналу, але лише якщо ви маєте намір написати власне програмне забезпечення для аналізу журналів. Стандартні аналізатори журналу, що не перебувають на полиці, припускають, що ваші журнали містяться у файлах, тому використовувати їх ви не зможете.

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

(Це питання зараз може бути виправлене, звичайно - я робив це багато років тому)

Файлова система - це база даних. Це дійсно простіша ієрархічна база даних замість реляційної СУБД, але все ж це база даних.

Причина, чому вхід у файлову систему популярний, полягає в тому, що текстові журнали добре поєднуються з філософією Unix: "Текст - це універсальний інтерфейс".

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

Якщо кожен додаток записується у власну базу даних, один у MySQL, інший у Postgres, інший у Elasticsearch, інший хоче увійти до ELK, інший може увійти лише до MongoDB, тоді вам доведеться вивчити двадцять різних інструментів для проходження журналів кожного застосування. Текст - це універсальний носій, на який кожен може увійти.

Навіть коли вам вдасться зробити так, щоб усі журнали переходили до однієї бази даних, скажімо, MySQL, ви можете виявити, що кожна програма хотіла б увійти в систему з різними схемами таблиці, тому вам все одно доведеться писати індивідуальний інструмент для запитів журналів для кожного застосування. І якщо ви якимось чином забили всі програми, щоб увійти до однієї схеми, ви, ймовірно, виявите, що ця загальна схема насправді не могла розповісти вам повну історію кожної програми, тому вам все одно доведеться розбирати тексти журналів у будь-якому випадку.

Реєстрація в базі даних часто насправді не суттєво полегшує справи.

Реєстрація в базі даних може бути корисною, якщо ви маєте на увазі конкретний аналіз, який ви маєте на увазі, або для конкретних вимог щодо збереження аудиту, для яких ви можете створити конкретну схему бази даних, щоб збирати лише дані для цих конкретних цілей. Але для криміналістичної та налагоджувальної роботи та, коли ви збираєте журнал, не маючи на увазі конкретної мети, текстові журнали, як правило, досить хороші, що витрати на навчання чи створення спеціалізованих інструментів часто не варті.

Давайте розглянемо це в декілька шарів:

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

Коротко:

• На машинному шарі ви справді не можете вести журнал, крім якогось відвалу.
• На шарі ОС ви можете вести журнал, але у вас дійсно доступна лише файлова система.
• Служби можуть увійти до файлової системи, але вони не можуть довіряти запуску інших служб, тому вони не можуть там увійти.
• Програми можуть увійти до служб та файлової системи

Тоді у нас є підхід на основі використання:

Чи хочете ви зафіксувати помилки, пов’язані з вузлом, в RDBMS, що горизонтально масштабується, де потрібно виконати додаткову роботу, щоб знайти помилку конкретного вузла, коли ви могли просто відкрити капот для одного вузла і побачити його там? З іншого боку, ваша програма, можливо, має зайти в RDBMS, щоб збирати помилки та повідомлення на рівні програми.

Що трапляється, коли RDBMS потребує реєстрації для себе, оскільки база даних не може бути записана?

Складність. Додавання RDBMS збільшить складність всієї системи астрономічно. А вміння керувати складністю - це головне, що відрізняє програмістів від виробників вихідного коду.

Це швидкість чи ремонтопридатність чи щось інше?

Швидкість.