Dlaczego warto korzystać z bazy danych zamiast po prostu zapisywać dane na dysku?

193

Zamiast bazy danych po prostu serializuję swoje dane do JSON, zapisując je i ładując na dysk w razie potrzeby. Całe zarządzanie danymi odbywa się w samym programie, co jest szybsze ORAZ łatwiejsze niż korzystanie z zapytań SQL. Z tego powodu nigdy nie zrozumiałem, dlaczego bazy danych są w ogóle potrzebne.

Dlaczego warto korzystać z bazy danych zamiast po prostu zapisywać dane na dysku?

MaiaVictor
źródło
61
Jeśli zarządzanie relacjami danych w aplikacji jest w rzeczywistości szybsze niż robienie tego w bazie danych (co jest dla mnie niezwykle trudne do uwierzenia), musisz przeczytać o SQL i normalizacji bazy danych. To, czego doświadczasz, to najprawdopodobniej efekt uboczny strasznie zaprojektowanej bazy danych.
yannis
68
Nie potrzebujesz bazy danych w opisywanym scenariuszu, ponieważ zestaw danych jest trywialny. Bazy danych są przeznaczone dla bardziej złożonych zestawów danych, jeśli wszystko, co robisz, to czytać i wyświetlać listę, twoje podejście działa.
yannis
16
Jakie warunki wyścigu mogłeś spotkać i czy jesteś na to gotowy? Czy chcesz przeskalować obok jednego serwera? Jaki masz plan tworzenia kopii zapasowych, jeśli serwer zawiedzie? Twoja odpowiedź na wszystkie te pytania będzie prawdopodobnie lepsza, jeśli masz bazę danych niż nie. Ponadto, jeśli kiedykolwiek zastanowiłeś się, jak nauczyć się korzystać z baz danych, domyślam się, że „łatwiejsze niż używanie zapytań SQL” powinno zostać zmienione na „łatwiejsze niż używanie zapytań SQL, jeśli nie rozumiesz SQL”.
btilly,
37
Baza danych i tak przechowuje dane na dysku. To tylko końcowy wynik naturalnej ewolucji systemów do przechowywania danych strukturalnych do pliku. Są szanse, że jeśli zamierzasz używać plików do przechowywania danych strukturalnych, odkryjesz, że odkrywasz funkcje, które zostały już opracowane w bazach danych. Dlaczego więc nie skorzystać z bazy danych od samego początku?
Benedykt
13
W zależności od ewolucji projektu może być konieczne radzenie sobie z takimi sprawami, jak jednoczesny dostęp i wycofywanie zmian. Brzmią banalnie, ale nie są. Do czasu ich rozwiązania okaże się, że właściwie napisałeś bazę danych. Czy naprawdę chcesz być w branży baz danych, czy innej firmie?
jwernerny

Odpowiedzi:

280
  1. Możesz wyszukiwać dane w bazie danych (zadawać pytania).
  2. Dane z bazy danych można wyszukiwać stosunkowo szybko.
  3. Możesz powiązać dane z dwóch różnych tabel za pomocą JOIN.
  4. Możesz tworzyć znaczące raporty z danych w bazie danych.
  5. Twoje dane mają wbudowaną strukturę.
  6. Informacje danego typu są zawsze przechowywane tylko raz.
  7. Bazy danych są ACID .
  8. Bazy danych są odporne na uszkodzenia.
  9. Bazy danych mogą obsługiwać bardzo duże zestawy danych.
  10. Bazy danych są współbieżne; wielu użytkowników może z nich korzystać jednocześnie, nie uszkadzając danych.
  11. Bazy danych dobrze się skalują.

Krótko mówiąc, korzystasz z szerokiej gamy dobrze znanych, sprawdzonych technologii rozwijanych przez wiele lat przez szeroką gamę bardzo inteligentnych ludzi.

Jeśli martwisz się, że baza danych jest nadmierna, sprawdź SQLite.

Robert Harvey
źródło
21
6. Normalizacja, 7. Zobacz link, 8. Przeczytaj o odporności na uszkodzenia. Aha, i zanim wciągniesz się w szał NoSQL, poznaj bazy danych SQL; poznać ich na własnych warunkach. Zrozumiesz. Jeśli mówisz tylko o prostych danych konfiguracyjnych, JSON może być wszystkim, czego potrzebujesz. Ale istnieje wiele innych rodzajów danych poza ustawieniami programu.
Robert Harvey
25
O ile nie jest bezpieczne, aby dwa programy jednocześnie edytowały dane, to częściowo dlatego istnieją bazy danych. Jeśli kiedykolwiek będziesz mieć taką potrzebę (i niektóre lub wszystkie inne potrzeby, o których wspomniałem), będziesz bardzo zadowolony, że nie musisz tego wszystkiego od nowa wymyślać.
Robert Harvey
23
@Dokkat To nie jest konieczne, nic nie jest. Jeśli twoje podejście działa dla ciebie, na pewno idź. Powinienem jednak wspomnieć, że większość w połowie przyzwoitych rdbms obsługuje magazyny oparte na pamięci, możesz załadować wszystko, czego potrzebujesz w pamięci, gdy aplikacja się obudzi (tak jak już to robisz), i zapytać je jak w typowej bazie danych (zachowując wszystkie korzyści, o których wspomniał Robert) ).
yannis
28
Innymi słowy, czasami potrzebujesz namiotu, ale czasem potrzebujesz domu, a budowa domu to zupełnie inna gra w piłkę niż rozbicie namiotu.
Robert Harvey
49
@Dokkat, gdy ludzie odnoszą się do awarii, mają na myśli takie rzeczy, jak ... procesor wysadził się w połowie pisania pliku „bazy danych”. Co się teraz stanie? Najprawdopodobniej twój plik jest uszkodzony / nieczytelny (przynajmniej może nie być już zgodny z twoim własnym formatem) i musisz przywrócić z kopii zapasowej (podczas gdy większość „prawdziwych” baz danych utraci tylko ostatnią transakcję). Oczywiście możesz napisać kod, aby to obsłużyć. Następnie możesz napisać kod dla wszystkich innych rzeczy. A potem zdajesz sobie sprawę, że spędziłeś 6 miesięcy na pisaniu DB, którego mógłbyś użyć od samego początku, przy bardzo małym wysiłku.
Daniel B
200

