Dlaczego system plików jest preferowany dla dzienników zamiast RDBMS?

44

Pytanie powinno jasno wynikać z tytułu. Na przykład Apache zapisuje swoje dzienniki dostępu i dzienniki błędów w plikach zamiast RDBMS bez względu na to, jak duży lub mały jest wykorzystywany.

W przypadku RDMS musimy po prostu pisać zapytania SQL, a to zadziała, podczas gdy w przypadku plików musimy zdecydować się na konkretny format, a następnie napisać wyrażenie regularne lub być parserami, aby nimi manipulować. A mogą nawet zawieść w szczególnych okolicznościach, jeśli nie zostanie zachowana wielka ostrożność.

Jednak wydaje się, że wszyscy wolą system plików do zarządzania dziennikami. Nie jestem stronniczy w stosunku do żadnej z tych metod, ale chciałbym wiedzieć, dlaczego jest to praktykowane w ten sposób. Czy to szybkość, łatwość konserwacji, czy coś innego?

— Yasir
źródło

10

Jak więc zapisywać błędy DB (na przykład db niedostępne), jeśli system logowania loguje się do DB?

— Marjan Venema

17

@Marjan Jak miałbym rejestrować błędy systemu plików, jeśli się nie powiedzie ?!

— Yasir

5

To prawda, ale jeśli to się nie powiedzie, istnieje prawdopodobieństwo, że twoja baza danych jest również niedostępna ... W końcu gdzie / jak zapisałby do swoich tabel bez systemu plików?

— Marjan Venema,

2

@Yasir: Wyślij wszystkie wiadomości dziennika do serwera syslog przed zalogowaniem do systemu plików :)

— Brian

1

@MarjanVenema, co jeśli gra jest bezcelowa. Co się stanie, jeśli dysk lokalny jest pełny, rejestracja nie powiedzie się, ale aplikacja i system operacyjny mogą kontynuować. Jeśli logujesz się na zdalnym serwerze DB, nadal będziesz mógł się zalogować. Są albo plusy i minusy, które można przechowywać w dziennikach, a najlepsze z nich zależy od tego, co próbujesz wydostać z rejestrowania. Przepraszam, ale pozwolę stadzie wrócić do dziennika plików to jedyny prawdziwy sposób.

— Andy,

37

Zbyt wiele rzeczy może zawieść w bazie danych i rejestrowanie tych awarii jest również ważne.
O ile nie masz systemu bazy danych, który umożliwia autonomiczne transakcje (lub w ogóle żadnych transakcji), rejestrowanie wymagałoby osobnego połączenia, aby wycofanie lub zatwierdzenie w dzienniku nie zakłócało wycofania lub zatwierdzenia w aplikacji.
Wiele rzeczy, które warto zarejestrować, dzieje się podczas uruchamiania, np. Przed nawiązaniem połączenia z bazą danych.
W typowej konfiguracji nowy dziennik jest tworzony codziennie, stare pliki dziennika są kompresowane i przechowywane przez 2 tygodnie, zanim zostaną ostatecznie usunięte. To samo nie jest łatwe w RDBMS.

— użytkownik 281377
źródło

1

Próbowałem tego eksperymentu i nie poszło dobrze. RDBMS został zaprojektowany wokół idei, że dane są zapisywane stosunkowo rzadko w stosunku do liczby odczytów. Logowanie jest w zasadzie odwrotne. Piszesz cały czas i rzadko czytasz. To świetny sposób na zirytowanie DBA.

— JimmyJames,

1

Można jednak rozważyć użycie systemu baz danych szeregów czasowych, takiego jak InfluxDB, do prowadzenia dzienników; wydaje mi się, że jest nieco lepiej przystosowany do tego zadania niż na przykład PostgreSQL. Nadal jednak nie ma przewagi nad staromodnymi plikami dziennika.

— user281377,

Korzystanie z nierelacyjnej bazy danych z indeksowaniem tokenów itp. Jest zdecydowanie przydatne i jeśli mądrze wybierzesz, mogą poradzić sobie z wężem ogniowym. Jest to część tego, jak działają takie rzeczy, jak splunk i flume.

— JimmyJames,

# 4 nie jest tak naprawdę problemem. DELETE FROM dbo.Log WHERE LogDate < today minus 2 weeks

— Robert Harvey

