Baza danych mapowana w pamięci błyskawicy — Lightning Memory-Mapped Database
| Pierwotny autor (autorzy) | Howard Chu |
|---|---|
| Deweloper(zy) | Symas |
| Pierwsze wydanie | 24 listopada 2011 |
| Wersja stabilna | 0.9.29 / 16 marca 2021 r
|
| Magazyn | |
| Napisane w | C |
| System operacyjny | Unix , Linux , Windows , AIX , Sun Solaris , SCO Unix , macOS , iOS |
| Rozmiar | 64 KB |
| Rodzaj | Wbudowana baza danych |
| Licencja | Licencja Publiczna OpenLDAP ( dozwolona licencja na oprogramowanie ) |
| Strona internetowa | symas |
Lightning Memory-Mapped Database (LMDB) to biblioteka oprogramowania, która zapewnia wbudowaną transakcyjną bazę danych w postaci magazynu klucz-wartość . LMDB jest napisany w C z powiązaniami API dla kilku języków programowania . LMDB przechowuje dowolne pary klucz/dane jako tablice bajtów, ma możliwość wyszukiwania na podstawie zakresu, obsługuje wiele elementów danych dla jednego klucza i ma specjalny tryb dołączania rekordów (MDB_APPEND) bez sprawdzania spójności. LMDB nie jest relacyjną bazą danych , jest to ściśle magazyn klucz-wartość, taki jak Berkeley DB i dbm .
LMDB może być również używany jednocześnie w środowisku wielowątkowym lub wieloprocesowym, z liniowym skalowaniem wydajności odczytu zgodnie z projektem. Bazy danych LMDB mogą mieć tylko jednego zapisującego na raz, jednak w przeciwieństwie do wielu podobnych baz danych klucz-wartość, transakcje zapisu nie blokują czytników, a czytelnicy nie blokują zapisujących . LMDB jest również niezwykłe, ponieważ wiele aplikacji w tym samym systemie może jednocześnie otwierać i używać tego samego sklepu LMDB, jako sposobu na zwiększenie wydajności. Ponadto LMDB nie wymaga dziennika transakcji (zwiększając w ten sposób wydajność zapisu bez konieczności dwukrotnego zapisywania danych), ponieważ z natury zachowuje integralność danych.
Historia
Projekt LMDB został po raz pierwszy omówiony w 2009 r. w poście na liście dyskusyjnej programistów OpenLDAP , w kontekście badania rozwiązań problemów z zarządzaniem pamięcią podręczną spowodowanych zależnością projektu od Berkeley DB . Konkretnym celem było zastąpienie wielu warstw konfiguracji i pamięci podręcznej związanych z projektem Berkeley DB pojedynczą, automatycznie zarządzaną pamięcią podręczną pod kontrolą systemu operacyjnego hosta .
Rozwój następnie rozpoczął się, początkowo jako rozwidlenie podobnej implementacji z projektu OpenBSD ldapd. Pierwsza publicznie dostępna wersja pojawiła się w repozytorium źródłowym OpenLDAP w czerwcu 2011 roku.
Projekt był znany jako MDB do listopada 2012 roku, po czym zmieniono jego nazwę, aby uniknąć konfliktów z istniejącym oprogramowaniem.
Opis techniczny
Wewnętrznie LMDB wykorzystuje struktury danych drzewa B+ . Wydajność jego konstrukcji i niewielkie rozmiary miały niezamierzony efekt uboczny w postaci zapewnienia dobrej wydajności zapisu . LMDB ma API podobne do Berkeley DB i dbm . LMDB traktuje pamięć komputera jako pojedynczą przestrzeń adresową współdzieloną przez wiele procesów lub wątków przy użyciu pamięci współdzielonej z semantyką kopiowania przy zapisie (znaną historycznie jako magazyn jednopoziomowy ). Ze względu na to, że większość dotychczasowych nowoczesnych architektur obliczeniowych ma 32-bitowe ograniczenia przestrzeni adresowej pamięci, co narzuca sztywny limit 4 GB na rozmiar dowolnej bazy danych korzystającej z takich technik, skuteczność techniki bezpośredniego mapowania bazy danych do magazynu jednopoziomowego był ściśle ograniczony. Jednak dzisiejsze procesory 64-bitowe implementują obecnie głównie 48-bitowe przestrzenie adresowe, dając dostęp do 47-bitowych adresów lub 128 terabajtów rozmiaru bazy danych, dzięki czemu bazy danych korzystające z pamięci współdzielonej są ponownie przydatne w rzeczywistych aplikacjach.
Konkretne, godne uwagi cechy techniczne LMDB to:
- Jego wykorzystanie drzewa B+ . Gdy instancja LMDB znajduje się w pamięci współdzielonej, a rozmiar bloku drzewa B+ jest ustawiony na rozmiar strony systemu operacyjnego, dostęp do magazynu LMDB jest niezwykle wydajny pod względem pamięci
- Nowe dane są zapisywane bez nadpisywania lub przenoszenia istniejących danych. Skutkuje to gwarantowaną integralnością i niezawodnością danych bez konieczności prowadzenia dzienników transakcji lub usług czyszczenia.
- Zapewnienie unikalnego trybu zapisu z dołączaniem (MDB_APPEND), który jest realizowany przez umożliwienie dodania nowego rekordu bezpośrednio na końcu drzewa B+ . Zmniejsza to liczbę operacji odczytu i zapisu na stronie, co skutkuje znacznie zwiększoną wydajnością, ale wymaga, aby programista był odpowiedzialny za upewnienie się, że klucze są już posortowane podczas przechowywania w DB.
- Semantyka kopiowania przy zapisie pomaga zapewnić integralność danych, a także zapewnia gwarancje transakcyjne i równoczesny dostęp dla czytelników bez konieczności blokowania, nawet przez bieżącego autora. Nowe strony pamięci wymagane wewnętrznie podczas modyfikacji danych są przydzielane za pomocą semantyki kopiowania przy zapisie przez podstawowy system operacyjny: sama biblioteka LMDB nigdy nie modyfikuje starszych danych, do których uzyskują dostęp czytelnicy, ponieważ po prostu nie może tego zrobić: wszelkie aktualizacje pamięci współdzielonej automatycznie tworzą całkowicie niezależna kopia zapisywanej strony pamięci.
- Ponieważ LMDB jest mapowany w pamięci, może zwracać bezpośrednie wskaźniki do adresów pamięci kluczy i wartości za pośrednictwem swojego interfejsu API, unikając w ten sposób niepotrzebnego i kosztownego kopiowania pamięci. Powoduje to znacznie zwiększoną wydajność (zwłaszcza, gdy przechowywane wartości są bardzo duże) i rozszerza potencjalne przypadki użycia LMDB.
- LMDB śledzi również nieużywane strony pamięci, używając drzewa B+ do śledzenia stron zwolnionych (już niepotrzebnych) podczas transakcji. Dzięki śledzeniu nieużywanych stron całkowicie unika się konieczności wyrzucania elementów bezużytecznych (i fazy usuwania elementów bezużytecznych, która pochłaniałaby cykle procesora). Transakcje, które wymagają nowych stron, otrzymują najpierw strony z tego niewykorzystanego drzewa darmowych stron; dopiero po ich zużyciu rozszerzy się na wcześniej nieużywane obszary bazowego pliku mapowanego w pamięci. W nowoczesnym systemie plików z obsługą rzadkich plików pomaga to zminimalizować faktyczne użycie dysku.
Format pliku LMDB jest, w przeciwieństwie do Berkeley DB , zależny od architektury. Oznacza to, że konwersję należy wykonać przed przeniesieniem bazy danych z maszyny 32-bitowej na maszynę 64-bitową lub między komputerami o różnej endianowości .
Konkurencja
LMDB wykorzystuje wielowersyjną kontrolę współbieżności (MVCC) i umożliwia wielu wątkom w wielu procesach koordynację jednoczesnego dostępu do bazy danych. Czytelniki skalują się liniowo według projektu. Podczas gdy transakcje zapisu są globalnie serializowane za pośrednictwem mutex , transakcje tylko do odczytu działają równolegle, w tym w obecności transakcji zapisu, i są całkowicie wolne od oczekiwania, z wyjątkiem pierwszej transakcji tylko do odczytu w wątku. Każdy wątek odczytujący z bazy danych zyskuje własność elementu w tablicy pamięci współdzielonej, którą może aktualizować, aby wskazać, kiedy znajduje się w transakcji. Programiści skanują macierz, aby określić najstarszą wersję bazy danych, którą transakcja musi zachować, bez konieczności bezpośredniej synchronizacji z aktywnymi czytnikami.
Wydajność
W 2011 roku Google opublikował oprogramowanie, które pozwalało użytkownikom generować mikro-benchmarki porównujące wydajność LevelDB z SQLite i Kyoto Cabinet w różnych scenariuszach. W 2012 r. Symas dodał obsługę LMDB i Berkeley DB oraz udostępnił publicznie zaktualizowane oprogramowanie do testów porównawczych. Wyniki testów porównawczych wykazały, że LMDB przewyższa wszystkie inne bazy danych w operacjach odczytu i zapisu wsadowego. SQLite z LMDB doskonale sprawdza się w operacjach zapisu, a zwłaszcza w zapisach synchronicznych/transakcyjnych.
Testy porównawcze wykazały, że podstawowy system plików ma duży wpływ na wydajność. JFS z zewnętrznym dziennikiem działa dobrze, zwłaszcza w porównaniu z innymi nowoczesnymi systemami, takimi jak Btrfs i ZFS . Zimbra przetestowała wydajność back-mdb w porównaniu z back-hdb w OpenLDAP, przy czym LMDB wyraźnie przewyższa back-hdb oparty na BDB. Wielu innych użytkowników OpenLDAP zaobserwowało podobne korzyści.
Od czasu początkowej pracy porównawczej przeprowadzonej w 2012 r. przeprowadzono wiele kolejnych testów z dodatkowymi silnikami baz danych zarówno dla obciążeń w pamięci, jak i na dysku, charakteryzujących wydajność na wielu procesorach i rozmiarach rekordów. Testy te pokazują, że wydajność LMDB nie ma sobie równych we wszystkich obciążeniach w pamięci i wyróżnia się we wszystkich obciążeniach odczytu związanych z dyskami, a także obciążeniach związanych z zapisem na dysku przy użyciu dużych rozmiarów rekordów. Kod sterownika testowego został następnie opublikowany w serwisie GitHub i dalej rozszerzony w zakresie bazy danych.
Niezawodność
LMDB został zaprojektowany od samego początku, aby zapobiegać utracie danych w obliczu awarii systemu i aplikacji. Jego metoda kopiowania przy zapisie nigdy nie nadpisuje aktualnie używanych danych. Unikanie nadpisywania oznacza, że struktura na dysku/pamięci masowej jest zawsze prawidłowa, więc awarie aplikacji lub systemu nigdy nie powodują uszkodzenia bazy danych. W trybie domyślnym w najgorszym przypadku awaria może spowodować utratę danych z ostatniej jeszcze niezatwierdzonej transakcji zapisu. Nawet przy włączonych wszystkich trybach asynchronicznych jest to tylko katastrofalna awaria systemu operacyjnego lub zdarzenie utraty zasilania sprzętu, a nie tylko awaria aplikacji, która może potencjalnie spowodować uszkodzenie danych.
Dwa artykuły naukowe z Sympozjum USENIX OSDI dotyczyły trybów awarii silników DB (w tym LMDB) w przypadku nagłej utraty zasilania lub awarii systemu. Artykuł z Pillai et al. nie znalazł żadnego błędu w LMDB, który wystąpiłby w rozważanych rzeczywistych systemach plików; pojedyncza awaria zidentyfikowana przez badanie w LMDB dotyczy tylko hipotetycznych systemów plików. Mai Zheng i in. Paper twierdzi, że wskazuje na awarie w LMDB, ale wniosek zależy od tego, czy używany jest fsync, czy fdatasync. Użycie fsync łagodzi problem. Wybór fsync lub fdatasync to przełącznik czasu kompilacji, który nie jest domyślnym zachowaniem w obecnych kompilacjach LMDB dla Linuksa, ale jest domyślnym w macOS, *BSD, Android i Windows. Domyślne kompilacje LMDB dla Linuksa są zatem jedynymi podatnymi na problem odkryty przez badaczy zhengmai, jednak LMDB może zostać po prostu przebudowany przez użytkowników Linuksa, aby zamiast tego korzystać z fsync.
Po dostarczeniu uszkodzonej bazy danych, takiej jak ta wytworzona przez fuzzing , LMDB może ulec awarii. Autor LMDB uważa, że sprawa jest mało niepokojąca, niemniej jednak przedstawił częściowe rozwiązanie w osobnym oddziale.
Licencja open source
W czerwcu 2013, Oracle zmienił licencję Berkeley DB (powiązany projektu) z licencją Sleepycat do Affero General Public License , co ogranicza jego zastosowanie w szerokiej gamie zastosowań. To spowodowało, że projekt Debian wykluczył bibliotekę od wersji 6.0. Skrytykowano również, że licencja ta nie jest przyjazna dla komercyjnych redystrybutorów. Rozpoczęła się dyskusja na temat tego, czy ta sama zmiana licencyjna może dotyczyć LMDB. Autor Howard Chu wyjaśnił, że LMDB jest częścią projektu OpenLDAP, który miał licencję w stylu BSD, zanim dołączył, i tak pozostanie. Żadne prawa autorskie nie są przekazywane nikomu poprzez odprawę, co uniemożliwiłoby podobny ruch, jak Oracle.
Problem z licencją Berkeley DB spowodował, że główne dystrybucje Linuksa, takie jak Debian, całkowicie wycofały się z korzystania z Berkeley DB, preferując LMDB.
API i zastosowania
Istnieją wrappery dla kilku języków programowania, takich jak C++, Java, Python, Lua, Go, Ruby, Objective C, Javascript, C#, Perl, PHP, Tcl i Common Lisp. Pełną listę opakowań można znaleźć na głównej stronie internetowej.
Howard Chu przeniósł SQLite 3.7.7.1, aby używać LMDB zamiast oryginalnego kodu B-drzewa , wywołując wynik końcowy SQLightning. Jeden cytowany test wstawiania 1000 rekordów był 20 razy szybszy (niż oryginalny SQLite z implementacją B-Tree). LMDB jest dostępny jako magazyn zapasowy dla innych projektów open source, w tym Cyrus SASL, Heimdal Kerberos i OpenDKIM. Jest również dostępny w niektórych innych projektach NoSQL, takich jak MemcacheDB i Mapkeeper. LMDB został użyty do przechowywania w pamięci Redis danych utrwalających dane na dysku. Istniejący back-end w Redis wykazywał patologiczne zachowanie w rzadkich przypadkach i poszukiwano zastępstwa. Barokowe API LMDB zostało jednak skrytykowane, zmuszając wiele kodowania do wykonywania prostych rzeczy. Jednak jego wydajność i niezawodność podczas testów była znacznie lepsza niż w przypadku wypróbowanych alternatywnych sklepów zaplecza.
Niezależny, zewnętrzny twórca oprogramowania wykorzystał powiązania Pythona z LMDB w środowisku o wysokiej wydajności i opublikował na stronie z wiadomościami technicznymi Slashdot , w jaki sposób system zdołał z powodzeniem obsłużyć 200 000 jednoczesnych operacji odczytu, zapisu i usuwania na sekundę (łącznie 600 000 operacji bazy danych na sekundę).
Aktualna lista aplikacji korzystających z LMDB jest utrzymywana na głównej stronie internetowej.
Wsparcie aplikacji
Wiele popularnych projektów wolnego oprogramowania dystrybuuje lub zawiera obsługę LMDB, często jako podstawowego lub jedynego mechanizmu przechowywania.
- The Debian , Ubuntu , Fedora i openSUSE systemy operacyjne.
- OpenLDAP, dla którego LMDB został pierwotnie opracowany przez back-mdb .
- Postfix za pośrednictwem adaptera lmdb_table .
- PowerDNS , serwer DNS.
- CFEngine domyślnie używa LMDB od wersji 3.6.0.
- Shopify używa LMDB w swoim systemie SkyDB.
- Zawiąż DNS serwer DNS o wysokiej wydajności.
- Monero to kryptowaluta typu open source stworzona w kwietniu 2014 roku, która koncentruje się na prywatności, decentralizacji i skalowalności.
- Oprogramowanie pośredniczące Enduro/X korzysta z LMDB dla opcjonalnej pamięci podręcznej XATMI Microservices (SOA). Aby przy pierwszym żądaniu została wywołana właściwa usługa, w kolejnym żądaniu proces klienta odczytuje zapisany wynik bezpośrednio z LMDB.
- Kontroler domeny Samba Active Directory
Przeglądy techniczne LMDB
LMDB w nowatorski sposób wykorzystuje dobrze znane techniki informatyczne, takie jak semantyka kopiowania przy zapisie i drzewa B+, aby zapewnić atomowość i gwarancje niezawodności, a także wydajność, która może być trudna do zaakceptowania, biorąc pod uwagę względną prostotę biblioteki i brak innego podobnego klucza Baza danych magazynu wartości oferuje te same gwarancje lub ogólną wydajność, mimo że autorzy wyraźnie stwierdzają w prezentacjach, że LMDB jest zoptymalizowany pod kątem odczytu, a nie zapisu. Dodatkowo, ponieważ LMDB został opracowany głównie do użytku w OpenLDAP, jego twórcy koncentrują się głównie na rozwoju i utrzymaniu OpenLDAP, a nie na samym LMDB. Deweloperzy ograniczyli czas poświęcony na prezentację pierwszych wyników testów porównawczych, w związku z czym skrytykowano ich jako niepodających ograniczeń i za dawanie „wrażenia srebrnej kuli” nieadekwatne do postawy inżynierów (należy zauważyć, że zgłoszone obawy zostały później odpowiednio rozwiązane ku zadowoleniu recenzenta przez kluczowego programistę stojącego za LMDB.)
Prezentacja wywołała u innych programistów baz danych dogłębną analizę kodu, aby zrozumieć, jak i dlaczego działa. Recenzje są od krótkich do dogłębnych. Deweloper baz danych Oren Eini napisał 12-częściową serię artykułów na temat swojej analizy LMDB, począwszy od 9 lipca 2013 r. Wniosek był następujący: „imponująca baza kodów… bardzo potrzebuje trochę miłości”, głównie z powodu zbyt długich metod i powielanie kodu. Ta recenzja, przeprowadzona przez programistę .NET bez wcześniejszego doświadczenia z C , zakończyła się 22 sierpnia 2013 stwierdzeniem „poza moimi problemami z kodem implementacja jest naprawdę genialna. to robi wrażenie... Dużo się nauczyłem z projektu i było to frustrujące, denerwujące i fascynujące doświadczenie"
Wiele innych recenzji obejmuje LMDB w różnych językach, w tym chińskim.