Chociaż zgadzam się ze wszystkim, co powiedział Robert, nie powiedział ci, kiedy powinieneś używać bazy danych, a nie tylko zapisywać dane na dysku.

Weź to dodatkowo do tego, co Robert powiedział o skalowalności, niezawodności, odporności na uszkodzenia itp.

Kiedy używać RDBMS, oto kilka punktów do rozważenia:

  • Masz dane relacyjne, tzn. Masz klienta, który kupuje twoje produkty, a produkty te mają dostawcę i producenta
  • Masz dużą ilość danych i musisz być w stanie szybko znaleźć odpowiednie informacje
  • Musisz zacząć martwić się o poprzednie zidentyfikowane problemy: skalowalność, niezawodność, zgodność z ACID
  • Musisz użyć narzędzi do raportowania lub wywiadu, aby rozwiązać problemy biznesowe

Co do tego, kiedy użyć NoSQL

  • Masz dużo danych, które muszą być przechowywane, które nie są uporządkowane
  • Wymagania dotyczące skalowalności i prędkości
  • Zasadniczo nie musisz definiować schematu z góry, więc jeśli zmienisz wymagania, może to być dobry punkt

Wreszcie, kiedy używać plików

  • Masz nieustrukturyzowane dane w rozsądnych ilościach, które system plików może obsłużyć
  • Nie obchodzi cię struktura, relacje
  • Nie zależy Ci na skalowalności ani niezawodności (chociaż można to zrobić w zależności od systemu plików)
  • Nie chcesz lub nie możesz poradzić sobie z narzutem, który doda baza danych
  • Masz do czynienia ze strukturalnymi danymi binarnymi należącymi do systemu plików, na przykład: obrazy, pliki PDF, dokumenty itp.
Sam
źródło
14
+1, myślę, że ważne jest, abyś wskazał, że w rzeczywistości pliki nadają się do przechowywania.
GrandmasterB
15
Możesz dodać kolejny przykład do swojej trzeciej listy: Gdy dane faktycznie plikami, np. Przesłane zdjęcia, dokumenty pdf i tym podobne. Może się to wydawać oczywiste, ale widziałem przypadki, w których obrazy były przechowywane w obiekcie blob bazy danych bez żadnego powodu.
Goran Jovic
5
Cóż, nigdy nie było żadnej wyraźnej wzmianki o tym, że jest to aplikacja internetowa, ale wywnioskowałem to z komentarza JSON. Czasami jednak coś będzie wykorzystywane tylko przez kilka osób i możesz uzasadnić zakres aplikacji, aby nie martwić się o skalowalność i niezawodność. Rozumiem przez to, że nie martwię się o takie rzeczy, jak grupowanie i redundancja.
Sam
8
@GoranJovic czasami ma to sens. Przechowuj ponad 10 000 obrazów w katalogu, a niektóre systemy plików zatrzymają się - baza danych może być łatwiejsza niż ręczny schemat partycji katalogu.
Martin Beckett
2
@MartinBeckett: który system plików ostatniej dekady to robi?
Eamon Nerbonne
55

Jedną rzeczą, o której nikt nie wspomniał, jest indeksowanie rekordów. Twoje podejście jest w tej chwili w porządku i zakładam, że masz bardzo mały zestaw danych i bardzo niewiele osób ma do niego dostęp.

W miarę, jak się komplikujesz, tworzysz bazę danych. Jakkolwiek chcesz to nazwać, baza danych to tylko zestaw rekordów zapisanych na dysku. Niezależnie od tego, czy tworzysz plik, czy MySQL , SQLite lub cokolwiek tworzy plik (i), oba są bazami danych.

Brakuje kompleksowej funkcjonalności wbudowanej w systemy baz danych, aby ułatwić ich obsługę.

Najważniejsze, co przychodzi na myśl, to indeksowanie. OK, więc możesz przechowywać 10 lub 20, a nawet 100 lub 1000 rekordów w szeregowanej tablicy lub ciągu JSON i wyciągnąć go z pliku i stosunkowo szybko iterować .

Teraz wyobraź sobie, że masz 10 000, 100 000, a nawet 1 000 000 rekordów. Gdy ktoś spróbuje się zalogować, będziesz musiał otworzyć plik o wielkości kilkuset megabajtów, załadować go do pamięci w swoim programie, wyciągnąć tablicę informacji o podobnej wielkości, a następnie iterować setki tysięcy rekordów tylko po to, aby znajdź jeden rekord, do którego chcesz uzyskać dostęp.

