Używanie płaskich plików vs bazy danych / API jako transportu między frontendem a backendem

Mam aplikację, która wywołała dość gorącą dyskusję między kilkoma programistami.

Zasadniczo jest podzielony na warstwę internetową i warstwę zaplecza. Warstwa internetowa zbiera informacje za pomocą prostego formularza internetowego, przechowuje te dane jako dokument JSON (dosłownie plik .json) w folderze obserwacyjnym używanym przez zaplecze. Zaplecze sonduje ten folder co kilka sekund, podnosi plik i wykonuje jego funkcje.

Same pliki są bardzo proste (tzn. Wszystkie dane łańcuchowe, bez zagnieżdżania), a ich wielkość wynosi około 1-2 tys., Przy czym system spędza większość czasu bezczynnie (ale rozrywa do 100 wiadomości w danym momencie). Krok przetwarzania zaplecza zajmuje około 10 minut na wiadomość.

Argument pojawia się, gdy jeden programista sugeruje, że użycie systemu plików jako warstwy przesyłania wiadomości jest złym rozwiązaniem, gdy zamiast tego należy użyć czegoś takiego jak relacyjna baza danych (MySQL), baza danych noSQL (Redis), a nawet zwykłe wywołanie interfejsu API REST.

Należy zauważyć, że Redis jest używany gdzie indziej w organizacji do obsługi wiadomości w kolejce.

Argumenty, które słyszałem, zostały rozbite w następujący sposób

Na korzyść plików płaskich:

• Pliki płaskie są bardziej niezawodne niż jakiekolwiek inne rozwiązanie, ponieważ plik jest przenoszony tylko z folderu „obserwuj”, do folderu „przetwarzającego” po jego pobraniu, a na koniec do folderu „gotowego” po zakończeniu. Istnieje zerowe ryzyko zniknięcia wiadomości z wyjątkiem błędów na bardzo niskim poziomie, które i tak popsułyby inne rzeczy.

• Pliki płaskie wymagają mniej technicznego wyrafinowania do zrozumienia - po prostu catto. Brak zapytań do napisania, brak ryzyka przypadkowego wyskoczenia wiadomości z kolejki i pozostawienia jej na zawsze.

• Kod zarządzania plikami jest prostszy niż interfejsy API baz danych z punktu widzenia programowania, ponieważ jest częścią standardowej biblioteki każdego języka. Zmniejsza to ogólną złożoność podstawy kodu i ilość kodu strony trzeciej, który należy wprowadzić.

• Zasada YAGNI mówi, że pliki płaskie działają teraz dobrze, nie ma potrzeby zmiany na bardziej skomplikowane rozwiązanie, więc zostaw to.

Na korzyść bazy danych:

• Łatwiej jest skalować bazę danych niż katalog pełen plików

• Pliki płaskie mogą spowodować, że ktoś skopiuje „gotowy” plik z powrotem do katalogu „watch”. Ze względu na charakter tej aplikacji (zarządzanie maszynami wirtualnymi) może to spowodować katastrofalną utratę danych.

• Wymagająca bardziej technicznego wyrafinowania dla T / S aplikacja oznacza, że ​​niewykształcony personel jest mniej skłonny do zepsucia się przez zwykłe szturchanie rzeczy.

• Kod połączenia DB, szczególnie w przypadku czegoś takiego jak Redis, jest co najmniej tak solidny, jak standardowe funkcje zarządzania plikami bibliotek.

• Kod połączenia DB jest widocznie (jeśli nie funkcjonalnie) prostszy z punktu widzenia programisty, ponieważ jest wyższy niż manipulacja plikami.

Z tego, co widzę, obaj programiści mają wiele ważnych punktów.

Tak więc spośród tych dwóch osób, twórcy pro-plików lub pro-baz danych, który jest bardziej zgodny z najlepszą praktyką inżynierii oprogramowania i dlaczego?

Przejście na rozwiązanie obejmujące bazy danych lub systemy kolejkowania wspomniane przez Ewana

• stworzyć zależność od nowego, złożonego systemu zarówno w backend, jak i frontend
• wprowadzić niepotrzebną złożoność i mnóstwo nowych punktów awarii
• zwiększyć koszt (w tym koszt posiadania)

Przenoszenie / zmiana nazwy plików w ramach jednego woluminu gwarantuje atomowość we wszystkich obecnych systemach operacyjnych, bez względu na ich trudności w odniesieniu do takich rzeczy, jak blokowanie plików / rekordów. Zarządzanie prawami na poziomie systemu operacyjnego powinno wystarczyć do zablokowania nieumytych i zapobiegania bezmyślnym / przypadkowym błędnym manipulacjom przez upoważnionych operatorów (administratorów / programistów). W związku z tym bazy danych nie mają nic do zaoferowania, o ile wydajność obecnego rozwiązania zależy od tabaki.

