Dobre powody, aby NIE używać relacyjnej bazy danych?

Czy możesz wskazać alternatywne narzędzia do przechowywania danych i podać dobre powody, aby ich używać zamiast starych, dobrych relacyjnych baz danych? Moim zdaniem większość aplikacji rzadko wykorzystuje pełną moc SQL - ciekawie byłoby zobaczyć, jak zbudować aplikację wolną od SQL.

Zwykłe pliki tekstowe w systemie plików

• Bardzo proste w tworzeniu i edycji
• Łatwy w obsłudze dla użytkowników za pomocą prostych narzędzi (np. Edytorów tekstu, grep itp.)
• Wydajne przechowywanie dokumentów binarnych

Pliki XML lub JSON na dysku

• Jak wyżej, ale z nieco większą możliwością walidacji struktury.

Arkusz kalkulacyjny / plik CSV

• Bardzo łatwy do zrozumienia model dla użytkowników biznesowych

Subversion (lub podobny system kontroli wersji oparty na dyskach)

• Bardzo dobre wsparcie dla wersjonowania danych

Berkeley DB (w zasadzie hashtable dyskowe)

• Bardzo proste koncepcyjnie (tylko nie wpisany klucz / wartość)
• Dosyć szybko
• Brak kosztów administracyjnych
• Uważam, że obsługuje transakcje

Prosta baza danych firmy Amazon

• Wydaje mi się, że podobnie jak Berkeley DB, ale hostowane

Google App Engine Datastore

• Hostowane i wysoce skalowalne
• Przechowywanie klucz-wartość według dokumentu (tj. Elastyczny model danych)

CouchDB

• Koncentracja na dokumencie
• Proste przechowywanie danych częściowo ustrukturyzowanych / opartych na dokumentach

Kolekcje języka ojczystego (przechowywane w pamięci lub serializowane na dysku)

• Bardzo ścisła integracja językowa

Niestandardowy (odręczny) mechanizm przechowywania danych

• Potencjalnie bardzo wysoka wydajność w wymaganych przypadkach użycia

Nie mogę twierdzić, że nic o nich wiem, ale możesz też zajrzeć do systemów obiektowych baz danych .

Odpowiedź Matta Shepparda jest świetna (zmodyfikuj), ale myśląc o wrzecionie wziąłbym pod uwagę te czynniki:

1. Struktura: czy to oczywiście rozpada się na kawałki, czy robisz kompromisy?
2. Zastosowanie: w jaki sposób dane zostaną przeanalizowane / odzyskane / wykorzystane?
3. Czas życia: jak długo dane są przydatne?
4. Rozmiar: ile jest danych?

Jedną ze szczególnych zalet plików CSV w porównaniu z systemami RDBMS jest to, że można je łatwo skondensować i przenieść na praktycznie każdą inną maszynę. Wykonujemy duże transfery danych, a wszystko jest dość proste, używamy po prostu jednego dużego pliku CSV i łatwego do skryptu za pomocą narzędzi takich jak rsync. Aby zmniejszyć liczbę powtórzeń w przypadku dużych plików CSV, możesz użyć czegoś takiego jak YAML . Nie jestem pewien, czy przechowałbym coś takiego jak JSON lub XML, chyba że miałbyś istotne wymagania dotyczące relacji.

Jeśli chodzi o niewymienione alternatywy, nie przeceniaj Hadoop , który jest otwartą implementacją MapReduce. Powinno to działać dobrze, jeśli masz TONĘ luźno ustrukturyzowanych danych, które należy przeanalizować, i chcesz znaleźć się w scenariuszu, w którym możesz po prostu dodać 10 dodatkowych maszyn do obsługi przetwarzania danych.

Na przykład zacząłem analizować wydajność, która była zasadniczo liczbą wszystkich czasów różnych funkcji zarejestrowanych na około 20 maszynach. Po próbie umieszczenia wszystkiego w RDBMS zdałem sobie sprawę, że naprawdę nie muszę ponownie sprawdzać danych po ich zagregowaniu. Jest to dla mnie przydatne tylko w zagregowanym formacie. Dlatego przechowuję pliki dziennika, kompresuję je, a następnie zostawiam zagregowane dane w bazie danych.

Uwaga : Jestem bardziej przyzwyczajony do myślenia o „dużych” rozmiarach.

System plików jest bardzo przydatny do przechowywania danych binarnych, co nigdy nie działa zadziwiająco dobrze w relacyjnych bazach danych.

Wypróbuj Prevayler: http://www.prevayler.org/wiki/ Prevayler jest alternatywą dla RDBMS. Na stronie więcej informacji.

Jeśli nie potrzebujesz ACID , prawdopodobnie nie potrzebujesz narzutu RDBMS. Więc zdecyduj, czy potrzebujesz tego najpierw. Większość podanych tutaj odpowiedzi innych niż RDBMS nie zawiera ACID.

Niestandardowy (odręczny) mechanizm przechowywania danych / Potencjalnie bardzo wysoka wydajność w wymaganych przypadkach użycia