Odpowiednia baza danych pozwoli Ci ustawić indeksy dla niektórych pól w rekordach, pozwalając na zapytanie do bazy danych i otrzymanie odpowiedzi bardzo szybko, nawet przy dużych zestawach danych. Połącz to z czymś takim jak Memcached , a nawet z systemem buforowania domowego napoju (na przykład przechowuj wyniki wyszukiwania w osobnej tabeli przez 10 minut i ładuj te wyniki, na wypadek, gdyby ktoś inny szukał tego samego wkrótce), i będziesz mieć niezwykle szybkie zapytania, czego nie dostaniesz przy tak dużym zestawie danych, gdy ręcznie odczytujesz / zapisujesz pliki.

Kolejną rzeczą luźno związaną z indeksowaniem jest transfer informacji. Jak powiedziałem powyżej, gdy masz pliki setek lub tysięcy megabajtów, musisz załadować wszystkie te informacje do pamięci, iterować je ręcznie (prawdopodobnie w tym samym wątku), a następnie manipulować danymi.

Z systemem baz danych będzie działał na swoim własnym wątku (wątkach), a nawet na własnym serwerze. Wszystko, co jest przesyłane między twoim programem a serwerem bazy danych, jest zapytaniem SQL, a wszystko, co jest przesyłane z powrotem, to dane, do których chcesz uzyskać dostęp. Nie ładujesz całego zestawu danych do pamięci - wszystko, co wysyłasz i odbierasz, to niewielki ułamek całego zestawu danych.

Thomas Clayson
źródło
1
1. Proszę nigdy nie ładować wszystkich informacji użytkownika do kodu po stronie klienta! (Jestem pewien, że to tylko przykład) 2. Załadowanie tego w pierwszej kolejności z pliku o wielkości 100 MB zajmuje trochę czasu. 3. Twój przykład jest poprawny, ale zakładasz, że zawsze będziesz szukać według nazwy użytkownika. Co się stanie, jeśli chcesz przechowywać więcej danych o użytkowniku? np. wiek. Teraz chcesz wyszukać wszystkich użytkowników w wieku od 20 do 30 lat. Lub jeszcze prościej: znajdź użytkownika według adresu, gdy twój json wygląda tak: {login: {pass: pass, add1: "123 sasd", city: "Wherever"}}.
Thomas Clayson
2
Twój ostatni punkt jest potencjalnie poprawny, ale wtedy mógłbym pracować ze starych danych - szczególnie, jeśli otworzę twój program, załaduję bieżącą bazę danych, a następnie 5 minut później ktoś się zaloguje i coś edytuje, moja baza danych jest teraz późniejszą wersją, dopóki nie wyjdź z programu i uruchom go ponownie. Jeśli następnie edytuję bazę danych i zapiszę ją ponownie, zastąpię wszelkie zmiany dokonane przez drugiego użytkownika. Gdy masz bazę danych użytkownika, może to być po prostu zmiana hasła. Jeśli dwóch użytkowników zmieni hasło podczas sesji, wówczas zmiana zostanie cofnięta przez jednego użytkownika.
Thomas Clayson
4
Wiele się nauczyłem po przeszukaniu kilku rzeczy na temat indeksowania. To było naprawdę pouczające. Bazy danych mają teraz trochę więcej sensu. Jest jeszcze kilka rzeczy, których nie rozumiem, ale to duży postęp. Dzięki za odpowiedź!
MaiaVictor
4
O indeksach, nie, baza danych nie indeksuje wszystkiego automatycznie. Tylko kilka rzeczy jest automatycznie indeksowanych, podczas gdy reszta wymaga wyraźnego „zrób to zindeksowane”. Wskaźniki skracają czas wyszukiwania do logarytmicznego czasu O (log (n)), który jest nieco wolniejszy niż stały.
Cesarz Orionii
1
Martwienie się o różnicę między implementacją opartą na haszowaniu a opartą na drzewie b jest przedwczesną optymalizacją. Jeśli dane znajdują się w indeksie, nadal będą kilkanaście razy szybsze niż odczytywanie ich z dysku.
SilverbackNet,
14

Gdy masz proste dane, takie jak lista rzeczy, które opisujesz w komentarzach do twojego pytania, baza danych SQL nie da ci wiele. Wiele osób nadal z nich korzysta, ponieważ wiedzą, że ich dane mogą z czasem się skomplikować, a wiele bibliotek sprawia, że ​​praca z bazą danych jest banalna.

Ale nawet z prostą listą, którą ładujesz, przechowujesz w pamięci, a następnie piszesz w razie potrzeby, może mieć wiele problemów:

Nieprawidłowe zakończenie programu może spowodować utratę danych lub podczas zapisywania danych na dysk coś pójdzie nie tak i możesz ostatecznie zabić cały plik. Możesz sobie poradzić z własnymi mechanizmami, ale bazy danych radzą sobie z tym za pomocą sprawdzonych w bitwie technik.

Jeśli Twoje dane zaczną rosnąć za duże i będą się zbyt często aktualizować, serializacja wszystkich danych i oszczędzanie będzie dużym wyzwaniem dla zasobów i spowolni wszystko. Musiałbyś zacząć pracować nad podziałem rzeczy, aby nie było tak drogo. Bazy danych są zoptymalizowane pod kątem zapisywania tylko tych rzeczy, które zmieniają się na dysk w sposób odporny na uszkodzenia. Są również zaprojektowane tak, abyś mógł szybko załadować małe fragmenty danych, których potrzebujesz w danym momencie.

