Mnesia: zalety i różnice

Jakie są zalety Mnesia w porównaniu z głównymi implementacjami baz danych SQL i czym się od nich różnią?

Czy mogę używać bazy danych do przechowywania naprawdę dużych ilości danych bez zauważalnego spadku wydajności?

Przepraszam za spóźnienie na imprezę. :) Oto moja odpowiedź, oparta na używaniu Mnesii od 1996 roku i różnych innych technologii baz danych od 1988 roku.

Mnesia i MySQL są rzeczywiście różnymi zwierzętami, a to, które z nich jest najlepsze, zależy w dużej mierze od tego, jak zamierzasz go używać.

Jeśli twoja aplikacja jest napisana w Erlang, Mnesia umożliwia przechowywanie danych w tym samym obszarze pamięci, co aplikacja, co oznacza, że ​​możesz pobrać pojedynczy obiekt danych tak szybko, jak kilka mikrosekund. W MySQL nie jest to możliwe, ponieważ aplikacja i baza danych zostaną rozdzielone w pamięci. Powodem, dla którego Mnesia może to zrobić i nadal jest niezawodny, jest to, że Erlang wdraża „ochronę” pamięci na poziomie językowym.

Ogólnie rzecz biorąc, bazy danych SQL faworyzują przepustowość nad opóźnieniami, a jeśli chodzi o opóźnienia, Mnesia + Erlang są na ogół wyjątkowe. Musisz zdecydować, który z nich jest dla Ciebie najważniejszy. Jak napisano w dokumentach (powyżej), docelowymi aplikacjami Mnesii były aplikacje do przełączania telekomunikacji, w których wymagania dotyczące czasu reakcji np. Dla konfiguracji połączenia wynosiły około 20 ms. Zasadniczo oznaczało to, że można było czytać z bazy danych tylko wtedy, gdy dane znajdowały się w pamięci współużytkowanej, ale unikałyby zapisywania w pamięci trwałej na podstawie konfiguracji dla poszczególnych połączeń. OTOH, te aplikacje praktycznie nie potrzebują obsługi zapytań ad-hoc i nie używają bardzo dużych zestawów danych. Poczyniono pewne prace nad rozszerzeniem przydatności Mnesia dla innych domen, ale nie jest to priorytetem dla zespołu programistów Erlang / OTP. Mnesia jest tym, czym jest i prawdopodobnie tak pozostanie.

W powyższym odsyłaczu, w którym Mnesia i MySQL są porównywane pod kątem szybkości, należy pamiętać, że jest on w eJabberd, który działa na jednym serwerze, jeśli jest to MySQL i uruchamia w pełni replikowaną bazę danych, jeśli jest to Mnesia - a duże klastry eJabberd mogą mieć tyle, co 10 lub więcej węzłów erlang (a zatem 10 lub więcej replik Mnesia). Z punktu widzenia redundancji jest to dość śmieszne i kosztowne, a Mnesia w żadnym wypadku nie zmusza cię do tego. Zapewnia to bardzo szybkie odczyty w każdym węźle, ale zapisy będą bardzo kosztowne. Kilka porównań, które przeczytałem, zakończyło się porównaniem rozproszonej Mnesii z MySQL z jednym węzłem; jeśli nadmiarowość nie jest potrzebna dla MySQL, nie powinna być również wymagana dla Mnesii. Mnesia pozwala na wybór wzorców replikacji, a lokalizacja danych jest przezroczysta dla aplikacji.

Mnesia nie jest również ograniczona do 2 GB na tabelę (chociaż jest to konkretna opcja przechowywania ). Największa baza danych Mnesia, jaką znam, ma około 600 GB danych w (64-bitowej) pamięci RAM + dysk - chociaż tego nie polecam. Wszystko do 10-20 GB powinno być idealnie w porządku z nowoczesnym sprzętem, ale całkowicie pomiń disc_only_copies i użyj disc_copies - kup więcej pamięci RAM, jeśli musisz. Pomyślałem dwa razy, zanim użyję wsparcia sharding (mnesia_frag) - działa, ale rzadko jest warte kłopotu.

Być może największą różnicą między Mnesią a MySQL jest sam SQL: Mnesia tak naprawdę nie ma porównywalnej funkcjonalności; QLC oferuje pewne wsparcie dla zapytań ad-hoc, ale nie należy do tej samej ligi co SQL, nie ma też poziomu optymalizacji zapytań. Pod względem narzędzi i obsługi administracyjnej MySQL jest również lepszy, a jeśli potrzebujesz analizy, nie ma wątpliwości, którą wybrać (tj. NIE Mnesia).

Najlepszym sposobem na zobaczenie Mnesii jest rozszerzenie języka Erlang. Zapewnia dostęp do danych na wyciągnięcie ręki i jest doskonały do ​​małych zestawów danych, w których struktura danych i wzorce dostępu są dobrze znane. W tym celu używanie MySQL jest tak samo niewygodne, jak używanie Mnesii do rzeczy, w których MySQL działa najlepiej.

Większość aplikacji znajduje się gdzieś pośrodku i właśnie wtedy staje się wezwaniem do oceny. Możesz skończyć używając obu ...

Z dokumentacji :

Mnesia to rozproszony system zarządzania bazami danych odpowiedni dla aplikacji telekomunikacyjnych i innych aplikacji Erlang, które wymagają ciągłej pracy i miękkich właściwości w czasie rzeczywistym. Jest to jedna sekcja Open Telecom Platform (OTP), która jest platformą systemu sterowania do budowania aplikacji telekomunikacyjnych.