http://www.hdfgroup.org/

Jeśli masz ogromne zbiory danych, zamiast tworzyć własne, możesz użyć HDF, hierarchicznego formatu danych.

http://en.wikipedia.org/wiki/Hierarchical_Data_Format :

HDF obsługuje kilka różnych modeli danych, w tym wielowymiarowe tablice, obrazy rastrowe i tabele.

Jest również hierarchiczny, jak system plików, ale dane są przechowywane w jednym magicznym pliku binarnym.

HDF5 to pakiet umożliwiający zarządzanie wyjątkowo dużymi i złożonymi zbiorami danych.

Pomyśl o petabajtach danych z teledetekcji NASA / JPL.

Dzień dobry,

Przychodzi mi do głowy jeden przypadek, kiedy danych, które modelujesz, nie można łatwo przedstawić w relacyjnej bazie danych.

Takim przykładem jest baza danych wykorzystywana przez operatorów telefonii komórkowej do monitorowania i sterowania stacjami bazowymi sieci telefonii komórkowej.

I prawie wszystkie te przypadki, OO DB używana jest , albo produkt komercyjny, albo system samoczynnie rozwijający się, który pozwala na tworzenie hierarchii obiektów.

Pracowałem nad aplikacją monitorującą 3G dla dużej firmy, która pozostanie bezimienna, ale której logo to plama z czerwonego wina (-: i używali takiej bazy danych OO do śledzenia wszystkich różnych atrybutów poszczególnych komórek w sieć.

Przeszukiwanie takich baz danych odbywa się przy użyciu zastrzeżonych technik, które zazwyczaj są całkowicie wolne od SQL.

HTH.

Twoje zdrowie,

Obrabować

Obiektowe bazy danych nie są relacyjnymi bazami danych. Mogą być naprawdę przydatne, jeśli chcesz po prostu umieścić jakieś obiekty w bazie danych. Obsługują również przechowywanie wersji i modyfikują klasy obiektów, które już istnieją w bazie danych. db4o jest pierwszym, który przychodzi na myśl.

W niektórych przypadkach (na przykład dane z rynków finansowych i kontrola procesów) może być konieczne użycie bazy danych czasu rzeczywistego zamiast RDBMS. Zobacz link do wiki

Było narzędzie RAD o nazwie JADE napisane kilka lat temu, które ma wbudowany OODBMS. Wcześniejsze wcielenia silnika DB obsługiwały również Digitalk Smalltalk. Jeśli chcesz przykładowo zbudować aplikację przy użyciu paradygmatu innego niż RDBMS, może to być początek.

Inne produkty OODBMS to Objectivity , GemStone (będziesz potrzebować VisualWorks Smalltalk, aby uruchomić wersję Smalltalk, ale jest też wersja java). W tej przestrzeni było też kilka projektów badawczych typu open-source - na myśl przychodzi EXODUS i jego potomek SHORE.

Niestety, koncepcja wydawała się umrzeć śmiercią, prawdopodobnie z powodu braku wyraźnie widocznego standardu i stosunkowo słabych możliwości wykonywania zapytań ad-hoc w porównaniu z systemami RDMBS opartymi na SQL.

OODBMS jest najbardziej odpowiedni dla aplikacji z podstawowymi strukturami danych, które najlepiej przedstawia się jako wykres połączonych ze sobą węzłów. Zwykłem mówić, że kwintesencją aplikacji OODBMS jest Multi-User Dungeon (MUD), w którym pokoje zawierają awatary graczy i inne obiekty.

Możesz przejść długą drogę, używając plików przechowywanych w systemie plików. RDBMS są coraz lepsze w obsłudze obiektów blob, ale może to być naturalny sposób obsługi danych obrazu i tym podobnych, szczególnie jeśli zapytania są proste (wyliczanie i wybieranie poszczególnych elementów).

Inne rzeczy, które nie pasują zbyt dobrze do RDBMS, to hierarchiczne struktury danych i zgaduję, że dane geoprzestrzenne i modele 3D nie są takie łatwe w obsłudze.

Usługi takie jak Amazon S3 zapewniają prostsze modele pamięci masowej (klucz-> wartość), które nie obsługują SQL. Kluczem jest skalowalność.

Pliki programu Excel również mogą być przydatne, szczególnie jeśli użytkownicy muszą mieć możliwość manipulowania danymi w znanym środowisku i zbudowania pełnej aplikacji, która nie jest do tego wykonalna.

Istnieje wiele sposobów przechowywania danych - nawet „relacyjna baza danych” obejmuje szereg alternatyw, od prostej biblioteki kodu, która manipuluje lokalnym plikiem (lub plikami) tak, jakby była relacyjną bazą danych pojedynczego użytkownika, po systemy oparte na plikach, które mogą obsłużyć wielu użytkowników w szerokiej gamie poważnych systemów opartych na serwerze.

Często korzystamy z plików XML - otrzymujesz dobrze ustrukturyzowane dane, fajne narzędzia do wykonywania zapytań, a także możliwość edycji, jeśli jest to konieczne, coś, co jest czytelne dla człowieka i nie musisz się wtedy martwić o działanie silnika bazy danych (ani o działanie silnik db). Działa to dobrze w przypadku rzeczy, które zasadniczo są tylko do odczytu (w naszym przypadku częściej niż nie są generowane z bazy danych w innym miejscu), a także w przypadku systemów pojedynczego użytkownika, w których można po prostu załadować dane i zapisać je w razie potrzeby - ale stwarzasz możliwości na problemy, jeśli chcesz edytować wielu użytkowników - przynajmniej jednego pliku.

Dla nas to wszystko - albo użyjemy czegoś, co wykona SQL (MS oferuje zestaw narzędzi, które działają od .DLL do wykonywania czynności dla pojedynczego użytkownika aż do serwera korporacyjnego i wszystkie mówią tym samym SQL (z ograniczeniami na dole)) lub użyjemy XML jako formatu, ponieważ (dla nas) szczegółowość rzadko jest problemem.

Obecnie nie musimy manipulować danymi binarnymi w naszych aplikacjach, więc to pytanie nie pojawia się.

Murph

Można rozważyć użycie serwera LDAP zamiast tradycyjnej bazy danych SQL, jeśli dane aplikacji są silnie zorientowane na klucz / wartość i mają charakter hierarchiczny.

Pliki BTree są często znacznie szybsze niż relacyjne bazy danych. SQLite zawiera w sobie bibliotekę BTree, która jest w domenie publicznej (jak w prawdziwej „domenie publicznej”, nie używając tego terminu luźno).

Szczerze mówiąc, gdybym chciał mieć system dla wielu użytkowników, potrzebowałbym dużo przekonywania, aby nie używać porządnej relacyjnej bazy danych serwera.

Pełnotekstowe bazy danych, do których można przeszukiwać za pomocą operatorów zbliżeniowych, takich jak „w ciągu 10 słów” itp.

Relacyjne bazy danych są idealnym narzędziem biznesowym do wielu celów - wystarczająco łatwe do zrozumienia i zaprojektowania, wystarczająco szybkie, adekwatne, nawet jeśli nie zostały zaprojektowane i zoptymalizowane przez geniusza, który potrafiłby „wykorzystać pełną moc” itp.

Jednak niektóre cele biznesowe wymagają indeksowania pełnotekstowego, którego silniki relacyjne albo nie zapewniają, albo są uwzględniane po namyśle. W szczególności w dziedzinach prawnych i medycznych można przechowywać i przebrnąć przez duże obszary nieustrukturyzowanego tekstu.

Ponadto: * Scenariusze osadzone - tam, gdzie zwykle wymagane jest użycie czegoś mniejszego niż pełnoprawny RDBMS. Db4o to ODB, który można łatwo wykorzystać w takim przypadku. * Szybki rozwój lub weryfikacja koncepcji - gdy chcesz skupić się na biznesie i nie martwić się o warstwę trwałości

Twierdzenie CAP wyjaśnia to zwięźle. SQL zapewnia głównie „Silną spójność: wszyscy klienci widzą ten sam widok, nawet w obecności aktualizacji”.

KISS: Niech to będzie małe i proste

Oferuję RDBMS :) Jeśli nie będziesz mieć kłopotów z konfiguracją / administracją, wybierz SQLite. Wbudowany RDBMS z pełną obsługą SQL. Pozwala nawet na przechowywanie dowolnego typu danych w dowolnej kolumnie.

