Odpowiedzi:
Zwykłe pliki tekstowe w systemie plików
Pliki XML lub JSON na dysku
Arkusz kalkulacyjny / plik CSV
Subversion (lub podobny system kontroli wersji oparty na dyskach)
Berkeley DB (w zasadzie hashtable dyskowe)
Prosta baza danych firmy Amazon
Kolekcje języka ojczystego (przechowywane w pamięci lub serializowane na dysku)
Niestandardowy (odręczny) mechanizm przechowywania danych
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:
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.
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
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”.
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ż:
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ć.