Czy korzystanie z serwera bazy danych ma sens, jeśli aplikacja działa tylko lokalnie?

Widziałem niektóre aplikacje, które są w zasadzie aplikacjami działającymi lokalnie w systemie (więc nie mają zbyt dużej komunikacji w sieci). Aplikacje te wydają się zależeć od serwerów baz danych w celu przechowywania ich danych.

Przykładem aplikacji jest Amarok (popularny odtwarzacz muzyki w systemie Linux). Nie wiem, czy nadal to robią, ale pamiętam, że był czas, kiedy instalacja Amaroka oznaczała, że ​​musisz zainstalować serwer MySQL i cały czas działać w tle.

Jaka jest zaleta korzystania z serwera do lokalnej pamięci masowej w porównaniu z użyciem mniejszego wbudowanego rozwiązania SQL, takiego jak sqlite? Mówię ogólnie o oprogramowaniu aplikacyjnym, niekoniecznie amaroku (to był tylko przykład). Czy istnieją sytuacje, w których korzystanie z serwera bazy danych ma sens w porównaniu z osadzoną bazą danych?

SQLite oferuje całkiem dobre podsumowanie, kiedy go użyć, czy nie, w porównaniu z alternatywami:

https://www.sqlite.org/whentouse.html

Ta linia podsumowania bardzo dobrze opisuje przypadek użycia SQLite:

SQLite nie konkuruje z bazami danych klient / serwer. SQLite konkuruje z fopen ().

Artykuł rozszerza się na ten temat. Zawiera także sekcję „Sytuacje, w których klient / serwer RDBMS może działać lepiej”. W skrócie są to:

• Aplikacje klient / serwer : wielu użytkowników w sieci.
• Witryny o dużej objętości : albo intensywnie pisz, albo intensywnie czytaj, aby wymagać dzielenia na fragmenty.
• Bardzo duże zbiory danych : większe niż można rozsądnie przechowywać na jednym dysku.
• Wysoka współbieżność : w szczególności współbieżne zapisy.

Nawet w przypadku pojedynczego systemu z jednym użytkownikiem „prawdziwy” serwer bazy danych ma sens:

1. Wykorzystuje znajomy język ( SQL ). SQLite używa SQL, ale niektóre wbudowane bazy danych (np. Baza danych obiektów , NoSQL ) nie używają SQL. Te mają wyższą krzywą uczenia się, ponieważ są mniej powszechne.
2. Zapewnia integralność referencyjną, ograniczenia, wyzwalacze itp., Których produkty takie jak SQLite mogą nie zapewniać lub przynajmniej nie dostarczają w pełni.
3. Dzięki celowaniu w prawdziwą bazę danych dla wielu użytkowników, zgodną z ACID , aplikacja ma możliwość pracy w scenariuszu dla jednego użytkownika / jednej stacji roboczej lub jako aplikacja hostowana dla wielu użytkowników przy użyciu tej samej bazy kodów .
4. Użytkownik ma możliwość badania danych offline przy użyciu standardowych narzędzi (np. SQL Developer, MySQL Workbench, SQL Server Management Studio), ładowania lub tworzenia kopii zapasowych danych przy użyciu tych narzędzi itp. Chociaż jest to możliwe z wieloma osadzonymi bazami danych różnych typów, ludzie mogą być bardziej zaznajomieni z tymi narzędziami ze świata baz danych C / S.

Podstawową wadą jest konieczność instalowania i utrzymywania oprogramowania serwera bazy danych, które jest nieco skomplikowane dla użytkowników nietechnicznych (a nawet wielu użytkowników technicznych). Systemy operacyjne takie jak Linux ułatwiają to: Mam PostgreSQL i MySQL na moim systemie Linux. Zainstalowałem aplikacje, które się do nich przyłączyły, z niewielką lub żadną interakcją z mojej strony.

Myślę, że ma to związek z bezwładnością.