W naszej firmie od dziesięcioleci z powodzeniem korzystamy z podobnych interfejsów opartych na plikach. Wiele innych rzeczy pojawiło się i zniknęło, ale interfejsy te pozostały ze względu na ich całkowitą prostotę, niezawodność i minimalne sprzężenie / zależności.

Nie sądzę, aby którekolwiek z rozwiązań było z natury złą praktyką, więc znalezienie najlepszej praktyki może być trudne.

Nie sądzę, aby obowiązywała tu zasada YAGNI, jeśli masz do czynienia ze skalą. „Praca” jest względna, jeśli masz duży potencjał do katastrofalnej utraty danych i małą zdolność skalowania, tak naprawdę nie rozważałbym takiej pracy. Nie jestem do końca pewien, z jaką skalą masz do czynienia, ale jeśli masz ogromną liczbę takich wpisów, trudniej jest każdemu z nich przejść na nowy system. Jeśli tak jest, powiedziałbym, że baza danych jest najlepszą praktyką.

MongoDB lub redis (nie mam doświadczenia z redis, czytam tylko dobre rzeczy) powinny działać dobrze, ponieważ twoje dane powinny już dobrze do niego pasować (dokumenty json są często trywialnie zmieniane na dokumenty BSON dla MongoDB). Ma także dodatkową zaletę polegającą na przechowywaniu dużej ilości danych w pamięci zamiast potencjalnego częstego odczytu / zapisu na dysku przez cały czas. Daje również pewność, że równoczesne odczytywanie / zapisywanie nie prowadzi do uszkodzenia lub zablokowania.

Jeśli ma zastosowanie tutaj zasada YAGNI, a pliki nie stanowią wąskiego gardła, skalują się w zakresie i nie mają katastrofalnych problemów, powiedziałbym, że trzymanie się plików jest „najlepszą praktyką”. Nie ma powodu, aby cokolwiek zmieniać, jeśli nie ma problemów, może napisz kilka testów, zaakcentuj je i sprawdź, gdzie są twoje ograniczenia i wąskie gardła.

Nie jestem pewien, czy baza danych jest rozwiązaniem w tym kontekście. Jeśli komunikujesz się z rzeczami na tym samym serwerze, możesz zrobić IPC, nie?

Podczas gdy dobry plik zapisuje plik i kopiuje go do gotowego katalogu, jest to podstawa wielu warstw komunikacyjnych, szczególnie. ze starszymi systemami ram głównych i tym podobnymi. „Anty” mają rację; w tym, że ma wiele problemów i ostrych przypadków. Z którymi trudno sobie poradzić, jeśli potrzebujesz 100% niezawodności, i występują częściej, gdy zwiększasz częstotliwość i liczbę plików.

Jeśli kontrolujesz obie strony transakcji, sugeruję przyjrzenie się niektórym z wielu dostępnych prostych systemów kolejkowania. ZeroMQ, RabbitMQ, MSMQ itp. Zamiast bazy danych. Ale jak sugerujesz, jeśli się nie złamie ...

Rozwiązanie bazodanowe jest właściwe. Rozwiązuje wiele zależności od konkretnego hosta lub warunków brzegowych.

Oba są podobnymi rozwiązaniami, z tym wyjątkiem, że baza danych nie jest hostowana na określonym hoście. Pozbywa się to problemów z zaporą / dostępem do systemu unix. Zdarzały się przypadki „przypadkowego” usunięcia w systemach plików i nikt nie jest winny.

W przypadku bazy danych możesz mieć ten sam problem, ale możesz włączyć kontrolę lub wstawić tylko logikę, aby pozbyć się usunięć.

Również w systemie plików, jeśli chcesz umieścić aplikację w nazwie pliku, np. OASIS, musisz utworzyć pliki OASIS.john_doe.system1.20160202. To staje się nużące i może być łatwiej reprezentowane w bazie danych. Na tej podstawie możesz nawet mieć puste pola w bazie danych i logice

Łatwo jest również aktualizować bazy danych zamiast całego katalogu plików w przypadku jakichkolwiek poprawek lub poprawek, które możesz chcieć wprowadzić w tabelach. Oczywiście można to zrobić w systemie plików, ale aktualizacja bazy danych jest bardziej intuicyjna.

np. Chcesz powtórki, ale z innym systemem niż OASIS powiedz DESERT i john_doe doe_smith i datuj od 20160101 do 20151231

Łatwe do generowania wiersze dla DESERT / doe_smith / 20151231 z oryginalnego zestawu zamiast tworzenia tych plików za pomocą skryptu powłoki.

Z punktu widzenia czytelności rozwiązanie bazy danych z punktu widzenia rozszerzenia jest lepsze.