@RobertHarvey Działa to dobrze, dopóki nie spróbujesz w środowisku o dużym obciążeniu, gdzie takie operacje masowe mogą powodować poważne problemy bez dodatkowych środków ostrożności. Ponów dzienniki wypełniające miejsce na dysku, cofnij zapełnianie się obszaru tabel, replikacja jest bardzo zajęta replikacją usuwania itp.

— 281377

16

Widziałem wcześniej dzienniki zapisywane w bazie danych (a czasem masz konfigurowalne opcje rejestrowania, gdzie śledzenie trafia do pliku, błędy do bazy danych, fatale do dziennika zdarzeń systemu Windows).

Głównymi przyczynami są szybkość i rozmiar, dzięki czemu niektóre śledzenie może generować ogromne, ogromne ilości rejestrowania - przeszukiwałem pliki dzienników o wielkości gigabajtów. Innym głównym powodem jest to, że czytanie dzienników musi odbywać się sekwencyjnie, nie ma potrzeby sprawdzania dziennika, z wyjątkiem znalezienia określonego błędu lub wpisu - a funkcja znajdowania w pliku działa w tym przypadku doskonale.

— gbjbaanb
źródło

Ale mam do tego zamieszanie. Mój notatnik, wordpad, gedit lub notatnik ++ lub dowolna przeglądarka internetowa nie będzie zadowolona z otwarcia pliku o wielkości 4 GB. Ta sama przeglądarka będzie jednak w stanie wyświetlić mi listę tysięcy stron, z których każda zawiera 500 wydrukowanych rekordów. Dobrze?

— Yasir

7

@Yasir, ponieważ używasz edytorów, które próbują załadować cały plik do pamięci. Spróbuj użyć inteligentniejszego edytora, który jest w stanie „przesyłać strumieniowo” duży plik. Vim jest dobrym przykładem.

— nakhli

6

@Yasir: To prawda, ale próbujesz zoptymalizować niewłaściwą rzecz. Zdecydowana większość dzienników jest zapisywana i nigdy nie czytana. Dzięki temu tworzenie dzienników jest bardzo szybkie, ponieważ jest to powszechny przypadek.

— unholysampler

5

Ech, wcześniej rejestrowałem się w bazie danych, a możliwość łatwego przeszukiwania komunikatów w dzienniku była niezwykle korzystna, szczególnie gdy włączamy rejestrowanie na poziomie debugowania, aby wyśledzić trudny do odtworzenia błąd.

— Andy,

2

@ gbjbaanb Nie uważałem, że jest to przereklamowane, i szczerze mówiąc sugerujesz, że używanie linii oznaczania oraz wycinanie i wklejanie do zapytania to żart. Nie chodzi tylko o wyszukiwanie, analizowaliśmy trendy, aby znaleźć serwery, które miały więcej problemów niż inne, jakie błędy najczęściej widywali użytkownicy itp.

— Andy

15

Szybkość jest jednym z powodów; inni są:

Eliminowanie punktów awarii. System plików rzadko zawodzi w warunkach, w których DBMS by tego nie zrobił, ale w bazach danych jest wiele warunków błędów, które nie istnieją w systemach plików.
Niska dostępność technologiczna. Jeśli coś pójdzie naprawdę źle, możesz uruchomić się w powłoce ratunkowej lub zamontować dysk w innym systemie i nadal mieć odpowiednie narzędzia do sprawdzania plików dziennika. Jeśli jest to baza danych, nigdzie nie ma uruchomionego serwera bazy danych.

— tdammers
źródło

3

Po pierwsze.

A mogą nawet zawieść w szczególnych okolicznościach, jeśli nie zostanie zachowana wielka ostrożność.

Transakcje w bazie danych nie mogą zawieść, jeśli nie jesteś ostrożny?

Pisanie do pliku tekstowego ma wiele zalet, z których najważniejszą jest

Tekst jest czytelny dla ludzi. Każdy może otworzyć plik dziennika za pomocą prostego edytora tekstu i zobaczyć, jakie są wiadomości. Nie musisz rozumieć, w jaki sposób baza danych jest zorganizowana.
Prędkość. Zapisywanie tekstu na dysk jest znacznie szybsze niż w przypadku usługi bazodanowej ustalającej, gdzie tekst trafia do bazy danych, zapisującej ją i zapewniającej zakończenie transakcji.

