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 ...