W szczególności bardzo wysoki poziom odporności na uszkodzenia wymagany w wielu systemach ciągłych, w połączeniu z wymaganiami dotyczącymi DBMS do działania w tej samej przestrzeni adresowej co aplikacja, doprowadziły nas do wdrożenia zupełnie nowego DBMS. o nazwie Mnesia. Mnesia jest implementowana w języku programowania Erlang i jest z nim ściśle związana i zapewnia funkcjonalność niezbędną do wdrożenia systemów telekomunikacyjnych odpornych na uszkodzenia. Mnesia to wielostanowiskowy rozproszony system DBMS specjalnie zaprojektowany dla aplikacji telekomunikacji przemysłowej napisany w symbolicznym języku programowania Erlang, który jest również zamierzonym językiem docelowym. Mnesia próbuje rozwiązać wszystkie problemy związane z zarządzaniem danymi wymagane w typowych systemach telekomunikacyjnych i ma wiele funkcji, które zwykle nie występują w tradycyjnych bazach danych.

W aplikacjach telekomunikacyjnych istnieją inne potrzeby niż funkcje oferowane przez tradycyjne DBMS. Aplikacje zaimplementowane teraz w języku Erlang wymagają połączenia szerokiego zakresu funkcji, które zazwyczaj nie są zaspokojone przez tradycyjne DBMS. Mnesia została zaprojektowana z uwzględnieniem następujących wymagań:

Szybkie wyszukiwanie kluczy / wartości w czasie rzeczywistym

Skomplikowane zapytania w czasie rzeczywistym, głównie dotyczące obsługi i konserwacji

Rozproszone dane z powodu rozproszonych aplikacji

Wysoka odporność na uszkodzenia

Dynamiczna ponowna konfiguracja

Złożone obiekty

Tym, co odróżnia Mnesię od większości innych DBMS, jest to, że została zaprojektowana z myślą o typowych problemach zarządzania danymi w aplikacjach telekomunikacyjnych. Stąd Mnesia łączy wiele pojęć spotykanych w tradycyjnych bazach danych, takich jak transakcje i zapytania, z pojęciami znajdującymi się w systemach zarządzania danymi dla aplikacji telekomunikacyjnych, takich jak bardzo szybkie operacje w czasie rzeczywistym, konfigurowalny stopień tolerancji na uszkodzenia (poprzez replikację) i możliwość ponownie skonfiguruj system bez zatrzymywania go lub zawieszania. Mnesia jest również interesująca ze względu na ścisłe powiązanie z językiem programowania Erlang, dzięki czemu prawie zamienia Erlang w język programowania baz danych. Ma to wiele zalet, przede wszystkim niedopasowanie impedancji między formatem danych używanym przez DBMS a formatem danych używanym przez język programowania,

Mnesia kontra MySQL, wydajność :

ejabberd zużywa mniej zasobów obliczeniowych podczas korzystania z bazy danych * SQL niż podczas korzystania z wewnętrznej Mnesii. Prawdopodobnie interesuje Cię ten temat, gdy masz wielu równoczesnych użytkowników (na przykład ponad 1000). Przy niewielu równoczesnych użytkownikach zużycie procesora przez ejabberd jest znikome, więc administratorzy małych serwerów nie dbają o ustawienie zewnętrznego serwera SQL i bazy danych.

CouchDB przeciwko Mnesia, V. MySQL i inne tematy Mnesia :

Jednym ze spostrzeżeń, które od razu przyszło mi do głowy, jest to, że chociaż było dla mnie rażąco oczywiste, jak ustrukturyzować dane dla MySQL, dla Mnesii jest mniej, a dla CouchDB wciąż nie jestem całkowicie pewien jak najlepszego podejścia. Na razie oto kilka bardziej oczywistych punktów:

„Record” ma pole „numplays”, które oczywiście wskazuje, ile razy zostało odtworzone. W MySQL jest to w porządku, ale jeśli po prostu dołączę to pole do dokumentu dla CouchDB, otrzymam kompletną duplikat wersji dokumentu w bazie danych za każdym razem, gdy zmieni się ta jedna liczba, co wydaje się okropnie nieefektywne.

Układ trzech tabel w MySQL zawierający rekordy, znaczniki i tabelę łączy między nimi (zobacz skrypt, jeśli nie jest to jasne) jest (przynajmniej dla mnie) oczywiście właściwym rozwiązaniem, ale istnieje wiele możliwych sposobów, aby to zrobić zarówno w Mnesii, jak i CouchDB, i okazuje się, że intuicyjnie nie mam odpowiedzi.

Krótko mówiąc, jest zaprojektowany do bardzo konkretnego celu i wydaje się być dobrze zaprojektowany, aby pasował do tego celu. Żadnej bazy danych nie można abstrakcyjnie porównać do innej. Tylko poprzez zastosowanie wymagań można wywoływać elementy współmierności.

Nie, nie powiedziałbym, że Mnesia nadaje się do dużych ilości danych. Możesz wybrać użycie Ets lub Dets jako backendu. Jeśli wybierzesz Ets, twoja baza danych będzie tylko w pamięci i bardzo szybko, ale dane nie będą trwałe. A jeśli chcesz, aby twoje dane były trwałe (zapisane na dysku), musisz użyć Dets, który ma limit 2 GB , więc twoja baza danych nie może pomieścić więcej niż 2 GB danych.

Możesz użyć niestandardowego zaplecza, np. Innostore, który jest używany w bazie danych Riak NoSQL.

Zaletą Mnesia jest to, że jest to rozproszona baza danych, więc bardzo łatwo jest wykonać systemy odporne na uszkodzenia, jeśli masz więcej niż jeden komputer. I jest bardzo łatwy w użyciu w Erlang, ponieważ jest to baza danych w języku i działa „jak funkcja”. Jest także superszybki, jeśli potrzebujesz tylko bazy danych w pamięci, np. Pamięci podręcznej.