Ponadto nie musisz używać baz danych SQL. Możesz używać „baz danych” NoSQL, co wiele osób robi, wystarczy użyć JSON do przechowywania danych. Odbywa się to jednak w sposób odporny na uszkodzenia oraz w taki sposób, że dane mogą inteligentnie dzielić, wyszukiwać i inteligentnie dzielić na wiele komputerów.

Ponadto niektórzy ludzie mieszają różne rzeczy. Mogą używać magazynu danych NoSQL, takiego jak Redis, do przechowywania danych logowania. Następnie używaj relacyjnych baz danych do przechowywania bardziej złożonych danych, w których muszą wykonywać bardziej interesujące zapytania.

Keith Nicholas
źródło
12

Widzę wiele odpowiedzi dotyczących problemu współbieżności i niezawodności. Bazy danych zapewniają inne korzyści oprócz współbieżności, niezawodności i wydajności. Pozwalają nie zawracać sobie głowy sposobem reprezentowania bajtów i znaków w pamięci. Innymi słowy, bazy danych pozwalają programiście skoncentrować się na „czym”, a nie na „jak”.

Jedna z odpowiedzi wymienia zapytania. „Zadawanie pytań do bazy danych SQL” dobrze skaluje się wraz ze złożonością pytania. W miarę ewolucji kodu podczas programowania proste zapytania, takie jak „pobierz wszystko”, mogą łatwo rozwinąć się w „pobierz wszystko tam, gdzie właściwość1 równa się tej wartości, a następnie posortuj według właściwości2”, nie powodując, że programista będzie musiał zoptymalizować strukturę danych dla takiego zapytania. Wydajność większości zapytań można przyspieszyć, tworząc indeks dla określonej właściwości.

Inne korzyści to relacje. W przypadku zapytań czystsze jest odsyłanie do danych z różnych zestawów danych niż zagnieżdżone pętle. Na przykład wyszukiwanie wszystkich postów na forum od użytkowników, którzy mają mniej niż 3 posty w systemie, w którym użytkownicy i posty są różnymi zestawami danych (lub tabelami DB lub obiektami JSON), można wykonać za pomocą jednego zapytania bez utraty czytelności.

Podsumowując, bazy danych SQL są lepsze niż zwykłe tablice, jeśli ilość danych może być duża (powiedzmy ponad 1000 obiektów), dostęp do danych w nietrywialnych i różnych częściach kodu dostępu do różnych podzbiorów danych.

Cesarz Orionii
źródło
Jestem trochę nieufny wobec pomysłu, że możesz po prostu zignorować sposób reprezentowania rzeczy. Możesz to zignorować, jeśli tak, i esp. jeśli napiszesz nieco bardziej złożone zapytanie, jest bardzo prawdopodobne, że Twoja aplikacja nie będzie już mogła skalować. „Dodanie indeksu” nie zawsze jest możliwe - masz do czynienia z zapisem i po prostu nie pomaga to w przypadku zapytań, których złożoność obejmuje wiele tabel. Gdy indeksy są konieczne, co sugeruje, że straciłeś korzyści z interaktywnego zapytania, ponieważ odpowiedzi na zapytania o określonej strukturze są możliwe w rozsądnym czasie.
Eamon Nerbonne
12

TLDR

Wygląda na to, że podjąłeś ważną, krótkoterminową decyzję techniczną dotyczącą przechowywania danych dla swojej aplikacji - zdecydowałeś się napisać niestandardowe narzędzie do zarządzania magazynem danych.

Siedzisz na kontinuum, z opcjami poruszania się w obu kierunkach.

W dłuższej perspektywie prawdopodobnie (prawie, ale nie w 100% na pewno) wpadniesz w kłopoty i lepiej będzie skorzystać z istniejących rozwiązań do przechowywania danych. Istnieją specyficzne, bardzo częste, przewidywalne problemy z wydajnością, z którymi będziesz musiał sobie poradzić, i lepiej jest korzystać z istniejących narzędzi, niż tworzyć własne.


Wygląda na to, że napisałeś (małą) niestandardową bazę danych, wbudowaną i bezpośrednio wykorzystywaną przez twoją aplikację. Zakładam, że polegasz na systemie operacyjnym i systemie plików do zarządzania faktycznym zapisywaniem i odczytywaniem dysku oraz traktowaniem kombinacji jako magazynu danych.

Kiedy robić to, co zrobiłeś

Siedzisz w dogodnym miejscu do przechowywania danych. Magazyn danych systemu operacyjnego i systemu plików jest niezwykle wygodny, dostępny i przenośny na wiele platform. Ta kombinacja istnieje już od tak dawna, że ​​masz pewność, że będziesz obsługiwany i uruchomisz aplikację na prawie każdej standardowej konfiguracji wdrażania.

Jest to również łatwa kombinacja do pisania kodu - interfejs API jest dość prosty i podstawowy, a do jego działania potrzeba stosunkowo niewielu wierszy kodu.

Ogólnie rzecz biorąc, idealnie jest robić to, co zrobiłeś, gdy:

  • Prototypowanie nowych pomysłów
  • Budowanie aplikacji, których skalowanie i wydajność jest mało prawdopodobne
  • Ograniczone przez nietypowe okoliczności, takie jak brak zasobów do zainstalowania bazy danych

Alternatywy

Jesteś na kontinuum opcji i możesz stąd iść w dwóch kierunkach, co uważam za „w dół” i „w górę”:

Na dół

Jest to najmniej prawdopodobna opcja do zastosowania, ale jest tutaj ze względu na kompletność:

Możesz, jeśli chcesz, zejść na dół , to znaczy całkowicie ominąć system operacyjny i system plików i naprawdę pisać i czytać bezpośrednio z dysku. Ten wybór jest zwykle istotny tylko w przypadkach, w których wymagana jest ekstremalna wydajność - pomyśl na przykład o minimalnym / małym odtwarzaczu MP3 , bez wystarczającej ilości pamięci RAM dla w pełni funkcjonalnego systemu operacyjnego lub czegoś takiego jak Wayback Machine , która wymaga niewiarygodnie wydajnej masy operacje zapisu danych (większość sklepów danych kompromisuje wolniejsze zapisy w celu szybszych odczytów, ponieważ jest to o wiele bardziej powszechny przypadek użycia dla prawie wszystkich aplikacji).

W górę

Jest tu kilka podkategorii - nie są one jednak do końca ekskluzywne. Niektóre narzędzia obejmują oba, zapewniając pewne funkcje w każdym, niektóre mogą całkowicie przełączyć się z pracy w jednym trybie do pracy w drugim, a niektóre można nakładać na siebie, zapewniając różne funkcje dla różnych części aplikacji.

Bardziej wydajne magazyny danych

Być może będziesz musiał przechowywać coraz większe ilości danych, wciąż polegając na własnej aplikacji do zarządzania złożonością manipulacji danymi. Dostępna jest cała gama sklepów z kluczowymi wartościami, z różnym zakresem obsługi powiązanych funkcji. Narzędzia NoSQL należą do tej kategorii, podobnie jak inne.

Jest to oczywista ścieżka do zwiększenia, gdy następujące elementy opisują twoją aplikację:

  • Niezwykle ciężki jest odczyt
  • Nie masz nic przeciwko zamianie wyższej wydajności na niższe (krótkoterminowe) gwarancje spójności (wiele oferuje „ostateczną spójność”).
  • „Bezpośrednio” zarządza większością manipulacji danymi i brakiem spójności (w praktyce prawdopodobnie najpierw użyjesz narzędzia innej firmy, ale ostatecznie wprowadzisz to do swojej aplikacji lub do niestandardowej pisemnej warstwy pośredniej) .
  • Chcesz masowo skalować ilość przechowywanych danych i / lub zdolność do ich przeszukiwania, przy „względnie prostych” wymaganiach dotyczących manipulacji danymi.

Jest tu trochę miejsca na poruszanie się - możesz wymusić lepszą spójność odczytu, dla wolniejszych odczytów. Różne narzędzia i opcje zapewniają api do manipulacji danymi, indeksowania i inne opcje, które mogą być mniej lub bardziej odpowiednie do łatwego pisania konkretnej aplikacji. Więc jeśli powyższe punkty prawie całkowicie opisują twoją aplikację, możesz być „wystarczająco blisko”, aby pracować z bardziej wydajnym rozwiązaniem do przechowywania danych.

Dobrze znane przykłady: CouchDB , MongoDB , Redis , rozwiązania do przechowywania w chmurze, takie jak Microsoft Azure , Google App Data Store i ECE Amazon.

Bardziej złożone silniki do manipulacji danymi

Rodzina aplikacji do przechowywania danych „SQL”, a także wiele innych, lepiej opisać jako narzędzia do manipulacji danymi niż zwykłe silniki pamięci. Zapewniają one szeroki zakres dodatkowych funkcji, poza przechowywaniem danych, a często nawet więcej niż to, co jest dostępne po stronie sklepu z kluczowymi wartościami. Będziesz chciał pójść tą ścieżką, gdy:

  • Absolutnie musisz mieć spójność czytania, nawet jeśli oznacza to, że podejmiesz wydajność.
  • Chcesz efektywnie wykonywać bardzo złożone operacje na danych - pomyśl o bardzo złożonych operacjach JOIN i UPDATE, kostkach danych i segmentowaniu itp.
  • Nie przeszkadza ci kompromis w zakresie wydajności (wymuszone, stałe formaty przechowywania danych, takie jak tabele, których nie można łatwo i / lub skutecznie zmienić).
  • Masz zasoby, aby poradzić sobie z często bardziej złożonym zestawem narzędzi i interfejsów.

Jest to bardziej „tradycyjny” sposób myślenia o bazie danych lub magazynie danych, który istnieje już od dłuższego czasu - więc jest tu wiele rzeczy do zrobienia i często jest dużo komplikacji. Jest to możliwe, choć wymaga pewnej wiedzy i wiedzy oraz pozwala budować proste rozwiązania / unikać dużej złożoności - najprawdopodobniej jednak będziesz używać narzędzi i bibliotek innych firm do zarządzania większością z nich.

Dobrze znanymi przykładami są MySQL , SQL Server , baza danych Oracle i DB2 .

Zlecić pracę na zewnątrz

Istnieje kilka nowoczesnych narzędzi i bibliotek innych firm, które współdziałają między narzędziami do przechowywania danych a aplikacją, aby pomóc Ci zarządzać złożonością.

Próbują początkowo zabrać większość lub całość pracy związanej z zarządzaniem magazynami danych i manipulowaniem nimi, a idealnie pozwalają na płynne przejście do złożoności tylko wtedy, gdy jest to wymagane. Jest to aktywny obszar przedsiębiorczości i badań, z kilkoma ostatnimi wynikami, które są natychmiast dostępne i przydatne.