— unholysampler
źródło

Oczywiście wszystko i wszystko może zawieść, jeśli nie będziemy ostrożni. Ale w przypadku tego pytania miałem na myśli programistę wysokiego poziomu. Jako prosty przykład programista może chcieć oddzielić wartości za pomocą określonego znaku. Tak więc jego regex będzie działał jak urok, ale zawiedzie, gdy ta sama postać znajduje się w bloku wartości. W ten sposób musi zająć się podobnymi możliwymi przypadkami i nie musi o nich myśleć, jeśli oszczędzał w DB. Czy widzisz również mój komentarz do odpowiedzi gbjbaanb?

— Yasir

1

A jeśli piszesz ręcznie swój SQL, masz ten sam problem. Różnica polega na tym, że zapis nie powiedzie się (lub nie uszkodzi danych) zamiast nieco irytować programistę, ponieważ jego ciąg wyszukiwania przyniósł złe wyniki. Tak, istnieją ramy, które oznaczają, że nie musisz pisać SQL, ale każda dodatkowa warstwa spowalnia proces. I pamiętaj, że to tylko logowanie. Każdy cykl, którego używasz do logowania, to cykl, którego nie używasz do prawdziwej pracy.

— unholysampler

@unholysampler Twój argument wydajności jest słaby, rejestrowanie może być wykonane bardzo szybko i na wątku w tle do bazy danych, a logowanie do f, podczas gdy potencjalnie szybsze, nadal nie jest wolne, szczególnie jeśli nie jest zrobione w tle.

— Andy,

2

W szczególności wychowujesz Apache, więc omówię to szczegółowo.

Apache można skonfigurować tak, aby logował się do bazy danych, chociaż wymaga do tego zewnętrznej wtyczki . Korzystanie z takiej wtyczki może ułatwić analizę logów, ale tylko jeśli zamierzasz napisać własne oprogramowanie do analizy logów. Standardowe standardowe analizatory dzienników zakładają, że twoje dzienniki są w plikach, więc nie będziesz mógł ich używać.

Kiedy to robiłem, wystąpiły również problemy z niezawodnością: jeśli bufor bufora zapisu serwera bazy danych jest zapełniony (co może się zdarzyć w przypadku mysql, jeśli zużyjesz limit systemu plików dla użytkownika, na którym działa), zaczyna kolejkować zapytania, dopóki nie będą w stanie aby kontynuować, w tym momencie Apache zaczyna czekać na zakończenie, powodując zawieszenie żądań na twojej stronie internetowej.

(Ten problem można teraz oczywiście naprawić - zrobiłem to wiele lat temu)

— Jules
źródło

1

System plików to baza danych. To rzeczywiście prostsza, hierarchiczna baza danych zamiast relacyjnego DBMS, ale mimo to baza danych.

Powodem, dla którego logowanie do systemu plików jest popularne, jest fakt, że dzienniki tekstowe dobrze pasują do filozofii Uniksa: „Tekst jest uniwersalnym interfejsem”.

Unix opracował wiele narzędzi ogólnego przeznaczenia, które mogą dobrze współpracować z logami tekstowymi. Nie ma znaczenia, czy dzienniki tekstowe są tworzone przez mysql, apache, aplikację niestandardową, oprogramowanie innych firm, które już dawno nie jest obsługiwane, sysadmin może używać standardowych narzędzi uniksowych, takich jak grep, sed, awk, sortować, uniq, cut, tail itd., aby mimo wszystko przeszukiwać kłody.

Jeśli każda aplikacja loguje się do własnej bazy danych, jedna do MySQL, inna do Postgres, inna do Elasticsearch, inna chce zalogować się do ELK, inna może zalogować się tylko do MongoDB, wtedy musisz nauczyć się dwudziestu różnych narzędzi do przeszukiwania dzienników każdego podanie. Tekst to uniwersalne medium, na którym każdy może się zalogować.

Nawet jeśli uda ci się to zrobić, aby wszystkie dzienniki trafiły do jednej bazy danych, powiedzmy MySQL, możesz zauważyć, że każda aplikacja będzie chciała logować się przy użyciu różnych schematów tabel, więc nadal będziesz musiał napisać niestandardowe narzędzie do zapytania dzienników dla każdego podanie. A jeśli w jakiś sposób wcisnąłeś wszystkie aplikacje, aby zalogować się do jednego schematu, prawdopodobnie okaże się, że ten ogólny schemat nie byłby w stanie opowiedzieć pełnej historii każdej aplikacji, więc i tak musisz przeanalizować teksty dziennika.