Amarok opiera się na XMMS, który pochodzi z 1997 roku. Aby mieć dobre możliwości bazy danych, musiałeś użyć serwera, ponieważ był on o wiele potężniejszy niż rozwiązania oparte na plikach, które w żadnym wypadku nie miały dobrych możliwości bazy danych.

Nadchodząca i zyskująca popularność dobrych lokalnych osadzonych baz danych, takich jak SQLlite, jest czymś całkiem nowym.

Najważniejszą cechą wyróżniającą jest współbieżność .

Jeśli masz tylko jedną aplikację, która działa w jednym wystąpieniu dla użytkownika, rozwiązanie osadzone (bez względu na to, czy jest to sqlite, czy jakaś pamięć obiektowa) jest zwykle OK.

Jeśli jednak masz wiele instancji, które muszą jednocześnie manipulować bazą danych, musisz mieć serwer do jej synchronizacji. SQLite pozwala tylko na jeden zapis na raz, w całej bazie danych, podobnie jak większość innych wbudowanych rozwiązań. Jeśli masz nawet wiele aplikacji, prawdopodobnie potrzebujesz bardziej szczegółowej specyfikacji ograniczeń, na którą wbudowane rozwiązania na ogół nie pozwalają.

Wiele innych odpowiedzi mówi o zaletach współbieżności, ale także ponieważ baza danych działa jako serwer, baza danych może uruchamiać zadania bez konieczności uruchamiania aplikacji. Może to być konserwacja, kopie zapasowe, synchronizacja z innym serwerem lub dowolne zaplanowane zadanie.

Jeśli uważasz, że Twoja aplikacja może zmienić się w aplikację typu klient / serwer, możesz zacząć od korzystania z RDBMS od samego początku zamiast przenosić go później.

Nie mam pojęcia, czy podany przykład wykorzystuje to, czy nie.

O ile nie korzystasz z systemu osadzonego z małą ilością pamięci i procesorem, nie sądzę, że działanie serwera w tle wyrządzi ci jakąkolwiek krzywdę.

Lokalne działanie serwera bazy danych jest w porządku. Baza danych ma na celu dostęp do danych i manipulowanie nimi. Dostęp do sieci to plus, który może, ale nie musi być potrzebny. Istnieją narzędzia inżynieryjne i naukowe, które to umożliwiają.

Powiedz, że używasz danych w lokalnej aplikacji. Dlaczego nie powinieneś korzystać z bazy danych? w przeciwieństwie do czego?

Zależy to od abstrakcji danych i ogólnej przestrzeni aplikacji, wymagań w zakresie zarządzania dostępem, planowanej inwestycji w utrzymanie danych, pilności wymaganego prototypu, gdzie jesteś na krzywej uczenia się itp.

Jeśli chcesz zapewnić ściśle zintegrowaną bazę danych do aplikacji, która nie wymaga dostępu z innych aplikacji, tworząc wyspy wbudowanej bazy danych. Przykładem może być implementacja Web Storage Mozilla Firefox z SQLite.

Jeśli potrzebujesz jeszcze większej wydajności przy ograniczonej ilości danych, lepiej wybrać wybór baz danych w pamięci.

Z drugiej strony, jeśli masz wiele aplikacji uruchamiających wiele zapytań o te same dane, a to wymaga lepszej struktury przechowywania danych w celu optymalizacji wydajności, wymagany jest scentralizowany system DBMS. Absolutnie wolę to do badań naukowych, gdy wymaga ogromnej ilości danych i gdzie czas odpowiedzi na zapytanie znacząco wpłynie na ogólne wrażenia użytkownika.

W przypadku Amaroka, jak sądzę, był to wybór DBMS typu open source, zanim wybrali ścieżkę osadzonych baz danych.

Jeśli masz pod ręką określoną definicję systemu, łatwiej będzie ważyć minusy i zalety.

V / r, Umut