Dobrze znanymi przykładami są narzędzia MVC ( Django , Yii ), Ruby on Rails i Datomic . Trudno tu być uczciwym, ponieważ istnieją dosłownie dziesiątki narzędzi i bibliotek, które działają jak opakowania wokół interfejsów API różnych magazynów danych.


PS: jeśli wolisz filmy wideo niż tekst, możesz obejrzeć niektóre filmy związane z bazą danych Richa Hickeya; robi dobrą robotę, wyjaśniając większość myślenia związanego z wyborem, projektowaniem i używaniem magazynu danych.

Blueberryfields
źródło
11

System plików pasuje do opisu bazy danych NoSQL, więc powiedziałbym, że zdecydowanie powinieneś rozważyć użycie tego przy podejmowaniu decyzji o tym, jak przechowywać dane, a nie po prostu odrzucić je na korzyść RDBMS, jak sugerują tutaj niektóre odpowiedzi.

Jednym problemem z systemami plików (i ogólnie NoSQL) jest obsługa relacji między danymi. Jeśli nie jest to tutaj główny bloker, powiedziałbym, że na razie pomiń RDBMS. Pamiętaj również o pozytywnych stronach korzystania z systemu plików jako magazynu:

  • Zero administracji
  • Niska złożoność, łatwa w konfiguracji
  • Współpracuje z dowolnym systemem operacyjnym, językiem, platformą, bibliotekami itp
  • Jedynym ustawieniem konfiguracji jest katalog
  • Trywialny do przetestowania
  • Trywialne sprawdzenie za pomocą istniejących narzędzi, kopii zapasowej, modyfikacji itp
  • Dobra charakterystyka wydajności i dobrze dostrojony przez system operacyjny
  • Łatwy do zrozumienia dla każdego programisty
  • Bez zależności, bez dodatkowych sterowników
  • Model bezpieczeństwa jest prosty do zrozumienia i stanowi podstawową część systemu operacyjnego
  • Dane nie są dostępne z zewnątrz

( źródło )

Martin Wickman
źródło
10

Systemy plików są rodzajem bazy danych. Może nie RDBMS, o którym mówią wszyscy, ale na pewno DB w najściślejszym tego słowa znaczeniu. Dostarczasz klucze (nazwę pliku) do wyszukiwania danych (zawartości pliku), które mają abstrakcyjne miejsce do przechowywania i interfejs API, za pomocą którego komunikuje się Twój program.

Używasz bazy danych. Pozostałe posty mogą spierać się o zalety różnych typów baz danych ...

Chris S.
źródło
1
bazy danych i pamięci nie można tak naprawdę używać zamiennie. Baza danych jest rodzajem magazynu, ale systemy plików z pewnością nie są typem bazy danych
Gaz_Edge 15.03.2013
3
„przechowywanie” to miejsce, w którym przechowywane są bity i bajty. Baza danych niekoniecznie wykorzystuje pliki w systemie plików. System plików jest zdecydowanie rodzajem bazy danych w najściślejszym tego słowa znaczeniu.
Chris S
6
Dla kogoś, kto twierdzi, że nie ma sensu w bazach danych, gdy jest to alternatywa, należy skorzystać z bazy danych ; tak. Pomocne wydaje się wyjaśnienie im, że ich argument oparty jest na założeniu, że jest błędne. Gdy lepiej zrozumieją swoją początkową sytuację, możemy pomóc im iść do przodu dzięki pełniejszemu zrozumieniu dostępnych technologii. Systemy plików są hierarchicznymi bazami danych, istnieją dobre powody, dla których systemy relacyjne i obiektowe zastąpiły je jako szybsze, lepiej zorganizowane i wydajniejsze przechowywanie / wyszukiwanie danych.
Chris S,
2
@Gaz_Edge Dane znajdują się już w niewydajnej „bazie danych”, ponieważ są przechowywane w wiązce plików, których strukturą i zawartością zarządza aplikacja PO. Próba przekonania PO do zaakceptowania i zaakceptowania, co jest przydatnym pierwszym krokiem do zrozumienia przypadku użycia „prawdziwego” systemu bazy danych; kiedy zrozumieją, że i tak powstaje „baza danych”, łatwiej jest zacząć mówić o tym, gdzie odpowiednio ustrukturyzowana i zarządzana usługa jest bardziej wydajna niż pozwalanie aplikacji na własne działania. Sugeruję, że ta odpowiedź bardzo pomaga.
Rob Moir
8

Baza danych jest potrzebna, jeśli masz wiele procesów (użytkowników / serwerów) modyfikujących dane. Następnie baza danych zapobiega wzajemnemu nadpisywaniu zmian.

Potrzebujesz również bazy danych, gdy twoje dane są większe niż pamięć. Obecnie, dzięki dostępnej pamięci, korzystanie z baz danych w wielu aplikacjach staje się przestarzałe.

Twoje podejście jest zdecydowanie lepsze niż nonsens „baz danych w pamięci”. Które są zasadniczo twoim podejściem, ale z dużą ilością dodanych kosztów ogólnych.