Logowanie do bazy danych często w praktyce wcale nie ułatwia pracy.

Logowanie do bazy danych może być przydatne, gdy masz konkretną analizę, o której myślisz, lub w celu spełnienia określonego wymogu przechowywania audytu, dla którego możesz zaprojektować określony schemat bazy danych, aby gromadzić tylko dane do tych konkretnych celów. Ale w przypadku kryminalistyki i debugowania oraz podczas zbierania dziennika bez określonego celu dzienniki tekstowe są zwykle wystarczająco dobre, aby koszt nauki lub tworzenia specjalistycznych narzędzi często nie był tego wart.

— Lie Ryan
źródło

0

Spójrzmy na to na kilku warstwach:

Warstwa maszyny
Warstwa systemu operacyjnego
Warstwa usługowa
Warstwa aplikacji

W skrócie:

Na warstwie maszyny naprawdę nie można rejestrować inaczej niż jakieś zrzuty.
W warstwie systemu operacyjnego można rejestrować, ale tak naprawdę dostępny jest tylko system plików.
Usługi mogą logować się do systemu plików, ale nie mogą ufać, że inne usługi będą działały, więc nie mogą się tam zalogować.
Aplikacje mogą logować się do usług i systemu plików.

Następnie mamy podejście oparte na przypadkach użycia:

Czy chcesz rejestrować błędy specyficzne dla węzłów w poziomo skalowanym systemie RDBMS, w którym musisz podjąć dodatkową pracę, aby znaleźć błąd określonego węzła, gdy możesz po prostu otworzyć pokrywę dla jednego węzła i zobaczyć go tam? Z drugiej strony aplikacja prawdopodobnie powinna zalogować się do RDBMS, aby zebrać błędy i powiadomienia na poziomie aplikacji.

Co dzieje się, gdy RDBMS musi sam się zarejestrować, ponieważ nie można zapisać bazy danych?

— ojrask
źródło

-2

Złożoność. Dodanie RDBMS zwiększy astronomicznie złożoność całego systemu. A umiejętność zarządzania złożonością jest najważniejszą rzeczą, która odróżnia programistów od producentów kodu źródłowego.

— noonex
źródło

1

Czy możesz rozwinąć to, co masz na myśli mówiąc o złożoności, ponieważ odnosi się ona do logowania do bazy danych w porównaniu do systemu plików? Z mojego doświadczenia nie wynika znacząca różnica w złożoności środowiska biznesowego.

— Adam Zuckerman

Naprawdę? SqlLite zwiększa złożoność astronomicznie? I chociaż serwer WWW normalnie nie potrzebuje DB, wiele aplikacji LOB już z niego korzysta, więc nie ma żadnych dodatkowych kosztów.

— Andy,

@AdamZuckerman oczywiście każdy RDBMS wymaga konserwacji, podatności na uszkodzenia, może wymagać specjalnego strojenia, może mieć wpływ na złą konfigurację, może wymagać specjalnego odzyskiwania, wprowadza własne ograniczenia, ma własne zależności, obsługiwane platformy, problemy z aktualizacją, błędy, licencje i tak dalej .

— noonex

@Andy po pierwsze, SQLite nie jest RDBMS w seansie klasycznym - jest „osadzonym RDBMS”. I tak - wymaganie SQLite do logowania znacznie zwiększy złożoność.

— noonex

1

@noonex Po prostu arbitralnie rozróżniasz serwer wbudowany od pełnego, gdy RDBMS tego nie robi. SqlLite zapewnia zgodność z ACID, na czym naprawdę polega RDBMS. A to znacznie zwiększa złożoność? Mogę sobie tylko wyobrazić, że nie pracowałeś nad niczym innym, jak najbardziej trywialnymi aplikacjami. Wreszcie dobra robota całkowicie ignoruje moje zdanie na temat wielu aplikacji LOB i tak potrzebowała już bazy danych.

— Andy,

-4

Czy to szybkość, łatwość konserwacji, czy coś innego?

Prędkość.

— S.Lott
źródło