Główna zaleta w stosunku do na przykład pliku dziennika: jeśli masz duży plik, jak zamierzasz go wyszukiwać? Dzięki silnikowi SQL po prostu tworzysz indeks i znacznie przyspieszasz działanie.

Informacje o wyszukiwaniu pełnotekstowym: SQLite ma również moduły do ​​wyszukiwania pełnotekstowego.

Po prostu ciesz się ładnym standardowym interfejsem do swoich danych :)

Jednym z dobrych powodów, aby nie używać relacyjnej bazy danych, jest sytuacja, gdy masz ogromny zestaw danych i chcesz wykonywać masowo równoległe i rozproszone przetwarzanie danych. Idealnym przykładem takiego przypadku byłby indeks internetowy Google.

Hadoop ma również implementację systemu plików Google o nazwie Hadoop Distributed File System .

Zdecydowanie poleciłbym Lua jako alternatywę dla przechowywania danych w rodzaju SQLite.

Ponieważ:

• Język został zaprojektowany od początku jako język opisu danych
• Składnia jest czytelna dla człowieka (XML nie jest )
• Aby zwiększyć wydajność, można skompilować fragmenty Lua do postaci binarnej

To jest opcja „zbiór języka ojczystego” zaakceptowanej odpowiedzi. Jeśli używasz C / C ++ jako poziomu aplikacji, całkiem rozsądne jest wrzucenie silnika Lua (100kB binarnego) tylko po to, aby odczytać konfiguracje / dane lub je wypisać.