funql.org
źródło
Szczerze mówiąc uwielbiam tę odpowiedź i chciałbym, aby była to prawda, ale nie jestem pewien, czy tak jest. Na przykład niektórzy użytkownicy (i Ty) wyrazili obawy dotyczące pamięci. Oczywiście, jeśli przechowuję dane o wartości GB, nie mogę zachować tego wszystkiego w pamięci. Ale co, jeśli jestem pewien, że dane nigdy nie byłyby tak duże, czy powinienem po prostu użyć pamięci? Cóż, są też inne rzeczy. Na przykład dowiedziałem się o przyrostowych widokach CouchDB. Jest to z pewnością coś, co, inaczej niż indeksowanie, NIE byłoby trywialne w implementacji samego siebie, a na pewno jest ogromnym przyspieszeniem, gdy używasz modelu widoku,
MaiaVictor
którym chyba jestem. Na przykład, kiedy przekształcam dane z „listy graczy” na „ranking”, operacja ogranicza mapę. Podczas tworzenia gry lub strony interaktywnej praktycznie wszystko, co prezentujesz, to operacja mapowania Zmniejsz liczbę podstawowych danych! Tak więc taka optymalizacja może być naprawdę pożądana. Cóż, nie mam pojęcia, czy coś z tego, co mówię, ma miejsce, ale to ma sens. Dużo się dzisiaj uczę i bardzo podoba mi się koncepcja NoSQL. Dzięki za odpowiedź (:
MaiaVictor
7

Zawsze należy zadać sobie pytanie, czy dana aplikacja wymaga RDBMS. Zbyt wiele aplikacji jest zbudowanych z procesem projektowania, który automatycznie zakłada na początku wszystkie wymagane narzędzia i struktury. Relacyjne bazy danych są tak powszechne i wielu programistów pracowało nad podobnymi aplikacjami jak wcześniej, że są one automatycznie dołączane przed rozpoczęciem projektu. Wiele projektów może temu zaradzić, więc nie oceniaj zbyt surowo.

Rozpocząłeś swój projekt bez niego i działa. Łatwiej było ci to uruchomić bez czekania na SQL. Nie ma w tym nic złego.

W miarę rozwoju tego projektu, a wymagania stają się bardziej skomplikowane, niektóre rzeczy będą trudne do zbudowania. Dopóki nie przeprowadzisz badań i nie przetestujesz metod alternatywnych, skąd wiesz, która metoda jest lepsza? Możesz zapytać programistów i przejrzeć płomienie i „to zależy”, aby odpowiedzieć na to pytanie. Gdy się go nauczysz, możesz rozważyć, ile wierszy kodu chcesz napisać w swoim języku, aby obsłużyć niektóre zalety bazy danych. W pewnym momencie wymyślasz koło na nowo.

Łatwe jest często względne. Istnieją pewne frameworki, które mogą zbudować stronę internetową i połączyć formularz z tabelą bazy danych bez konieczności pisania kodu przez użytkownika. Myślę, że jeśli zmagasz się z myszą, może to stanowić problem. Wszyscy wiedzą, że nie jest to skalowalne ani elastyczne, bo, Boże, zabroń, że ściśle powiązałeś wszystko z GUI. Non-programista właśnie zbudował prototyp; wiele YAGNI można znaleźć tutaj.

Jeśli wolisz nauczyć się ORM manipulowanego przez wybrany język zamiast nauki SQL, skorzystaj z niego, ale spróbuj zainstalować, utwórz tabelę i wyciągnij dane z popularnej bazy danych z SQL (wybierz * From; nie oszałamiające rzeczy). To łatwe do zrobienia. Właśnie dlatego ktoś je stworzył. To nie wydaje się tak wielką inwestycją, aby podjąć świadomą decyzję. Prawdopodobnie możesz również wykonać test wydajności.

JeffO
źródło
Dla przypomnienia, faktycznie korzystałem z mysql od lat, kiedy prowadziłem „otserv”. Zgadnij co? Wszystko to przyniosło problemy. Ludzie mogli „klonować” przedmioty przy użyciu brudnej sztuczki po tym, jak uświadomili sobie, że ich postacie zostały zapisane po wylogowaniu, ale nie po awarii serwera. To poważny problem dla otservs. A społeczność otserv jest OGROMNA. Nie zdarzyłoby się to, gdyby po prostu zapisywali dane w pamięci i okresowo je szeregowali. Więc zmodyfikowałem źródło samodzielnie, te długie pliki C ++ i zacząłem okresowo zapisywać w mysql, a nie po wylogowaniu się postaci. Zgadnij co? To było WOLNE!
MaiaVictor,
Mysql po prostu nie był w stanie obsłużyć stanu pełnego zapisywania co około 2 minuty. Było jasne, kiedy nastąpiło zapisanie - cały serwer „opóźniał się” na sekundę. Teraz byłbym wdzięczny, gdyby ludzie, którzy tu zamieszczali, mieli na to odpowiedź!
MaiaVictor,
1
Nie oceniaj RDBMS po tym, co się stało z pojedynczą aplikacją, która prawdopodobnie została źle zakodowana. Zwłaszcza, gdy modyfikacje do obsługi bazy danych zostały wprowadzone przez osobę bez doświadczenia w korzystaniu z bazy danych.
alroc
1
@Dokkat, mam nadzieję, że nikt nie kopie kabla zasilającego pomiędzy wpłatą środków na konto bankowe a "okresowym" zapisywaniem salda konta na dysk. Opisałeś architekturę gwarantowanej utraty danych. W przypadku niektórych aplikacji jest to w porządku, ale większość aplikacji bazodanowych daje użytkownikom możliwość wyboru. Możesz uruchomić pojedynczy węzeł bazy danych z kopiami zapasowymi i zaryzykować utratę danych lub użyć replikacji, aby wyeliminować utratę danych w przypadku awarii jednego węzła.
mikerobi
@Dokkat, więc nie używaj MySql lub innej w pełni funkcjonalnej bazy danych w stylu „serwerowym”. Używasz Sqlite (lub podobnego) i będzie on utrzymywał się na dysku za każdym razem, jednocześnie zapewniając DB wbudowany w twoją aplikację (więc nie ma potrzeby oddzielnej instalacji) i wciąż daje ci dostęp SQL, integralność transakcyjną i trwałość dysku.
gbjbaanb
6

Zapisywanie danych na dysku JEST zapisywaniem ich w bazie danych, zwłaszcza jeśli umieścisz każdy obiekt w osobnym pliku, którego nazwa jest kluczem do rekordu. Aby zminimalizować czas wyszukiwania odczytu pliku, utwórz podkatalogi na podstawie kilku pierwszych znaków klucza.

Na przykład key = ghostwriter miałby postać g / ho / stwriter.json lub g / h / o / stwriter.json lub g / ho / ghostwriter.json lub g / h / o / ghostwriter.json. Wybierz schemat nazewnictwa w oparciu o dystrybucję kluczy. Jeśli są to numery sekwencyjne, to 5/4/3 / 12345.json jest lepszy niż na odwrót.

To jest baza danych i jeśli robi wszystko, czego potrzebujesz, zrób to w ten sposób. W dzisiejszych czasach nazywa się to bazą danych NoSQL, taką jak GDBM lub db Berkeley. Tyle wyborów. Najpierw dowiedz się, czego potrzebujesz, a następnie zbuduj bibliotekę interfejsów, aby poradzić sobie ze szczegółami, być może interfejs get / set, taki jak memcached lub interfejs CRUD, a następnie będziesz mógł zamienić biblioteki, jeśli będziesz musiał zmienić format bazy danych na jeden o różnych cechach.

Należy pamiętać, że niektóre bazy danych SQL, takie jak PostgreSQL i Apache Derby DB, umożliwiają wykonywanie zapytań SQL na podstawie wielu formatów NoSQL, w tym własnych baz danych. Nie jestem pewien co do MyBatis, ale może być podobnie.

Unikaj szumu NoSQL. Przeczytaj o funkcjach, przetestuj wydajność i możliwości, a następnie wybierz na podstawie tego, jak dobrze odpowiada Twoim potrzebom aplikacji.

http://www.hdfgroup.org/HDF5/ to kolejny interesujący i szeroko stosowany format magazynu danych, którego ludzie często nie rozważają.

Michael Dillon
źródło
4

Gdy tylko dane są aktualizowane jednocześnie, podejście wykorzystujące bazę danych (może to być baza danych w pamięci) będzie prawdopodobnie bardziej poprawne i wydajniejsze, a jednocześnie kod pozostanie łatwy, ponieważ po prostu nie masz martwić się o jednoczesne aktualizacje, transakcje, buforowanie, asynchroniczne operacje we / wy i tak dalej.

Ingo
źródło
Jednoczesna modyfikacja w ramach procesu będzie bardziej wydajna przy użyciu blokad wewnątrzprocesowych niż IPC demona bazy danych, który uzyskuje kilka blokad. Ale prawdopodobnie mówisz o wielu procesach modyfikujących dane.
dhasenan
@dhasenan - To kolejna zaleta dobrych systemów baz danych. Otrzymujesz współbieżność, która działa we wszystkich przypadkach: wielowątkowa, wieloprocesowa, wielu klientów na różnych serwerach lub dowolna ich kombinacja. Twój dobrze przemyślany program wielowątkowy może w niektórych przypadkach być „bardziej wydajny”, ale po prostu się nie skaluje.
Ingo
-5

Potrzebujesz bazy danych do przechowywania / pobierania kontroli jakości, takich jak te, które tutaj publikujemy! Prosty plik nie jest w stanie uporządkować danych związanych z różnymi tematami.

Joe
źródło
3
Nie, „tematy” mogą być folderami, a „posty” w witrynie mogą być plikami. Zdecydowanie możliwe jest uruchomienie takiej strony z systemu plików. To nie jest wydajne: powolne i skomplikowane opracowywanie, uruchamianie zapytań, wstawianie nowych danych itp.
Chris S
powolny + skomplikowany = niezdolny?
Joe
Powolny i skomplikowany w budowie! = Powolny i skomplikowany w działaniu
Joe
1
@joe, naprawdę nie jest prawdą, że plik (może nie jest to „prosty” plik, ale co to znaczy?) nie może być wykorzystywany do organizowania danych związanych z różnymi tematami. Możesz użyć JSON, jak sugeruje Dokkat, lub XML, lub plików z mieszanymi rekordami, tak jak robiliśmy to w czasach wcześniejszych niż XML, lub dowolnego formatu pliku, jaki możesz wymarzyć. Nie zalecałbym żadnego z tych podejść do większości scenariuszy, ale to nie znaczy, że nie da się tego zrobić.
John M Gant,
@John Gant: całkowicie się z tobą zgadzam, bazy danych nie mogą zastąpić pojedynczych (ponieważ nie lubisz prostych) plików i odwrotnie, z tego jedynego powodu, że samochód nie może zastąpić roweru. mówię w 3 „ludzkich” językach, a mój wybór słów i słownictwa jest powodem, dla którego zostałem źle zrozumiany ... tak sądzę
joe