Bazy
Danych
Zbudujmy sobie bazę danych
Paweł Marciniak
– LhimkDB. Część 1
J
est bardo dużo różnych baz danych. Są bar-
dzo dobre bazy danych dostępne za darmo
z całym kodem źródłowym, bez żadnych ogra-
niczeń licencyjnych (np. PostgreSQL). Po co zatem
budować jeszcze jedną? Jest kilka powodów.
Po pierwsze, będziemy budować bazę danych do
wbudowywania do programów (ang. embedded da-
tabase), o architekturze klucz-wartość (ang. key-va-
lue). Jest oczywiście dużo takich baz danych dostęp-
nych na licencjach open source, ale bardzo nielicz-
ne można używać bez ograniczeń w programach ko-
mercyjnych. Najpopularniejsza jest Berkeley DB (http://
www.sleepycat.com/), która wymaga udostępniania ko-
du źródłowego programu za darmo. Jest bardzo cieka-
wa baza danych PBL (http://mission.base.com/peter/
source/) na licencji LGPL, ale niestety ma ograniczo-
ną długość klucza do 255 bajtów. Warta zobacze-
nia jest baza danych MetaKit (http://www.equi4.com/
metakit.html), dostępna na licencji BSD, ale nie jest to
baza danych klucz-wartość. MetaKit jest bazą danych
opartą na kolumnach (ang. column based). Jest jesz-
cze dużo innych projektów, ale, albo mają restrykcyj-
ną licencję, albo nie mają transakcji, albo jeszcze cze-
goś innego im brak. W sumie, nie znalazłem dobrej ba-
zy danych klucz-wartość do wbudowywania do progra-
mów. To może warto taką bazę zbudować?
Najprościej by było (tak się wydaje), wyjąć kawałek
PostgreSQL-a, który odpowiada za samo przechowy-
wanie danych w indeksach (czyli w postaci klucz-war-
tość). PostgreSQL korzysta z biblioteki Gist, więc jest to
dobrze wydzielony fragment kodu. Jednak PostgreSQL
jest bazą danych budowaną na algorytmach z lat 70.
i 80., oczywiście odnawianych, ale wciąż podstawą jego
działania są standardowe algorytmy. Skoro budujemy
coś nowego, to czemu nie zrobić tego inaczej? Podsta-
wy budowy baz danych, praktyczne i teoretyczne, były
formułowane w latach, kiedy komputer miał kilka kilobaj-
tów RAM-u i kilku megabajtowy dysk twardy. Wszelkie
rozważania opierały się na tym, że najbardziej kosztow-
ną czasowo operacją jest komunikacja z dyskiem twar-
dym. Komunikacja ta polega na zapisie i odczycie stron
(ang. pages) o stałej wielkości. Generalnie jest to nadal
prawdą, ale pojawiło się wiele nowych elementów, jak
np. systemowe: pamięć wirtualna, mapowanie plików
itp., czy sprzętowe: operacje CAS, pamięć stała oparta
o FLASH, RAM itp. Jeszcze kilka lat temu baza danych
Paweł od 20 lat zajmuje się tworzeniem oprogramowa-
nia, głównie w C/C++. Od trzech lat rozwija system dy-
namicznej kompilacji Lhimk.
Kontakt z autorem: pawel@software.com.pl
22 www.sdjournal.org
������� ������������������
����������
��������� �����������
�������
��������������
�������
���������
�������
���
�������
��������������
��������� ����������
�����
Rysunek 1. Architektura LhimkDB
musiała mieć swoją własną partycję na dysku. Nikt przy
zdrowych zmysłach nie używał standardowego syste-
mu plików. Potem zaczęły się pojawiać bazy, które sa-
me potrafiły powiększać swoje pliki (nie wymagały ad-
ministratora!). Dziś wydaje się to oczywiste, ale kiedyś
takie nie było. Może czas na kolejne zmiany.
Oczywiście nikt przystępując do pisania kolejnej
aplikacji nie będzie pisał własnej bazy danych (no
może prawie nikt). Nawet jeśli istniejące rozwiąza-
nia mają złe licencje, lub są przestarzałe. Lepiej jed-
nak wziąć sprawdzone, dobrze przetestowane roz-
wiązanie, w końcu baza danych musi być w 100 %
niezawodna. Z drugiej strony, warto przynajmniej
zobaczyć jak taka baza jest zbudowana, a najlepiej
choćby spróbować coś samemu napisać. Zrozumie-
my wtedy lepiej jak baza danych działa, a wszystkie
one działają podobnie, i będziemy mogli dużo lepiej
wykorzystywać gotowe rozwiązania. Pojawi się też
w naszym życiu więcej humoru, jeśli czytamy rekla-
my Poważnych Wielkich Producentów Baz Danych.
Niniejszy artykuł jest pierwszą częścią cztero-
częściowej serii, w której zbudujemy od podstaw no-
woczesną bazę danych do wbudowywania. Ta część
jest ogólnym przeglądem całego projektu, który ma
decydujący wpływ na podjęte szczegółowe decyzje.
W następnych częściach będziemy omawiać krok po
kroku wszystkie elementy tej bazy, wracając do omó-
wionych tutaj decyzji.
Cel
Wypiszmy sobie cele, jakie stawiamy przed nową
bazą danych. Po pierwsze, o czym już pisałem, ma
to być baza danych do wbudowywania (czyli biblio-
teka), w architekturze klucz-wartość. Nie lubię ogra-
niczeń, więc najlepiej niech klucz i wartość będą “do-
wolnej” długości. Sama baza danych też nie powin-
na mieć ograniczeń na wielkość. Oczywiście chcemy
mieć wsparcie dla transakcji, najlepiej też dla trans-
akcji zagnieżdżonych, a jak się uda, to też dla dłu-
Software Developer’s Journal 11/2005
 Zbudujmy sobie bazę danych – LhimkDB
gich (ang. long running transactions). Sama architektura po-
winna być otwarta, czyli powinna dać się rozszerzać i wbudo-
wywać np. nowe typy indeksów. Ważne jest też, żeby baza
danych szybko odtwarzała swój stan po awarii i pozwalała ro-
bić gorące kopie (ang. hot backups).Jest to krytyczne w serwi-
sach internetowych, gdzie system musi działać cały czas i nie
możemy wykonywać czynności administracyjnych, wymagają-
cych odłączenia bazy danych choćby na kilka minut.
Projekt
Od razu zacznę od najbardziej kontrowersyjnej decyzji. Otóż
LhimkDB jest napisany w języku i środowisku Lhimk. Jesz-
cze przez chwilę nie przestawaj czytać, a zaraz wszyst-
ko wyjaśnię. LhimkDB najpierw został napisany w języku C
(w oparciu o kod SkipDB autorstwa Steva Dekorte, http://
www.dekorte.com/). Początkowo myślałem, że będzie to bi-
blioteka napisana w C i włączona do Lhimka jako DLL. Jed-
nak w trakcie pisania, okazało się, że dużo wygodniej będzie
ten kod przepisać w Lhimku. Został jednak oryginalny kod
w C, więc jeżeli komuś bardzo przeszkadza Lhimk, to może
wziąć wersję w C i ją dopracować (kod w C jest na poziomie
późnej bety, ma wszystkie opisywane tutaj mechanizmy). Jed-
nak Lhimk nie powinien być żadną barierą, jeżeli ktoś szuka
biblioteki do baz danych do C/C++ (lub innych języków, któ-
re potrafią z bibliotek C korzystać). Lhimk jest oparty na C,
jest wstecznie zgodny z C i można go używać jako biblioteki
w programach napisanych w C. Można też program w C
skompilować jako bibliotekę i zanurzyć w Lhimku. Tak czy in-
aczej, bez żadnych problemów można korzystać z LhimkDB
w programach C/C++. Więcej o Lhimku w ramce obok.
Wróćmy do bazy danych. Każda baza danych składa się
z kilku współpracujących ze sobą warstw (Rysunek 1.). Na sa-
mym dole jest warstwa obsługująca przechowywanie danych
na dysku (np. w plikach). Można ją sobie wyobrażać jak stertę
pamięci (ang. heap) z możliwością zapisu na dysk. Zapis ten
musi być tak zorganizowany, żeby w przypadku awarii baza
mogła wrócić do poprzedniego poprawnego stanu.
Dalej jest warstwa, która organizuje dane tak, żeby można je
było łatwo odszukać po kluczu. Jest to rodzaj pamięci asocjacyj-
nej, takiej jak np. hash tablica, ale w naszym wypadku wymaga-
my jeszcze, żeby dane dały się przeglądać posortowane według
klucza. Do tego celu najczęściej używa się odmian zbalansowa-
nych drzew (B-Tree), my użyjemy struktury Skip List.
Lhimk
Lhimk jest środowiskiem dynamicznej kompilacji dla języka o tej
samej nazwie (Lhimk), który jest oparty na C. Lhimk jest językiem
obiektowym, o bardzo prostej składni, w zasadzie, każdy kto zna C/
C++ może od razu zacząć programować w Lhimku. Do składni C są
dodane klasy z wielodziedziczeniem (ang. multiinheritance) i możli-
wością przeciążania operatorów, szablony, sygnały, wyjątki i kilka
innych drobiazgów. Lhimk jest środowiskiem dynamicznej kompila-
cji, więc cały kod jest kompilowany w momencie uruchamiania pro-
gramu. Kompilator jest bardzo szybki, więc trwa to krócej niż łado-
wanie wielu bibliotek w skompilowanych programach.
Lhimk jest dostępny częściowo na licencji LGPL i częściowo
na licencji BSD. Wynika to z tego, że korzysta z kodu TCC, który
jest na licencji LGPL, natomiast moją intencją jest dawać wszyst-
ko na licencji BSD.
Software Developer’s Journal 11/2005 www.sdjournal.org
Najwyższa warstwa obsługuje transakcje aplikacji. LhimkDB
jest zbudowany korzystając z algorytmów nieblokujących, nie wy-
stępuje w niej zjawisko zakleszczenia (ang. deadlock). Jeżeli wy-
stąpi konflikt wśród transakcji, to jedna z nich jest unieważniana.
Jeżeli jakaś transakcja może być wciąż unieważniana powsta-
je tzw. livelock. Zapobiega się temu np. gwarantując, że transak-
cja, która zaczęła wcześniej na pewno skończy z powodzeniem.
Przyjrzyjmy się teraz po kolei tym wszystkim warstwom.
Warstwa przechowywania – UDB
Baza danych to nic innego, jak uporządkowana metoda dostępu
do danych na dysku (lub ogólniej – w pamięci trwałej). Zawsze
u podstawy każdej bazy danych leży jakiś zestaw mechanizmów
dający dostęp do zapisanych danych. Większość baz danych ma
własne mechanizmy stronicowania. Polegają one na podziele-
niu pliku (lub partycji) na strony, które są wczytywane do pamięci
i zapisywane na dysk. Specjalne algorytmy decydują o tym, kie-
dy i jakie strony wczytać, i które strony można zwolnić na dysk,
a które trzymać nadal w pamięci. Oczywiście mamy tu też odpo-
wiednie patenty, które urozmaicają życie programistów.
W starszych bazach danych występuje problem tzw. po-
dwójnego stronicowania (ang. double paging). Polega on na
tym, że jeżeli wczytujemy stronę z dysku do pamięci, to może
być ona zapisana, bez naszej ingerencji, z powrotem na dysk
przez system operacyjny, w ramach obsługi pamięci wirtual-
nej. Tak się dzieje, kiedy baza danych konkuruje o pamięć z in-
nymi programami, np. z serwerem WWW. Rozwiązaniem tego
problemu jest mapowanie stron na pamięć, przy użyciu funkcji
mmap (wszystkie funkcje systemowe podaję dla systemu Linux).
LhimkDB nie posiada własnego mechanizmu stronicowania.
Doszedłem do wniosku, że najlepiej będzie korzystać z mechani-
zmów systemu operacyjnego. Pierwszą zaletą jest to, że, oczy-
wiście, nie trzeba tego kodu pisać, i przez to LhimkDB jest prost-
szy i łatwiejszy w utrzymaniu. Druga zaleta jest taka, że system
mapując pliki na pamięć wykorzystuje niskopoziomowe mechani-
zmy procesorów. Adres w pamięci jest tłumaczony na adres stro-
ny+przesunięcie przez procesor z wykorzystaniem bardzo zopty-
malizowanych algorytmów (więcej na ten temat można przeczy-
tać książce Understanding the Linux Virtual Memory Manager
Mela Gormana, która jest dostępna w internecie). Cała obsługa
pamięci trwałej ze stronicowaniem polega na wywoływaniu mmap,
kiedy wczytujemy plik, msync, kiedy chcemy zapisać dane na
dysk, a zapis i odczyt wykonywane są przy pomocy memmove. Ta-
kie rozwiązanie ma też wady. Po pierwsze, jeżeli mapujemy ca-
ły plik na pamięć, to pojawia nam się ograniczenie wielkości pliku
do 3 GB, a w praktyce pewnie do 1 GB. Można to obejść na dwa
proste sposoby. Można podzielić plik na obszary, ale bardzo du-
że, np. Po 100 MB, wtedy wielkość zapisywanych danych będzie
ograniczona do wielkości takiej “strony”. Drugim sposobem jest
użycie 64-bitowego adresowania. Oba wyjścia mają sens i mogą
być w LhimkDB łatwo zaimplementowane.
Ostatnio niektóre bazy danych zaczęły stosować mmap do ob-
sługi stron, głównie, żeby uniknąć problemów z podwójnym stro-
nicowaniem. Bardzo rzadko spotyka się jednak rozwiązania, któ-
re, tak jak LhimkDB, korzystają z systemowych mechanizmów
stronicowania. Stosowanie mmap oznacza, że nie mamy kontro-
li nad tym kiedy dane będą zapisane na dysk. To znaczy, mo-
żemy się upewnić, że wszystkie brudne strony (ang. dirty pages)
zostały już zapisane przy pomocy msync, ale nie możemy zabro-
nić systemowi zapisać czegoś wcześniej. Na tym w końcu pole-
23
 Bazy
Danych

�����
�� ��
� ��
������
�������
� ��
Rysunek 2. Sposób zapisu danych w LhimkDB.
ga stronicowanie, że system decyduje co zrzucić na dysk, a co
trzymać w pamięci (istnieją polecenia systemowe mlock, mun-
lock, którymi możemy zabraniać i pozwalać systemowi zapisy-
wać strony na dysk, ale wtedy cała obsługa stronicowania spada
na nas). Musimy zatem tak zorganizować dane, żeby w każdej
chwili każda ich wersja była poprawna i dało się odtworzyć stan
do poprzedniej poprawnie zakończonej transakcji.
Najczęściej bazy danych korzystają z mechanizmu Write
Ahead Log (WAL), czyli najpierw zapisz do logu. Polega on na
�����������������������������������������������������
�����
�� ��
� ��
������
�������
� ��
�������������������������������������������������
������������������������������������������������������������������
�����
��� ��
�� ��
������
�������
�� ��
Rysunek 3. Sposób obsługi wielodostępu do danych. Transakcja
A zaczęła się wcześniej i w momencie jej startu ostatnią
zakończoną transakcją zapisu była transakcja
o numerze 100. Transakcja B zaczęła się później, poprosiła
o prawa do zapisu i dostała numer 101. Transakcja B zmienia
obiekt o PID 1, i wprowadza jego nową wartość pod aresem 30.
Jednak wciąż jest pamiętana stara wartość, i kiedy transakcja A
chce odczytać wartość obiektu PID(1), to dostaje stary adres 15.
Atomowy odczyt i zapis
Jeżeli kilka wątków zapisuje i odczytuje tę samą pamięć, to trze-
ba zapewnić, żeby operacje takie były atomowe. Najprostszą i naj-
częściej stosowaną metodą jest ustawianie loków, które z kolei ko-
rzystają z muteksów (semaforów) i liczników. Ostatnio pojawiły się
w procesorach tzw. operacje CAS (Compare and Swap). Nie wcho-
dząc w szczegóły, pozwalają one na atomowy odczyt i zapis frag-
mentów pamięci. Coraz częściej pojawiają się artykuły, biblioteki
i eksperymentalne programy korzystające z tych operacji. Wszyst-
kie przykłady pokazują, że aplikacje budowane przy pomocy ope-
racji atomowych działają szybciej niż aplikacje blokujące z lokami,
szczególnie w systemach wieloprocesorowych. LhimkDB jest przy-
gotowany na pracę przy pomocy operacji CAS.
tym, że przed każdą operacją zapisujemy do osobnego pliku (lo-
gu), dane, które pozwolą nam tę operację cofnąć (tzw. undo log).
Jeżeli chcemy robić to na poziomie pliku, to możemy np. przed
zmianą danych zapisać stare dane (wraz z adresem i długo-
ścią) do logu. W ten sposób stworzymy znany mechanizm pliku
z dziennikiem (ang. journaled file). Problem z tym rozwiązaniem
jest taki, że po każdej operacji na pliku, musimy mieć gwarancję,
że plik z logiem jest fizycznie zapisany (czyli wykonać jakiś sync
na pliku z logiem). Oznacza to, że będzie tyle operacji synchroni-
zacji ile zmian w bazie, a to może znacznie spowolnić działanie
bazy. Drugi problem polega na umożliwieniu dostępu do takie-
go pliku przez wiele wątków (lub procesów) jednocześnie. Zapi-
sy trzeba oczywiście wykonywać w sposób atomowy i nie mogą
interferować z odczytami. To można łatwo osiągnąć przy pomo-
cy sekcji krytycznych lub operacji CAS (więcej o operacjach CAS
w ramce obok). Ale nie chcemy, żeby transakcja mogła odczyty-
wać dane, które są zapisane przez inną transakcję, która jeszcze
nie skończyła (nie było commit). Bazy danych stosują w tym celu
kolejne mechanizmy loków (ang. locks). Takie loki są zakładane
najczęściej na całe strony. Jeżeli jeden wątek odczyta jakąś stro-
nę, to np. żaden inny wątek nie będzie mógł tej strony zmieniać.
Jeżeli transakcja obejmuje wiele stron, to może z łatwością dojść
do zakleszczenia (ang. deadlock), czyli sytuacji, kiedy np. wątek
A czeka aż wątek B zwolni stronę 1, a wątek B czeka aż wątek
A zwolni stronę 2. W takich bazach danych muszą być wprowa-
dzone specjalne mechanizmy wykrywające zakleszczenia, któ-
re reagują najczęściej zabijając przynajmniej jeden wątek (pro-
gramiści często o tym zapominają, a jest to źródło wielu weso-
łych nieporozumień z klientami). Takie czekanie na zasoby bar-
dzo spowalnia działanie aplikacji wielowątkowych (czyli np. ser-
werów WWW). Pojawiły się ostatnio rozwiązania oparte na algo-
rytmach nieużywających loków (ang. lockless lub lockfree). Naj-
częściej oparte są one na operacjach CAS i strukturach danych
z cieniem (ang. shadow data).
LhimkDB organizuje dane w pliku podobnie jak to się dzie-
je w strukturach danych z cieniem. Każda dana ma swój PID,
który jest adresem w pliku, który trzyma wszystkie PID (plik ten
w LhimkDB nazywany jest indeksem, nie mylić z indeksem
w sensie bazy danych). Przy każdym PID jest pamiętany adres
danych w pliku z danymi (w LhimkDB nazywany plikiem z rekor-
dami, znowu, nie mylić z rekordami w relacyjnej bazie danych).
PID jest zatem odpowiednikiem adresu dla obiektu. Obiekt mo-
żemy dowolnie przemieszczać w pliku rekordów, wystarczy wte-
dy wprowadzić jego nowy adres przy PIDw pliku indeksu.

24 www.sdjournal.org Software Developer’s Journal 11/2005

 Zbudujmy sobie bazę danych – LhimkDB

Listing 1. Fragment implementacji Skip List z artykułu Thomassa Niemanna “A compact guide to searching and sorting”
(http://epaperpress.com/sortsearch/index.html)
statusEnum findLeft(SkipList *This, keyType key, x->level = newLevel;
nodeType** node){ x->prev = This->update[0];
int i; if (x->prev == This->hdr){
nodeType *x = This->hdr; x->prev = NIL;
*node = NIL; }
for (i = This->listLevel; i >= 0; i--){ printf("update prev, x->prev %d:%d \n",
while (x->forward[i] != NIL x->prev->key, x->prev->rec.stuff);
&& compLT(x->forward[i]->key, key)){ for (i = 0; i <= newLevel; i++){
x = x->forward[i]; x->forward[i] = This->update[i]->forward[i];
} This->update[i]->forward[i] = x;
This->update[i] = x; }
} if (x->forward[0] != NIL){
*node = x; printf("update forward[0] prev, x->forward[0] %d:%d \n",
return STATUS_OK; x->forward[0]->key, x->forward[0]->rec.stuff);
} x->forward[0]->prev = x;
statusEnum insert(SkipList *This, keyType key, }
recType *rec){ return STATUS_OK;
int i, newLevel; }
nodeType *x; statusEnum delete(SkipList *This, keyType key){
findLeft(This,key, &x); int i;
x = x->forward[0]; nodeType *x;
if (x != NIL && x != This->hdr && compEQ(x->key, key)) findLeft(This,key, &x);
return STATUS_DUPLICATE_KEY; x = x->forward[0];
for ( if (x == NIL || !compEQ(x->key, key))
newLevel = 0; return STATUS_KEY_NOT_FOUND;
rand() < RAND_MAX/2 && newLevel < MAXLEVEL; for (i = 0; i <= This->listLevel; i++){
newLevel++); if (This->update[i]->forward[i] != x) break;
printf("new level: %d \n", newLevel); This->update[i]->forward[i] = x->forward[i];
if (newLevel > This->listLevel){ }
This->listLevel = newLevel; free (x);
} while ((This->listLevel > 0)
if ((x = malloc(sizeof(nodeType) && (This->hdr->forward[This->listLevel] == NIL))
+ newLevel*sizeof(nodeType *))) == 0) This->listLevel--;
return STATUS_MEM_EXHAUSTED; return STATUS_OK;
x->key = key; }
x->rec = *rec;

W LhimkDB pamiętamy jednak nie jeden adres, a dwa.
Dla każdego z dwóch adresów pamiętamy też numer transak-
cji, która wprowadzała te dane (patrz Rysunek 2.). Wyobraź-
my sobie, że mamy dwie transakcje A i B. Transakcja A zaczę-
ła się wcześniej i w momencie jej startu ostatnią zakończoną
transakcją zapisu była transakcja o numerze 100. Transakcja
B zaczęła się później, poprosiła o prawa do zapisu i dosta-
ła numer 101. Transakcja B zmienia obiekt o PID(1), i wpro-
wadza jego nową wartość pod adresem 30 (adres w pliku re-
kordów). Jednak wciąż jest pamiętana stara wartość, i kiedy
transakcja A chce odczytać wartość obiektu PID(1), to dostaje
stary adres 15 (patrz Rysunek 3.). W ten sposób zapisy trans-
akcji B nie będą w żaden sposób interferować z transakcją A.
Pojawia się ograniczenie, że w jednym czasie może być
tylko jedna transakcja z prawami zapisu. Nie jest to dla nas
problem, ponieważ mówimy tu o transakcjach niskopozio-
mowych, aplikacja będzie się posługiwać zupełnie innymi
transakcjami, które będą mogły dowolnie równolegle dzia-
łać. Oznacza to tylko tyle, że transakcje aplikacji będą musia-
ły commitować swoje zmiany po kolei. Trwa to zazwyczaj bar-
dzo krótko (na moim notebooku około 1/300 s) i nie stanowi
zasadniczego ograniczenia.
Drugi problem jest taki, że jeżeli od startu transakcji A by-
ły dwie transakcje B1 i B2, które zmieniały obiekt PID(1), to już
nie pamiętamy wersji o numerze 100, którą chciałaby odczytać
transakcja A. W takim wypadku występuje konflikt i transakcja
A jest unieważniana. Moje “badania” empiryczne pokazały, że nie
jest to przypadek częsty. Przy dziesięciu równolegle zapisujących
wątkach, walczących o 3 te same obiekty, występuje to zjawisko
w około 1% transakcji. Gdyby był to jednak znaczący problem,
zawsze można zapamiętywać więcej historycznych wartości.
Wiemy już jak obiekty są zapisywane, i jak są im przypo-
rządkowywane PID. Zastanówmy się nad zarządzaniem pamię-
cią. Obiekty są tworzone, kasowane, powstają nowe wersje itp.
W związku z tym muszą być mechanizmy, które zarządzają alo-
kacją i zwalnianiem pamięci. Jest to dosyć ciekawa dziedzina,
w przypadku alokacji pamięci, która będzie zapisywana na dysk
i odtwarzana z dysku, wcale nie ma tak dużo gotowych wzorco-

Software Developer’s Journal 11/2005 www.sdjournal.org 25

 Bazy
Danych
Listing 2. Transakcje mogą zostać odwołane, dlatego
muszą być wykonywane w pętli
DBSystem *dbs = DBSystem::new();
DBTransaction *dbt = dbs->startTransaction();
while(1) {
try() {
//kod transakcji
dbt->commit();
break;
} catch(e) {
if (e == TRANSACTION_ABORTED)
{ sposób szukamy 2 razy szybciej. Możemy też wziąć co czwarty
dbt->abort();
} Możemy wziąć co ósmy, co szesnasty, co 32. element itd. W ten
throw(e);
} zienia elementu jest zależna od logarytmu ilości obiektów. Dla
} statycznych danych nie ma problemu, żeby takie idealne drzewo
wych rozwiązań. Najciekawszy jest Vmalloc z AT&T autorstwa
Kiem-Phong Vo (http://www.research.att.com/sw/tools/vmalloc).
Jest to spora biblioteka z wieloma możliwościami. Dla mnie tro-
chę za ciężka i nie do końca rozumiem licencję (chyba jest w du-
chu BSD, ale jest tak długa, że nie mam czasu jej analizować).
Jest też trochę dokumentów w internecie włącznie z próbą opa-
tentowania banalnego algorytmu przez ... jakżeby inaczej IBM.
W LhimkDB jest obecnie takie rozwiązanie: Pamięć jest przy-
dzielana wielkościami będącymi potęgami 2. W momencie, kie-
dy jest zwalniany kawałek pamięci, jego adres jest dodawany do
tablicy o indeksie log2(wielkość) (czyli mamy tablicę 32 elemen-
tową, np. pamięć o wielkości 64 jest dodawana pod adresem 6,
pamięć 128 pod adresem 7 itp.). Kiedy chcemy zaalokować ka-
wałek o wielkości 128, sprawdzamy pod adresem 7, czy mamy
jakieś wolne kawałki pamięci. Jeżeli tak, to bierzemy pierwszy.
Jeżeli nie, to sprawdzamy, czy mamy jakieś kawałki o wielkości
256, 512 ... (czyli indeksy 8, 9 ...). Jeżeli nic nie znajdziemy, to
alokujemy pamięć na końcu pliku. Nie robię dwóch rzeczy: nie łą-
czę kawałków zwolnionej pamięci obok siebie i nie alokuję części
pamięci, zawsze alokuję całość. W tej chwili ten alokator spraw-
dza się bardzo dobrze. Oczywiście można go dowolnie wymie-
niać i dostosowywać do potrzeb swoich aplikacji.
W LhimkDB wszystkie te mechanizmy tworzą system nazwa-
ny UDB. Dalej pisząc o UDB będę miał na myśli zapis danych
z możliwością alokacji pamięci i przyznania unikalnego PID.
Pamięć asocjacyjna – SkipDB
Na poziomie UDB dane można odczytywać w momencie kie-
dy znamy ich PID. Jeżeli chcemy odszukiwać dane poda-
jąc klucz musimy mieć jakieś mechanizmy wyższego pozio-
mu. W bazach danych stosowane są zmodyfikowane algo-
rytmy znane ze zwykłych struktur danych: tablice asocjacyj-
ne (ang. hash tables), drzewa binarne (B-Tree) itp. Najczęściej
w bazach danych stosowana jest jakaś wersja B+-tree/B*-
tree. Więcej na ten temat można przeczytać w artykule: Tho-
massa Niemanna A compact guide to searching and sorting
(http://epaperpress.com/sortsearch/index.html).
LhimkDB stosuje algorytm Skip List, wymyślony w 1989 r.
przez Billa Pugha (http://www.cs.umd.edu/~pugh/). Jest to tak
prosty algorytm, że mogę go wyjaśnić tutaj w dwóch akapitach.
26 www.sdjournal.org
Najprostszym rozwiązaniem byłoby trzymanie rekordów
w postaci [klucz, dane, PID następnego rekordu] (taki rodzaj li-
sty, gdzie zamiast adresu jest PID). Wtedy znalezienie rekordu
o podanym kluczu polegałoby na przejrzeniu takiej listy, aż od-
najdziemy żądany klucz. Możemy te rekordy trzymać w postaci
posortowanej i wtedy, kiedy znajdziemy rekord, o większym klu-
czu, wiemy, że nie ma co dalej szukać, naszego klucza już nie
znajdziemy (nazwijmy taką posortowaną listę L0). Wyobraźmy
sobie, że mamy 100 rekordów na takiej liście. Bierzemy co dru-
gi rekord i tworzymy kolejną listę (nazwijmy ją L1). Teraz może-
my najpierw odszukać największy klucz niewiększy od naszego
na liście L1, a potem sprawdzić na L0, czy mamy trafienie. W ten
element i zrobić listę L2. Teraz będziemy szukać 4 razy szybciej.
sposób utworzymy drzewo binarne, w którym szybkość odnale-
utworzyć. Gorzej jest kiedy dane do drzewa są dodawane, usu-
wane i nie wiemy w jakiej kolejności i co nadejdzie dalej.
Genialny pomysł Skip List polega na tym, że przy każdym
wkładanym elemencie losujemy do jakich list go zapisać. Z praw-
dopodobieństwem 1 do listy L0. Z prawdopodobieństwem 1/2 do
listy L1, 1/4 do L2 itd. W ten sposób zawsze na L0 będą wszyst-
kie elementy, na L1 mniej więcej połowa, na L2 jedna czwarta
itd. Statystycznie będzie to dokładnie to samo jakbyśmy ręcznie
robili listy ze statycznego zbioru danych. Co więcej, algorytmy są
banalne, można je zamieścić w tym artykule (Listing 1.). Dla po-
równania, usuwanie elementu z B+-tree jest tematem całych roz-
praw (np. Jan Jannink Implementing deletion in B+-Trees).
Implementacja Skip List w SkipDB jest praktycznie taka
sama. Uwzględnia tylko wykorzystanie PID zamiast wskaźni-
ków i obsługę transakcji. SkipDB zapamiętuje odczytane raz
obiekty (tworzy cache), więc odwoływanie się kilka razy do
tych samych danych jest bardzo szybkie.
Transakcje wysokiego poziomu
UDB i SkipDB, korzystający z UDB, mają pojęcie transakcji
na poziomie operacji na dysku. Z opisu UDB wiemy, że w jed-
nym czasie może być tylko jedna zapisująca transakcja dys-
kowa. Programista tworzący aplikacje wielowątkowe przy uży-
ciu LhimkDB powinien korzystać z transakcji wyższego pozio-
mu. Transakcja taka ma klon SkipDB, do którego będzie zapi-
W Sieci
• Strona domowa projektu Lhimk i LhimkDB
http://www.lhimk.org/
• Berkeley DB
http://www.sleepycat.com/
• Baza danych PBL na licencji LGPL
http://mission.base.com/peter/source/
• Baza danych MetaKit
http://www.equi4.com/metakit.html
• SkipDB autorstwa Steva Dekorte
http://www.dekorte.com/
• Vmalloc z AT&T autorstwa Kiem-Phong Vo
http://www.research.att.com/sw/tools/vmalloc
• Strona domowa Billa Pugha
http://www.cs.umd.edu/~pugh/
Software Developer’s Journal 11/2005
 Zbudujmy sobie bazę danych – LhimkDB
sywać dane (baza docelowa) i własne SkipDB używane wy-
łącznie jako cache (baza podręczna). Transakcje współdzielą
między sobą wyłącznie obiekt pliku (część UDB), więc wspól-
ny dostęp musi być kontrolowany wyłącznie do danych pliku.
Transakcja LhimkDB działa tak: kiedy czyta rekord, naj-
pierw czyta z bazy podręcznej. Jeżeli tam go nie ma, to spraw-
dza w bazie docelowej. Jeżeli chce zmienić rekord, to wprowa-
dza te zmiany tylko do bazy podręcznej. Dopiero po sprawdze-
niu wszelkich ewentualnych konfliktów, kiedy jesteśmy pewni, że
transakcja zakończyła się sukcesem, następuje przepisywanie
zmian z bazy podręcznej do docelowej. Czyli w jednym czasie,
tylko jedna transakcja może wykonywać commit. Transakcja jest
zatem materializowana w postaci zapisów do bazy podręcznej.
Jeżeli będziemy tę bazę zapisywać (domyślnie jest tylko w pa-
mięci), to mamy transakcje długie (trwałe), które możemy nawet
nazywać. Jeżeli będziemy z kolei tworzyć hierarchię takich baz
podręcznych, uzyskamy transakcje zagnieżdżone.
Trzeba pamiętać, że transakcja może zostać unieważnio-
na. Dlatego, jeżeli chcemy mieć gwarancję, że transakcja się
wykona, trzeba ją wykonywać w pętli (Listing 2).
Możliwe rozszerzenia
Najważniejszym rozszerzeniem, jakie jest w LhimkDB, jest to,
że to nie jest baza klucz-dane, a tak naprawdę baza drzewiasta.
Oznacza to, że każdy element bazy może mieć podelementy ad-
resowane kluczami. Jest to bardzo podobne do bazy standar-
du MUMPS, które są powszechnie stosowane w największych
i najbardziej skomplikowanych aplikacjach (np. w bankach, apli-
kacjach medycznych itp.). Na bazie tej hierarchii jest też budo-
wany system bezpieczeństwa, który przypomina system bez-
pieczeństwa systemu plików. W każdym węźle jest określone kto
może wykonywać i jakie operacje na elementach tego węzła. Je-
śli dodamy, że Lhimk ma implementację serwera WWW, to ma-
my kompletne środowisko do tworzenia aplikacji webowych.
Dlaczego takie środowisko jest ważne? Nie wystarczy
nam PHP+MySQL?
Każdy, kto budował większe aplikacje przy użyciu serwera
SQL, wie, że w zasadzie serwer SQL architektonicznie się do te-
go nie nadaje. Można tego “naukowo” dowieźć. Weźmy dowolną
operację na danych w takiej aplikacji (np. dekretację dokumen-
tu). Jeżeli jest ona wykonywana raz, to może być zrealizowa-
na przy pomocy sekwencji: odczytaj z SQL, przetwórz w aplika-
cji, zapisz do SQL. Ale jeśli będziemy ją chcieli wywołać np. dla
1000 elementów, to okaże się, że przetwórz w aplikacji musimy
zapisać w postaci procedury SQL. W ten sposób cały nasz kod
z czasem wyemigruje do SQL, a w “aplikacji” zostanie tylko po-
kazywanie danych. Jest to szczególnie drastycznie widoczne
przy aplikacjach webowych, gdzie nic się klientowi nie pokazu-
je, tylko wysyła HTML. Stąd pomysły, żeby np. do serwera SQL
dobudować serwer HTTP. Te pomysły zostały zarzucone, po-
nieważ architektury serwerów SQL zakładają stałe połączenie
z klientem, a HTTP jest protokołem bezstanowym. Rozwiąza-
niem może być zatem wbudowanie bazy danych do serwera
aplikacyjnego i serwera HTTP. I takie rozwiązanie jest w Lhimku.
Podsumowanie
LhimkDB jest pisany z myślą o nowoczesnych wielowątko-
wych aplikacjach uruchamianych na nowoczesnym sprzęcie
i systemach operacyjnych. Jest to nowe rozwiązanie, na pew-
no nie osiągnęło jeszcze 100 % zaufania, ale kod jest prosty
i jest go niewiele. Wszystkie podstawowe rzeczy można by-
ło wytłumaczyć w jednym artykule. Sama implementacja jest
dość obiecująca. Na pewno jest bardzo dużo miejsca na opty-
malizację i poprawę, ale i bez tego dziś LhimkDB działa szyb-
ko i stabilnie.
W tej części pokazałem ogólną architekturę LhimkDB.
W następnych częściach zajmiemy się szczegółowo budowa-
niem opisanych tu warstw bazy danych. n
 Bazy
Danych
Zbudujmy sobie bazę danych – LhimkDB
Paweł Marciniak
cz 2 Budujemy warstwę dostępu do danych
M
iesiąc temu rozpocząłem cykl artykułów
opisujący jak zbudować od podstaw bazę
danych. Budujemy bazę danych do wbudo-
wywania do programów (ang. embedded database),
o architekturze klucz-wartość (ang. key-value). W po-
przednim artykule podałem motywację, dlaczego ta-
ką bazę warto zbudować i pokazałem cały projekt,
jego założenia i elementy. Dla przypomnienia na ry-
sunku 1. pokazany jest schemat całej bazy LhimkDB.
W tym artykule zajmiemy się najniższą warstwą,
czyli warstwą dostępu do danych – UDB (ang. Unor-
dered Database). UDB jest oczywiście częścią
LhimkDB, ale zarówno jego zadania, jak i sposób im-
plementacji są na tyle niezależne, że mogą zaintere-
sować kogoś, kto chce mieć po prostu trwałą pamięć
dla swoich programów. Innymi słowy UDB może być
używane jak niezależna biblioteka.
LhimkDB jest pisany w języku Lhimk. Język ten
jest na tyle podobny do C/C++, że nie ma sensu
się go uczyć, czy wyjaśniać jak w nim pisać progra-
my. Te elementy, które występują w Lhimku, a nie
ma ich w C/C++ są omówione w ramce “Lhimk” lub
w samym tekście artykułu. Jeżeli ktoś nie chce uży-
wać Lhimka (co całkowicie rozumiem), to może z ła-
twością pokazany kod przepisać w C++. Można też
z Lhimka korzystać z wewnątrz programów napisa-
nych w C/C++.
Założenia
Po pierwsze ustalmy, czego od UDB oczekujemy.
UDB można przyrównać do obsługi pamięci na ster-
cie (ang. heap memory). Tyle, że będzie to pamięć
trwała (ang. persistent) i z obsługą transakcji. Naj-
lepiej zdecydować, jaki będzie interfejs, czyli jakie
funkcje UDB będzie udostępniać. Potrzebujemy ta-
kich metod:
l pid _ t put(char d[[]]) – umieszczenie danych w pa-
mięci trwałej, zwraca pid, przy pomocy którego
będziemy mogli się później do tych danych od-
wołać
l putAt(pid _ t pid, char d[[]]) – umieszczenie
danych w pamięci pod konkretnym pid (zmiana
starych danych)
l char at(pid _ t pid)[[]] – odczytanie danych
z podanego pid (tego, który zwraca put)
Paweł od 20 lat zajmuje się tworzeniem oprogramowa-
nia, głównie w C/C++. Od trzech lat rozwija system dy-
namicznej kompilacji Lhimk.
Kontakt z autorem: pawel@software.com.pl
42 www.sdjournal.org
������� ������������������
����������
��������� �����������
�������
��������������
�������
���������
�������
���
�������
��������������
��������� ����������
�����
Rysunek 1. Architektura LhimkDB
l remove(pid _ t pid) – usunięcie danych zapisa-
nych pod podanym pid (pid może być potem po-
nownie użyte, do innych danych)
l beginTransaction() -- rozpoczęcie transakcji zapisu
l commitTransaction() -- zakończenie transak-
cji wraz z zapisaniem danych. Nie potrzebujemy
rollback. Jeżeli nie chcemy zakończyć transak-
cji, po prostu nie zrobimy commitTransaction().
To jest w zasadzie całe API. Typ char[[]] to równo-
ważnik (char* buf, uint len), czyli dynamicznej ta-
blicy z zapisaną długością. Jest to jeden z tych nielicz-
nych elementów, które są w Lhimku, a nie ma ich w C/
C++ (notacja char fun()[[]], oznacza, że fun zwraca
char[[]], choć dziwnie to wygląda, jest to notacja z C).
Jeśli chodzi o obsługę transakcji, to chcemy mieć moż-
liwość jednego wątku zapisującego i wielu wątków czy-
tających. Wątki czytające powinny widzieć tylko te da-
ne, które zostały wcześniej wprowadzone i zatwierdzo-
ne przez commitTransaction() (dokładnie mówiąc, wą-
tek czytając dwa razy dane pod tym samym pid po-
winien dostać dwa razy te same dane, czyli interesu-
ją nas tylko te zmiany, które zostały dokonane i za-
twierdzone zanim nasz wątek zaczął czytać). Oczywi-
ście w przypadku awarii chcemy mieć gwarancję, że po
ponownym podłączeniu bazy danych, będziemy czy-
tać tylko wartości wprowadzone, przez poprawnie za-
kończone transakcje (innymi słowy, jeśli awaria wystąpi
w trakcie transakcji zapisu, to chcemy zapisy tej trans-
akcji anulować).
Dodatkowo, nie chcemy mieć żadnych ograni-
czeń, ani na wielkość zapisywanych danych (do wiel-
kości całej dostępnej pamięci), ani na wielkość całej
bazy danych (do maksymalnej wielkości plików), ani
na wielkość transakcji.
Obsługa plików
U podstawy każdej bazy danych leży obsługa syste-
mu plików. To właśnie zapis do pliku daje nam trwa-
Software Developer’s Journal 12/2005
 Zbudujmy sobie bazę danych – LhimkDB
�����
�� ��
� ��
������
�������
� ��
Rysunek 2. Sposób zapisu danych w UDB
łość (ang. persistance). W LhimkDB pliki są obsługiwane
przez klasę MFile – Memory Mapped File.
Idea jest taka:
• Otwieramy plik (lub tworzymy nowy)
• Mapujemy plik na pamięć -- wywołanie mmap (wszystkie
funkcje systemowe podaję dla Linuksa)
• Odczyty i zapisy wykonujemy przy pomocy memcpy
• Wszystkie operacje zapisu i odczytu są chronione przez
mutex
• Tylko jeden wątek może mieć w jednej chwili prawa do zapisu
Najprostsza wersja klasy MFile jest przedstawiona na Listin-
gu 1. Jest to w pełni wielowątkowa wersja klasy MFile, która
spełnia wszystkie nasze założenia, poza obsługą dużych pli-
ków (teoretycznie do 4GB, w praktyce do 1GB). Kod tej klasy
jest bardzo prosty i czytelny. Jedyne trudności rodzi wielowąt-
kowy dostęp, dlatego trzeba utrzymywać minimalną funkcjo-
nalność takich klas.
Obiekt MFile będzie praktycznie jedynym obiektem
współdzielonym przez różne wątki UDB (i dalej LhimkDB).
To znaczy, że różne wątki będą miały wskaźnik do tego sa-
mego obiektu MFile. Kolejne klasy i obiekty, które będzie-
my dalej omawiać, nie będą już współdzielone pomiędzy
wątkami -- wątki będą je tworzyć samodzielnie. Jeżeli no-
wy wątek chce używać obiektu MFile, musi utworzyć jego
klona:
MFile *mf = mf_base->clone();
Zwiększane jest wtedy pole usage. Plik jest zamykany kiedy
usage osiąga 0.
Zobaczmy teraz jak usunąć barierę wielkości plików.
Robimy to bardzo prosto poprzez system stron (ang. pa-
ges). Strony są powszechnie wykorzystywane w syste-
mach baz danych, ponieważ są one pochodną sposobu,
w jaki system operacyjny obsługuje zapis i odczyt plików.
System operacyjny robi to właśnie przy pomocy stron,
za jednym razem może odczytać lub zapisać jedną stro-
nę danych (w moim Linuksie jest to 4096 bajtów, można
to sprawdzić funkcją getpagesize()). Strony w bazach da-
nych mają zawsze rozmiar będący niewielką wielokrotno-
ścią strony systemowej (np. w PostgreSQL-u jest to do-
myślnie 8192 bajtów). Strony w bazach danych są jednost-
ką blokowania dostępu i często stanowią ograniczenie dla
wielkości jednego rekordu (większe dane trzeba zapisy-
Software Developer’s Journal 12/2005 www.sdjournal.org
wać w specjalnych typach, które zajmują kilka stron). Ge-
neralnie, im większy jest rozmiar strony tym baza danych
działa szybciej i można zapisywać większe dane, ale ma-
my mniejszą współbieżność.
Ale to jest prawda w tradycyjnych bazach danych, u nas
strony są podobne tylko z nazwy. W MFile strona nie stano-
wi jednostki blokowania dostępu, ani ograniczenia w wiel-
kości danych. Wielkość stron jest też dużo większa (wydaje
mi się, że optymalna wielkość strony to 4MB) i jest ich dużo
mniej. Zasada działania jest taka, że jeżeli chcemy coś zro-
bić pod adresem np. 12345, to prosimy klasę PageSystem,
aby dała nam stronę dla tego adresu. Wszystkie strony
trzymane są w tablicy, a ich indeks to adres/rozmiar _ stro-
ny. Jeżeli strona już jest utworzona, to jest po prostu zwra-
cana. Jeżeli nie, to jest tworzona, mapowana na pamięć
i zwracana. Jeżeli przekroczyliśmy limit ilości stron, to
ostatnio najmniej używana strona (ang. Least Recently
Used) jest zwalniana ( munmap).
Jeżeli rozmiar danych przekracza wielkość strony to za-
pis i odczyt są wykonywane w pętli aż cały bufor zostanie za-
pisany lub odczytany (Listing 2). W rezultacie możemy skon-
figurować MFile, żeby miał jedną małą stronę (np. 4096) i ob-
�����������������������������������������������������
�����
�� ��
� ��
������
�������
� ��
�������������������������������������������������
������������������������������������������������������������������
�����
��� ��
�� ��
������
�������
�� ��
Rysunek 3. Sposób obsługi wielodostępu do danych.
Transakcja A zaczęła się wcześniej i w momencie jej startu
ostatnią zakończoną transakcją zapisu była transakcja o
numerze 100. Transakcja B zaczęła się później, poprosiła o
prawa do zapisu i dostała numer 101. Transakcja B zmienia
obiekt o PID 1, i wprowadza jego nową wartość pod aresem
30. Jednak wciąż jest pamiętana stara wartość, i kiedy
transakcja A chce odczytać wartość obiektu PID(1), to
dostaje stary adres 15.
43
 Bazy
Danych
sługiwać zapis i odczyt 100MB z 10GB plików. Tyle, że bę-
dzie to długo trwało. Rozmiary i ilość stron są limitowane tak
naprawdę tym, ile możemy zająć z przestrzeni adresowej (nie
z pamięci!). Jeżeli np. jeden obiekt MFile zabierze 100MB
z przestrzeni adresowej, to będziemy mogli takich plików
otworzyć za jednym razem około 10-ciu. Jeżeli nie planuje-
my otwierania dużej ilości plików, nasza aplikacja jest np. de-
dykowanym serwerem, to warto zająć nawet 1GB przestrze-
ni adresowej. Oczywiście problem znika (przynajmniej teo-
retycznie) na maszynach 64-bitowych. Na takich maszynach
cały ten system stronicowania ma niewielki sens, lepiej pod-
piąć cały plik i niech dalej się martwi system operacyjny.
Mamy zatem metodę trwałego zapisu dowolnie dużych
danych w dowolnie dużych plikach. W MFile nie ma poję-
cia transakcji, commit oznacza tylko tyle, że będzie zsynchro-
nizowana zawartość pamięci i pliku, czyli wszystko zostanie
na pewno na dysk zapisane. Musimy zatem dodać funkcjonal-
ność, która obsłuży transakcje.
UDBIndex
Przechodzimy do właściwej klasy UDB. Tak naprawdę to skła-
da się ona z 4 klas: UDBIndex, UDBRecord, UDBRecords
i UDB. Koncepcja jest taka, że będziemy wykorzystywać dwa
pliki -- Index i Records. Zajmiemy się teraz klasą UDBIndex,
która implementuje Index.
Index jest czymś w rodzaju tablicy wskaźników. Jeże-
li chcemy odczytać dane (rekord) zapisane pod pid=10, to
sięgamy do 10-tej komórki w pliku Index (mówiąc ściśle, to
dla dziesiątego obiektu pid=9, gdyż numerujemy od 0), od-
czytujemy pozycję danych w pliku Records i potem odczytu-
jemy same dane z pliku Records (najpierw nagłówek, w któ-
rym jest zapisana długość tych danych, a potem same da-
ne). W ten sposób możemy dowolnie przemieszczać dane
w pliku Records, bez zmiany pid. Pid jest odpowiednikiem
wskaźnika, to właśnie przy pomocy pid będziemy się do
konkretnych danych dalej odwoływać.
Jest tutaj jedna drobna komplikacja. Otóż, w pliku In-
dex zapamiętujemy dwie pozycje, a nie jedną. Każda
z nich ma przypisany numer transakcji, która dane pod tą
pozycją zapisała. Transakcja, kiedy chce odczytać dane,
podaje również numer ostatniej zatwierdzonej transakcji
(ang. commited), którą akceptuje (ten który był w momen-
cie rozpoczęcia odczytu). W odpowiedzi podawana jest
nowsza pozycja, ale starsza od naszej aktualnej transak-
cji. Mówiąc innymi słowy, pamiętamy zawsze jedną histo-
ryczną wartość. Jeżeli wątek nie chce wartości najnow-
szej (bo mógł wcześniej przeczytać starszą wartość), to
dajemy mu wartość starszą. Jest to pokazane na Rysun-
ku 2. i Rysunku 3.
Oczywiście może się zdarzyć tak, że od czasu wystar-
towania naszej transakcji czytającej, dwie różne transakcje
zmieniły dane pod odczytywanym pid. Wtedy nie ma już hi-
storycznej wartości, która byłaby dla nas dobra. W takim wy-
padku jest wyrzucany wyjątek i transakcja zawodzi. (Jeże-
li jedna transakcja będzie zmieniać kilka razy te same dane, to
nic złego się nie stanie, bo będzie zawsze modyfikować naj-
nowszą pozycję w naszej parze).
UDBIndex przyznaje również pid nowym rekordom. W tym
celu prowadzi listę nieużywanych pid, jak i licznik zapamiętu-
jący największy użyty pid.
44 www.sdjournal.org
UDBIndex zapamiętuje na początku swojego pliku na-
główek, w którym zapisuje numer ostatnio zakomitowa-
nej transakcji (last _ commited) i numer aktualnie działają-
cej transakcji (current). W momencie startu transakcji zapi-
su (begin()) jest zwiększany o jeden numer aktualnej trans-
akcji i nagłówek jest zapisywany (jest wykonywana trans-
akcja pliku MFile). Jeżeli przy otwieraniu pliku okaże się,
Lhimk
Lhimk jest środowiskiem dynamicznej kompilacji dla języka
o tej samej nazwie (Lhimk), który jest oparty na C. Lhimk jest ję-
zykiem obiektowym, o bardzo prostej składni, w zasadzie, każ-
dy kto zna C/C++ może od razu zacząć programować w Lhim-
ku. Do składni C są dodane klasy z wielodziedziczeniem (ang.
multiinheritance) i możliwością przeciążania operatorów, szablo-
ny, sygnały, wyjątki i kilka innych drobiazgów. Lhimk jest środo-
wiskiem dynamicznej kompilacji, więc cały kod jest kompilowa-
ny w momencie uruchamiania programu. Kompilator jest bardzo
szybki, więc trwa to krócej niż ładowanie wielu bibliotek w skom-
pilowanych programach.
Lhimk jest dostępny częściowo na licencji LGPL i częścio-
wo na licencji BSD. Wynika to z tego, że korzysta z kodu TinyCC,
który jest na licencji LGPL, natomiast moją intencją jest dawać
wszystko na licencji BSD.
Podstawową jednostką kodu w Lhimku jest moduł. Każdy mo-
duł ma unikalny adres, np.:
\lhimk.org\Db\UDB
W Lhimku nie ma podziału na pliki nagłówkowe i implementa-
cję. Jak chcemy się odwołać do jakiegoś typu lub obiektu z in-
nego modułu, po prostu podajemy całą ścieżkę. To jest np. od-
wołanie do klasy UDB (odwołania do typów poprzedzone są zna-
kiem '@'):
@\lhimk.org\Db\UDB\UDB
Na końcu jest dwa razy UDB, ponieważ klasa UDB jest w module
UDB. Obiekty globalne (czyli wbudowane funkcje) są po prostu po-
przedzane przez '\', np.:
\printf(“Hello!\n”);
Klasa może mieć metody wirtualne, albo statyczne. W Lhimku ra-
czej nie używa się referencji do obiektów, a wyłącznie wskaźniki
(Lhimk ma wbudowany garbage collector). Nowy obiekt najczęściej
tworzony jest tak:
@\lhimk.org\Db\UDB\UDB *udb = \lhimk.org\Db\UDB\UDB::new();
Gdzie metoda new jest zwykłą metodą statyczną zwracającą
UDB*.
Szablony są realizowane na poziomie modułu, który jest jed-
nostką kompilacji. Jeżeli chcemy mieć np. listę integerów, napi-
szemy to tak:
@\lhimk.org\LTL\List\List[int T] *udb = @\lhimk.org\LTL\List\
List[int T]::new();
W ten sposób moduł \lhimk.org\LTL\List\ zostanie przekompilowa-
ny z typem T zdefiniowanym jako int. Jest to podejście dużo prostsze
niż w C++, a czasami daje dużo lepsze możliwości (można np. w za-
leżności od typu T dodawać do klas poszczególne metody).
To chyba cały podręcznik Lhimka...
Software Developer’s Journal 12/2005
 Zbudujmy sobie bazę danych – LhimkDB

Listing 1. Najprostsza implementacja klasy MFile

class MFile { this->_p->maxPos = noff;
MFilePrivate* _p; this->_p->buf = this->_p->file->mmap(
int init(char* path, char* ext) { pthis->buf, pthis->maxPos, "rw", "s", 0);
this->_p = MFilePrivate::new(); return 0;
//... inicjalizacja pól wycięta ... };
this->open(); int truncate(unsigned long long off) {
return 0; LOCK;
}; this->_truncate_(off);
constructor new(char* path, char* ext) { UNLOCK;
MFile* this = \lhc\new(MFile*); };
this->init(path, ext); int write(unsigned long long pos, void *buf,
return this; unsigned int size) {
}; if (!this->canWrite()) {
void free() { ERROR("MFile::write, thread can not write",
if (this->canWrite()) { ERROR_MINOR);
this->finishWrite(); }
} LOCK;
//Musimy zablokować cały blok if (pos+size >= this->_p->maxPos) {
//ponieważ inne wątki mogą zmieniać usage //truncate without locking
//w tym samym czasie this->_truncate_(pos+size);
LOCK_USAGE; }
if (this->_p->usage<0) { \memmove(this->_p->buf + pos, buf, size);
ERROR("USAGE<0", ERROR_FATAL); this->_p->needsSync = 1;
} UNLOCK;
if (this->_p->usage > 0) { return 0;
this->_p->usage--; };
UNLOCK_USAGE; int read(unsigned long long pos, void *buf,
} else { unsigned int size) {
this->close(); if (pos + size > this->_p->maxPos) {
UNLOCK_USAGE; ERROR("Read out of range", ERROR_MINOR);
\free(this->_p); }
\free(this); LOCK;
} \memmove(buf, this->_p->buf + pos, size);
}; UNLOCK;
MFile *clone() { return 0;
LOCK_USAGE; };
this->_mfile_p->usage++; int sync() {
UNLOCK_USAGE; this->_p->file->msync(this->_p->buf, this->_p->maxPos);
return this; return 0;
}; };
int open() { int commit() {
this->_p->needsSync = 0; return this->sync();
this->_p->file->open("a+"); };
this->_p->maxPos = this->_p->file->size(); int startWrite() {
return 0; LOCK_WRITE;
}; this->_p->write_thread = \lpth\Thread::self();
int close() { };
this->_p->file->munmap(this->_p->buf, int finishWrite() {
this->_p->maxPos); this->_p->write_thread = 0x0;
this->_p->file->close(); UNLOCK_WRITE;
return 0; };
}; int canWrite() {
int _truncate_(unsigned long long off) { int ret = 0;
//Plik powiększamy o GROWSTEP if (((void*)this->_p->write_thread) != 0x0) {
unsigned long long noff = ret = this->_p->write_thread ==
(off/GROWSTEP +1) * GROWSTEP; \lpth\Thread::self();
if (this->_p->buf != 0x0 && this->_p->maxPos>0) { }
this->_p->file->munmap(this->_p->buf, return ret;
this->_p->maxPos); };
} };
this->_p->file->ftruncate(noff);

Software Developer’s Journal 12/2005 www.sdjournal.org 45

 Bazy
Danych

Listing 2. Pętla zapisująca dane dowolnej wielkości, Listing 4. Przykłady użycia UDB
niezależnie od wielkości strony.
@\ludb\UDB *udb = \ludb\UDB::new("TESTUDB", 1);
while(size > 0)
{ unsigned long long pid1, pid2, pid3;
Page* p = this->_mfile_p->
page_system->getPageForPos(pos); udb->beginTransaction();
pid1 = udb->putBuf("aaa",4);
unsigned int n_pos = pos - p->off; pid2 = udb->putBuf("bbb",4);
unsigned int wsize = ( (p->size()-n_pos)> pid3 = udb->putBuf("ccc",4);
size ? size : (p->size()-n_pos)); udb->commitTransaction();

\memmove(p->buf + n_pos, buf, wsize); \printf("%llu : %s \n", pid1, udb->at(pid1)->data);

\printf("%llu : %s \n", pid2, udb->at(pid2)->data);
size -= wsize; \printf("%llu : %s \n", pid3, udb->at(pid3)->data);
pos += wsize;
buf += wsize; udb->free();
}

drugim. Znając zatem rozmiar możemy je z łatwością se-

że ostatnia transakcja została przerwana (last _ commi-
ted!=current), to są przeglądane wszystkie zapisy w in-
deksie i usuwane są te, które odnoszą się do przerwanej
transakcji. Jest to całe recovery po awarii bazy danych.
Jest to bardzo szybkie i umożliwia szybkie ponowne włą-
czenie np. serwisu internetowego (oczywiście zależy to od
wielkości pliku, ale przeglądany jest plik indeksu, a nie plik
z danymi!) .
UDBRecord
i UDBRecords
Rekord (nie mylić z rekordem w relacyjnej bazie danych)
składa się z nagłówka i z danych. W nagłówku pamięta-
ny jest rozmiar rekordu, pid i jego stan, czyli, czy nie zo-
stał skasowany. Rekordy są zapisywane do pliku jeden po
Listing 3. Metody odczytujące nagłówek i dane rekordu.
int readHeader()
{ stercie). W tej chwili wykorzystywany jest taki algorytm:
this->_p->file->read(this->_p->pos, (unsigned char *)
(this->_p->header),
sizeof(UDBRecordHeader));
return 1;
};
char readDatum()[[ ]]
{ rozmiarze 2^n (np. pod adresem 10, są bloki o wielkości
unsigned int size = this->_p->header->size;
char d[[ ]] = \lhc\array_new(char[[]],size);
\array_resize(d, size);
this->_p->file->read(this->_p->pos +
sizeof(UDBRecordHeader),
d->data, size);
return d;
};
kwencyjnie przeglądać (część z nich może mieć ustawio-
ne w nagłówku, że są usunięte). Odczyt rekordu odby-
wa się w dwóch krokach. Najpierw czytany jest nagłówek,
w którym zapisany jest rozmiar danych. Potem, kiedy znamy
już rozmiar danych, możemy przeczytać dane (Listing 3.).
Jeżeli chcemy rekord usunąć ustawiamy mu flagę w na-
główku i zapisujemy (zajęta przez niego przestrzeń jest do-
dawana do puli bloków do wykorzystania, o czym piszę da-
lej).
Na tym poziomie nie martwimy się już o współbieżność,
bo współdzielony między wątkami jest tylko obiekt MFile, któ-
ry sam się o współbieżność martwi.
UDB
i alokacja pamięci
UDB jest połączeniem UDBIndex i UDBRecord. W zasadzie
stanowi jednolite API dostępu do obu tych klas.
UDB poza prostymi porządkowymi pracami odpowiada za
alokację przestrzeni w pliku (podobnie jak robi to malloc na
• Alokowane są ilości pamięci będące potęgami 2 (32, 64,
128 ... 1024 itp. bajtów)
• Wolne bloki pamięci trzymane są w tablicy kolejek. Ta-
blica ma rozmiar 32 (w systemach 64-bitowych mo-
że mieć rozmiar 64, jeżeli ktoś planuje alokowanie blo-
ków powyżej 4GB). Pod adresem n są trzymane bloki o
1024 bajtów).
• Jeżeli chcemy zaalokować pamięć dla bloku o wielkości
x, to znajdujemy takie n, że 2^n>=x i patrzymy, czy ma-
my jakieś wolne bloki w kolejce pod adresem n (jeżeli np.
chcemy zaalokować 700 bajtów, to n=10, bo 1024>700
i 512<700, szukamy najpierw zatem wolnych bloków
o wielkości 1024). Jeżeli nie ma wolnych bloków pod adre-
sem n, to patrzymy pod n+1, n+2 itd. Oczywiście im dalej
odejdziemy od n, tym więcej “stracimy” miejsca, alokując
np. 1024 bajty dla 16 bajtowego bloku, więc możemy ten
proces przerwać. Jeżeli znajdziemy dostępny blok, to alo-
kujemy go w całości.

46 www.sdjournal.org Software Developer’s Journal 12/2005

W sieci
l Strona domowa projektu Lhimk i LhimkDB
http://www.lhimk.org/
l Vmalloc z AT&T autorstwa Kiem-Phong Vo
http://www.research.att.com/sw/tools/vmalloc/

• Jeżeli nie znajdziemy odpowiedniego bloku, to alokujemy

miejsce na końcu pliku.

W momencie otwierania pliku są przeglądane wszystkie re-

kordy i rekordy ustawione jako usunięte są zapisywane do
tablicy kolejek jako wolna przestrzeń. Robi to osobny wątek,
więc nie opóźnia to samego otwarcia pliku i rozpoczęcia pracy
bazy danych. Poza tym nie są nigdzie w pliku zapamiętywane
informacje o alokacjach przestrzeni, więc system ten nie spo-
walnia wykonywania transakcji.

Przykłady użycia
Na Listingu 4. pokazany jest prosty kod korzystający
z UDB. Nie ma tu nic, co mogłoby kogoś zaskoczyć (mo-
że poza charakterystycznymi dla Lhimka znakami '\' przed
printf). Obiekt UDB jest tworzony, transakcja się zaczyna,
zapisujemy dane przy pomocy putBuf, odczytujemy przy
pomocy at.
W przypadku aplikacji wielowątkowych, trzeba bazowy
obiekt UDB przekazać do funkcji wątku i zamiast tworzyć no-
wy obiekt UDB klonujemy obiekt bazowy:

void thread_fun(@\ludb\UDB *base_udb)

{
@\ludb\UDB *udb = base_udb->clone();
... coś robimy ...
udb->free();
}

Trzeba też pamiętać, żeby operacje w wątku wykonywać we-

wnątrz try...catch, gdyż transakcja może zawieść nawet przy
odczycie (przy odczycie nie rozpoczynamy transakcji przez
beginTransaction).

Podsumowanie
Pokazałem jak od podstaw stworzyć warstwę dostępu do
danych – UDB. Udało się spełnić wszystkie zakładane za-
łożenia, włącznie z obsługą transakcji, wielowątkowości
oraz danych i plików dowolnej wielkości. Pokazane UDB
jest dość nietypowe, ale sprawdza się w praktyce. Jest bar-
dzo proste, przez co powinno mieć mało błędów. Z pobież-
nych testów wynika, że LhimkDB-UDB działa bardzo wydaj-
nie, nawet przy bardzo dużych plikach (rzędu 10GB). Moż-
na je też dowolnie konfigurować do potrzeb swoich aplika-
cji. Takie krytyczne parametry jak wielkość strony czy wiel-
kość, o którą zwiększamy plik (ang. grow step), mogą być
zmieniane dla istniejących plików, czego raczej nie spotyka
się w tradycyjnych bazach danych. Bardzo szybkie jest też
odtwarzanie po awarii, co jest szczególnie ważne w aplika-
cjach WWW.
Za miesiąc dodamy kolejną warstwę, która będzie odpo-
wiadać za dostęp do danych według klucza. n

Software Developer’s Journal 12/2005

 Bazy
danych
Zbudujmy sobie bazę danych – LhimkDB
Paweł Marciniak
cz 3. Budujemy warstwę dostępu wg klucza
D
wa miesiące temu rozpocząłem cykl artyku-
łów opisujący jak zbudować od podstaw ba-
zę danych. Budujemy bazę danych do wbu-
dowywania do programów (ang. embedded databa-
se), o architekturze klucz-wartość (ang. key-value).
W pierwszym artykule podałem motywację, dlaczego
taką bazę warto zbudować i pokazałem cały projekt, je-
go założenia i elementy. Dla przypomnienia na rysunku
1. pokazany jest schemat całej bazy LhimkDB. W po-
przednim artykule pokazałem jak zbudować warstwę
przechowywania danych – UDB (ang. Unordered Da-
tabase). W tym artykule zajmiemy się warstwą dającą
dostęp do danych wg klucza i umożliwiającą przegląda-
nie danych w uporządkowanej kolejności.
Dostęp do danych wg klucza będzie realizowa-
ny przy pomocy struktury SkipList. Najpierw poka-
żę jak zbudować ogólną klasę SkipList, a potem przy
pomocy pewnej sztuczki połączymy ją z UDB i uzy-
skamy bazę danych. Wszystkie te elementy są oczy-
wiście częścią LhimkDB, ale zarówno ich zadania,
jak i sposób implementacji są na tyle niezależne, że
mogą zainteresować kogoś, kto chce mieć po prostu
trwałą pamięć lub ciekawą strukturę danych typu po-
sortowana pamięć asocjacyjna, dla swoich progra-
mów. Innymi słowy, zarówno SkipList jak i UDB mo-
gą być używane jako niezależne biblioteki.
LhimkDB jest pisany w języku Lhimk. Język ten
jest na tyle podobny do C/C++, że nie ma sensu się
go uczyć, czy wyjaśniać jak w nim pisać programy.
Te elementy, które występują w Lhimku, a nie ma ich
w C/C++ są omówione w ramce “Lhimk” lub w samym
tekście artykułu. Jeżeli ktoś nie chce używać Lhimka
(co całkowicie rozumiem), to może z łatwością poka-
zany kod przepisać w C++. Można też z Lhimka ko-
rzystać z wewnątrz programów napisanych w C/C++.
Jeszcze o UDB
Oczywiście, nie byłbym sobą, gdybym już nie zmienił
tego, co opisałem w poprzednich artykułach. Uważ-
ni czytelnicy pamiętają, że w pokazywanym przeze
mnie rozwiązaniu UDB, były pamiętane 2 wartości
dla każdego obiektu – obecna i poprzednia. Pozwa-
lało to jednocześnie czytać i zmieniać dane. Niestety,
jeżeli transakcja czytająca trwała na tyle długo, żeby
w jej czasie wykonały się dwie transakcje zapisujące,
to mogły wystąpić konflikty przy czytaniu. Nie dawa-
Paweł od 20 lat zajmuje się tworzeniem oprogramowa-
nia, głównie w C/C++. Od trzech lat rozwija system dy-
namicznej kompilacji Lhimk.
Kontakt z autorem: pawel@lhimk.org
32 www.sdjournal.org
������� ������������������
����������
��������� �����������
�������
��������������
�������
���������
�������
���
�������
��������������
��������� ����������
�����
Rysunek 1. Architektura LhimkDB
ło mi to spać po nocach. W końcu znalazłem rozwią-
zanie, które zapamiętuje wszystkie wartości historycz-
ne, dla wszystkich wykonywanych aktualnie transak-
cji. Rozwiązanie jest trywialne: po prostu przy każdej
zmianie wartości obiektu tworzymy nowe PID, gdzie
zapamiętujemy wskaźnik do starej wersji. W ten spo-
sób powstaje nam lista wartości historycznych obiek-
tów. Są one usuwane z bazy, kiedy kończy się najstar-
sza transakcja czytająca, która mogłaby do tych da-
nych sięgnąć. W rezultacie mamy coś co producenci
baz danych reklamują jako funkcje OLAP, czyli moż-
liwość wykonywania długich analitycznych zapytań,
bez kolizji z transakcjami zapisującymi.
W tej chwili można korzystać z obydwu rozwią-
zań dla UDB. Przy okazji okazało się, że kod jest na-
prawdę bardzo modularny, bo wprowadzona zmiana
objęła tylko kilka metod UDBIndex.
Założenia
Podobnie jak w poprzednim artykule zaczniemy od
ustalenia, co chcemy osiągnąć. Mamy już napisane
UDB, które można przyrównać do obsługi pamięci na
stercie (ang. heap memory). Tyle, że UDB to pamięć
trwała (ang. persistent) i z obsługą transakcji. W UDB
każdy obiekt ma przypisany PID (daleki odpowiednik
wskaźnika), który pozwala odczytywać, zmieniać war-
tość i usuwać obiekty. Teraz dodamy możliwość za-
pisywania danych adresowanych dowolnym kluczem
(np. tekstem) i przeglądanie ich w kolejności tego klucza.
API jest zbudowane w sposób ogólny, bez zna-
jomości typów klucza (K) i wartości (T). Ponieważ
Lhimk wspiera szablony i programowanie generycz-
ne, można podawać dowolne typy, nie musimy ich
znać pisząc nasz kod.
A oto nasze API:
l operator[[K k]] – odczyt wartości zapisanej pod
kluczem k
l operator[[K k]]=T t – zapis wartości t pod klu-
czem k
Software Developer’s Journal 1/2006
 Zbudujmy sobie bazę danych – LhimkDB

�� �� �� �� �� �� �� �� � � � �

Rysunek 2. Zwykła posortowana lista (L0)

l remove(K k) – usunięcie wartości zapisanej pod kluczem k
l startTransaction() -- rozpoczęcie transakcji zapisu
l commitTransaction() -- koniec transakcji zapisu z potwier-
dzeniem wprowadzonych zmian
+ kod iteratora (end, next, prev itp.)
W tym momencie muszę trochę wyjaśnić, jak działa defi-
niowanie własnych operatorów w Lhimku. Po pierwsze, to co
napisałem powyżej, jest pseudokodem, w Lhimku nazwy ope-
ratorów, są legalnymi nazwami metod, bez żadnych dodatko-
wych znaków. Dla przykładu:
l operator _ bb – oznacza kod dla operatora [[]]
l operator _ bba – oznacza kod dla operatora [[]]=
l operator _ eq – oznacza kod dla operatora ==
itd. Ale to jest drobiazg. O wiele ciekawszy jest operator [[]]=
(operator _ bba). Otóż, w języku C++ jeżeli piszemy kod klasy
np. Vector i chcemy zrobić przypisanie do i-tej komórki, to wy-
gląda to mniej więcej tak:
T& operator[](K k)
Oznacza to, że metoda operatora zwróci referencję do obiek-
tu, więc w przypadku kodu:
v[10] = 20;
do komórki 10 jakoś “magicznie” zostanie przypisana wartość
20. Nie chcę krytykować C++, bo naprawdę lubię ten język
i napisałem w nim sporo dużych programów. Ale akurat refe-
rencje, to jest coś, czego serdecznie nie znoszę. Pewnie je-
stem za głupi, żeby je zrozumieć. Dlatego celowo nie doda-
łem ich do Lhimka (choć kilka razy kusiło).
Kiedy piszemy kod klasy Vector, to tak naprawdę chcemy
mieć jakiś operator, który będzie odpowiednikiem metody in-
sert. W Lhimku jest taki operator, to: [[]]= (albo: []= lub {}=).
Jeżeli mamy zdefiniowany taki operator, to kod:
�� �� �� �� �� �� �� ��
Rysunek 3. Posortowana lista z linkiem pomiędzy co drugim
elementem (L0)
W bazach danych stosowane są zmodyfikowane algorytmy
znane ze zwykłych struktur danych: tablice asocjacyjne (ang.
hash tables), drzewa binarne (B-Tree) itp. Najczęściej w ba-
zach danych stosowana jest jakaś wersja B+-tree lub B*-tree.
Więcej na ten temat można przeczytać w artykule: Thomassa
Niemanna “A compact guide to searching and sorting” (http:
//epaperpress.com/sortsearch/index.html). Jest to związane
z tym, że tradycyjne bazy danych chcą upakować wszystko do
jednej strony i mieć jak najmniej odczytów i zapisów stron.
Osobiście nie mam wielkiego przekonania, że takie podej-
ście ma jeszcze jakieś dobre uzasadnienie (zresztą nie tylko
ja). Nowoczesny sprzęt i systemy operacyjne bardzo zmieniły
sytuację w ostatnich kilku latach. Dyski (bardziej poprawnie: ich
sterowniki) mają kilka poziomów pamięci, własne algorytmy ko-
lejkowania zapisów itp. Nie ma wielkiego sensu umieszczanie
dzisiaj takiego kodu w bazie danych. Moim zdaniem lepiej sko-
rzystać z jak najprostszych rozwiązań, które będą dobrze wy-
korzystywać nowoczesny sprzęt – np. cache procesora. Dlate-
go LhimkDB stosuje algorytm Skip List, wymyślony w 1989 r.
przez Billa Pugha (http://www.cs.umd.edu/~pugh/). Jest to tak
prosty algorytm, że mogę go wyjaśnić tutaj w dwóch akapitach.
Weźmy najprostszą listę jednokierunkową w postaci [klucz,
dane, wskaźnik następnego rekordu]. W takiej liście znalezienie
rekordu o podanym kluczu polega na przeglądaniu kolejnych re-
kordów, aż odnajdziemy żądany klucz. Możemy te rekordy trzy-
������������������������������������������������������������������
�����������������
� �
� � �
� � � �

v[[10]] = 20 ;

�� �� �� �� �� �� �� ��
wywoła

���������������������������������������������������������������
operator_bba(10,20)
�������������������������

Proste. I o to chodziło. Używam wszędzie [[]], a nie pojedyn- � � �

czych [], bo taka jest w Lhimku konwencja (jeżeli mogę użyć
tego słowa w stosunku do tak młodego tworu). Operator [[]] � � � �
jest odwołaniem do tablicy z jakimś dodatkowym “czymś”,
operator [], to szybkie odczytanie wartości z tablicy.
� � � � �
SkipList
Najpierw zajmiemy się zbudowaniem struktury danych, która �� �� �� �� � �� �� �� ��
da nam dostęp do zapisanych wartości wg klucza z możliwo-
ścią przeglądania zgodnie z kolejnością klucza. W tej chwili za- Rysunek 4. Przykład SkipListy z pokazaniem wkładania
pominamy, że budujemy bazę danych i robimy “zwykłą” klasę. nowego elementu

Software Developer’s Journal 1/2006 www.sdjournal.org 33

 Bazy
danych
mać w postaci posortowanej i wtedy, kiedy znajdziemy rekord,
o większym kluczu, wiemy, że nie ma co dalej szukać – naszego
klucza już nie znajdziemy (nazwijmy taką posortowaną listę L0 –
Rysunek 2.). Wyobraźmy sobie, że mamy 100 rekordów na takiej
liście. Bierzemy co drugi rekord i łączymy je dodatkowymi wskaź-
nikami tworząc kolejną listę (nazwijmy ją L1 – Rysunek 3.). Teraz
możemy najpierw odszukać największy klucz niewiększy od na-
szego na liście L1, a potem sprawdzić na L0, czy mamy trafie-
nie. W ten sposób szukamy 2 razy szybciej. Możemy też wziąć
co czwarty element i zrobić listę L2. Teraz będziemy szukać 4 ra-
zy szybciej. Możemy wziąć co ósmy, co szesnasty, co 32-ugi ele-
ment itd. W ten sposób utworzymy drzewo binarne, w którym
szybkość odnalezienia elementu jest zależna od logarytmu ilo-
ści obiektów. Dla statycznych, z góry określonych danych nie ma
problemu, żeby takie idealne drzewo utworzyć. Gorzej jest kiedy
dane do drzewa są dodawane i usuwane, a my nie wiemy w ja-
kiej kolejności i co nadejdzie dalej.
Genialny pomysł Skip List polega na tym, że przy każ-
dym wkładanym elemencie losujemy do jakich list go zapi-
sać. Z prawdopodobieństwem 1 do listy L0. Z prawdopodo-
bieństwem 1/2 do listy L1, 1/4 do L2 itd. W ten sposób za-
wsze na L0 będą wszystkie elementy, na L1 mniej więcej
połowa, na L2 jedna czwarta itd. Statystycznie będzie to
dokładnie to samo jakbyśmy ręcznie robili listy ze statycz-
nego zbioru danych. Co więcej, algorytmy są banalne, za-
mieściłem je w całości w pierwszym artykule z tego cy-
klu, teraz zamieszczam prezentację graficzną na rysunku
4. Dla porównania, usuwanie elementu z B+-tree jest tema-
tem całych rozpraw (np. Jan Jannink „Implementing dele-
tion in B+-Trees”).
Najlepsze w LhimkDB jest to, że nie tworzymy żadnej spe-
cjalnej wersji tego algorytmu „dla baz danych”. Korzystamy
dokładnie z tego samego kodu, który obsługuje „zwykłe” Ski-
pListy, łącząc je bardzo prosto z kodem UDB. Zanim pokażę
jak to zrobić, musimy mieć jeszcze jeden mechanizm: trwały
wskaźnik (ang. persistent pointer).
Persistent Pointer (PPointer)
Zostawmy na chwilę Skip Listę i zastanówmy się jak zintegro-
wać z naszą bazą danych UDB, najprostszą listę, taką jak L0
z powyższego opisu (tyle, że nieposortowaną).
Klasa Lista może mieć takie pola:
Lista* next;
int val;
int key;
Wiadomo o co chodzi, będziemy szukać elementów z odpo-
wiednim key i zwracać ich val. Używać chcemy tej struktury
w najprostszy sposób:
Lista *l = Lista::new(key, val);
Lista *l2 = Lista::new(key2, val2);
l->next = l2;
W momencie, kiedy robimy l->next=l2, chcielibyśmy, żeby l2
zostało “zapisane do bazy danych”. W tym celu zrobimy drob-
ną modyfikację. Wskaźnik next zastąpimy taką strukturą:
PPointer[Lista T] *next;
34 www.sdjournal.org
Lhimk
Lhimk jest środowiskiem dynamicznej kompilacji dla języka o tej
samej nazwie (Lhimk), który jest oparty na C. Lhimk jest językiem
obiektowym, o bardzo prostej składni, w zasadzie, każdy kto zna
C/C++ może od razu zacząć programować w Lhimku. Do składni
C są dodane klasy z wielodziedziczeniem (ang. multiinheritance)
i możliwością przeciążania operatorów, szablony, sygnały, wyjąt-
ki i kilka innych drobiazgów. Lhimk jest środowiskiem dynamicznej
kompilacji, więc cały kod jest kompilowany w momencie urucha-
miania programu. Kompilator jest bardzo szybki, więc trwa to kró-
cej niż ładowanie wielu bibliotek w skompilowanych programach.
Lhimk jest dostępny częściowo na licencji LGPL i częścio-
wo na licencji BSD. Wynika to z tego, że korzysta z kodu TinyCC,
który jest na licencji LGPL, natomiast moją intencją jest dawać
wszystko na licencji BSD. Podstawową jednostką kodu w Lhim-
ku jest moduł. Każdy moduł ma unikalny adres, np.: \lhimk.org\
Db\UDB
W Lhimku nie ma podziału na pliki nagłówkowe i implementa-
cję. Jak chcemy się odwołać do jakiegoś typu lub obiektu z innego
modułu, po prostu podajemy całą ścieżkę. To jest np. odwołanie
do klasy UDB (odwołania do typów poprzedzone są znakiem '@'):
@\lhimk.org\Db\UDB\UDB
Na końcu jest dwa razy UDB, ponieważ klasa UDB jest w mo-
dule UDB. Obiekty globalne (czyli wbudowane funkcje) są po pro-
stu poprzedzane przez '\', np.: \printf(“Hello!\n”);
Klasa może mieć metody wirtualne, albo statyczne. W Lhimku
raczej nie używa się referencji do obiektów, a wyłącznie wskaź-
niki (Lhimk ma wbudowany garbage collector). Nowy obiekt naj-
częściej tworzony jest tak: @\lhimk.org\Db\UDB\UDB *udb = \
lhimk.org\Db\UDB\UDB::new();
Gdzie metoda new jest zwykłą metodą statyczną zwracającą
UDB*. Szablony są realizowane na poziomie modułu, który jest jed-
nostką kompilacji. Jeżeli chcemy mieć np. listę integerów, napisze-
my to tak: @\lhimk.org\LTL\List\List[int T] *udb = @\lhimk.org\
LTL\List\List[int T]::new();
W ten sposób moduł \lhimk.org\LTL\List\ zostanie przekom-
pilowany z typem T zdefiniowanym jako int. Jest to podejście dużo
prostsze niż w C++, a czasami daje dużo lepsze możliwości (można
np. w zależności od typu T dodawać do klas poszczególne metody).
Sygnały są odpowiednikami tablicy wskaźników do funkcji. Sygnał
deklarujemy tak: signal changed(A*); Potem możemy dodać meto-
dę, która będzie wywoływana: this->changed << a->handle; //bez ()!
Jeżeli gdzieś w kodzie jest: this->changed->call(a); to zostanie wy-
wołanie: a->handle(); To chyba cały podręcznik Lhimka...
Oznacza to, że next będzie trwałym wskaźnikiem, a nie zwy-
kłym wskaźnikiem. Używamy go jak tablicy, żeby móc prze-
ciążyć operator przypisania (patrz wyżej): l->next[[0]] = l2;
To w rezultacie wywoła: PPointer::operator_bba(0, l2);
Nałóżmy na obiekt klasy Lista jeszcze obowiązek pamię-
tania swojego PID (metody getPid i setPid).
Wewnątrz operator _ bba klasy PPointer, postępujemy tak
(pełny kod znajduje się na Listingu 1.):
l Zapamiętaj wskaźnik do obiektu, jeżeli obiekt nie był jesz-
cze zapisany do bazy danych (ma getPid()==0), to zapisz
go do bazy danych.
Podobnie działa operator_bb (odczyt):
l Jeżeli masz wskaźnik do obiektu, to go zwróć (znaczy, że już
go czytaliśmy), jeżeli nie, to weź pid i odczytaj obiekt z bazy.
Software Developer’s Journal 1/2006
 Zbudujmy sobie bazę danych – LhimkDB

Listing 1. Implementacja klas PPointer i PPointerSystem

class PPointerSystem { @\lstream\Stream *s = \lstream\Stream::new();
@\ludb\UDB *udb; a->serialize(s);
@\lmap\Map[unsigned long long K][A* T] *cache; this->udb->atPut(a->getPid(), s->data);
@\lmap\Map[unsigned long long K][A* T] *changed; it->next();};
void *user_data; this->changed->clear();};
constructor new(char* path, int DELETE=0) { A* getRoot() {
PPointerSystem* this = \lhc\new(PPointerSystem*); A* root = this->at(1);
this->udb = \ludb\UDB::new(path, DELETE); if (!root) {
this->cache = \lmap\Map[unsigned long long K] root = A::newRoot(this);
[A* T]::new(); if (!this->udb->isInTransaction()) {
this->changed = \lmap\Map[unsigned long long K] this->beginTransaction();
[A* T]::new(); this->put(root);
return this; }; this->commitTransaction();}
PPointerSystem* clone() { if (root->getPid()!=1) {
PPointerSystem* clone = \lhc\new(PPointerSystem*); ERROR("Root must be saved first, at pid==1",
clone->udb = this->udb->clone(); ERROR_MINOR);}}
clone->cache = \lmap\Map[unsigned long long K] return root;};};
[A* T]::new(); class PPointer {
clone->changed = \lmap\Map[unsigned long long K] PPointerSystem* ps;
[A* T]::new(); A* objects[[]];
return this; }; A* parent;
void beginTransaction() { unsigned long long pids[[]];
this->udb->beginTransaction(); signal changed(A*);
}; constructor new(PPointerSystem* ps, A* parent) {
void commitTransaction() { PPointer* this = \lhc\new(PPointer*);
this->commit(); this->ps = ps;
this->udb->commitTransaction(); }; this->objects = \lhc\array_new(A*[[]],1);
void free() { this->pids = \lhc\array_new(unsigned long long[[]],1);
this->udb->free(); }; this->changed = \lhc\signal_new(signal changed(A*));
A* at(unsigned long long pid) { this->parent = parent;
A* a = this->cache[[pid]]; return this;};
if (!a) { A* operator_bb(unsigned int ind) {
char data[[]] = this->udb->at(pid); A* r= this->objects[[ind]];
if (data) { if (!r && this->pids[[ind]]!=0) {
@\lstream\Stream *s = \lstream\Stream:: r=this->ps->at(this->pids[[ind]]);}
new(data); return r;};
a = A::deserialize(this, s); A* operator_bba(unsigned int ind, A* obj) {
this->cache[[pid]] = a;} } this->objects[[ind]] = obj;
return a; }; if (obj) {
unsigned long long put(A* a) { if (obj->getPid()==0) {
@\lstream\Stream *s = \lstream\Stream::new(); this->ps->put(obj);}
a->serialize(s); this->pids[[ind]] = obj->getPid();
unsigned long long pid = this->udb->put(s->data); } else {
a->setPid(pid); this->pids[[ind]] = 0;}
this->cache[[a->getPid()]] = a; this->changed->call(this->parent);
return pid; }; return obj;};
void atPut(unsigned long long pid, A* a) { void resize(unsigned int size) {
@\lstream\Stream *s = \lstream\Stream::new(); \array_resize(this->objects,size);
a->serialize(s); \array_resize(this->pids,size);
this->udb->atPut(pid, s->data); this->changed->call(this->parent);};
a->setPid(pid); void serialize(@\lstream\Stream *s) {
this->cache[[pid]] = a; //we save only pids
return pid; }; int size = this->pids->size;
void remove(A* a) { s->putInt(size);
this->udb->removeAt(a->getPid()); int i = 0;
this->cache->remove(a->getPid()); for (i=0; i<size; i++) {
this->changed->remove(a->getPid()); }; s->putLongLong(this->pids[i]);}};
void markChanged(A* a) { void deserialize(@\lstream\Stream *s) {
if (a->getPid()>0) { //we save only pids
this->changed[[a->getPid()]] = a; }}; int size = s->getInt();
void commit() { this->resize(size);
@\lmap\Iterator[unsigned long long K][A* T] int i = 0;
*it = this->changed->getIterator(); for (i=0; i<size; i++) {
while (!it->end()) { this->pids[i] = s->getLongLong();};};};
A *a = it->get();

Software Developer’s Journal 1/2006 www.sdjournal.org 35

 Bazy
danych
Dane do zapisu pobieramy od obiektu metodą serialize,
a nowy obiekt z odczytanych danych robimy przy pomocy
metody deserialize. W zasadzie każda klasa, która spełnia te
warunki może być używana z PPointer i będzie “automatycz-
nie” zmieniana w bazę danych.
Do pełni szczęścia musimy mieć jeszcze jakiś obiekt Root, od
którego zaczynamy zapisywanie i czytanie. Taki obiekt pamięta-
my pod ustalonym z góry PID, w naszym wypadku jest to 1.
Jedyny haczyk, który jeszcze został, jest taki, że nie mo-
żemy bezpośrednio do zapisu i odczytu użyć UDB. Musimy
mieć pewną strukturę pośrednią, która będzie zapamiętywać
wszystkie już odczytane obiekty (taki podręczny cache). In-
aczej, mogłoby się zdarzyć, że odczytamy obiekt dwa razy
i będziemy mieli dwa egzemplarze tego samego obiektu
(z tym samym PID). Dodatkowo, nie będziemy zapisywać obiek-
tu za każdym razem, kiedy jest zmieniana jego wartość. Będzie-
my zapamiętywać zmienione obiekty i zapisywać dopiero pod-
czas robienia commitTransaction(). Klasa, która to realizuje nazy-
wa się PPointerSystem i pokazana jest na Listingu 1.
PPointer + SkipList == baza danych
Zobaczmy teraz jak połączyć PPointer i SkipListę. SkipLi-
sta, podobnie jak każda inna lista, zbudowana jest elementów
(SkipListElement), które połączone są między sobą wskaźni-
kami. Każdy element SkipListy ma tablicę wskaźników for-
ward do elementów przed nim, i jeden wskaźnik prev, służą-
cy do przeglądania listy wstecz. Żeby wyszła nam sztuczka
z PPointer, wskaźnik prev też trzymamy w tablicy, tyle, że jedno-
elementowej. W “zwykłym” SkipListElement mamy takie pola:
SkipListElement *prev[[]];
SkipListElement *forward[[]];
Jeśli zrobimy nowy SkipListElement z takimi polami:
@\lpp\PPointer[SkipListElement A] *prev;
@\lpp\PPointer[SkipListElement A] *forward;
Listing 2. Przykłady użycia klasy SkipList i Db\SkipList
//Zwykład SkipLista:
@\lskiplist\SkipList[int T][int K]* list
= \lskiplist\SkipList[int T][int K]::new();
list[[1]] = 1;
list[[1]] += 1;
int v = list[[1]];
list->remove(1);
list->free(); //nie musimy tego robić
//SkipLista – baza danych:
@\lskiplistdb\SkipList[int T][int K]* list
= \lskiplistdb\SkipList[int T][int K]::new(“BAZA_
DANYCH”);
list->startTransaction();
list[[1]] = 1;
list[[1]] += 1;
int v = list[[1]];
list->remove(1);
list->commitTransaction();
list->free(); //zamyka bazę danych
36 www.sdjournal.org
W sieci
l Strona domowa projektu Lhimk i LhimkDB
http://www.lhimk.org
l Strona domowa Billa Pugha
http://www.cs.umd.edu/~pugh/
to właśnie zrobiliśmy prawie wszystko, co trzeba, żeby przero-
bić “zwykłą” SkipListę, na bazę danych. Wystarczy jeszcze do
tej klasy dodać metody setPid i getPid oraz serialize i dese-
rialize, żeby spełnić warunki opisane wyżej.
Teraz możemy utworzyć nową klasę SkipList (nazwa
może być ta sama, bo jest trzymana w innym miejscu). Bę-
dzie ona dziedziczyć z naszej „normalnej” klasy SkipList,
ale podamy nasz nowy SkipListElement jako parametr kom-
pilacji szablonu:
class SkipList : \...\SkipList[SkipListElement
SkipListElement][T T][K K]
Proste prawda? Wiem, że nie jest to proste, ale działa! Co naj-
ważniejsze, nie mamy dwóch implementacji klas SkipList – jed-
nej do „zwykłych” zastosowań, drugiej do baz danych. Dodatko-
wo korzystanie z obu klas jest identyczne. Jedyny wyjątek jest
taki, że wersji bazodanowej, przed zapisem trzeba rozpocząć
transakcję i po skończeniu modyfikacji transakcję zakończyć.
Idąc dalej, nasza „baza danych” dziedziczy pośrednio
z bazowych klas typu Container. Możemy zatem korzystać
ze wszelkich algorytmów uogólnionych, np. z wypisywania,
przeszukiwania itp. Możemy dowolnie w kodzie mieszać
dostęp do danych zapisanych na dysku ze zwykłymi struk-
turami w pamięci. Właśnie z tej cechy będziemy korzystać
za miesiąc, kiedy zbudujemy wysokopoziomowe transak-
cje, czyli takie jakie powinny być wykorzystywane w „zwy-
kłych programach”.
Podsumowanie
Jak widać baza danych klucz-wartość, to zwykła struktura ta-
blicy asocjacyjnej (w naszym wypadku użyliśmy SkipListy)
z elementami obsługi persystencji i transakcji. Mając w miarę
nowoczesne środowisko programowania, można oba te pro-
blemy rozdzielić i na końcu łatwo połączyć np. przy pomocy
szablonów. Nie ma tu żadnej zasługi Lhimka, można to samo
osiągnąć np. w C++. W rezultacie baza danych jest jeszcze
jednym typem generycznym (których mamy dużo np. w STL-
u) i można do baz danych stosować wszystkie techniki znane
z programowania uogólnionego (generycznego).
Zamiana SkipListy w bazę danych jest bardzo prosta (kil-
kadziesiąt minut), nie ma praktycznie żadnego powodu, że-
by nie dało się w ten sposób zamienić dowolnej innej struktu-
ry. Pozwala to na łatwe eksperymentowanie i daje wielką ela-
styczność w wykorzystaniu zaprezentowanego rozwiązania.
Za miesiąc dodamy jeszcze jedną warstwę, która pozwo-
li uruchamiać dowolną ilość transakcji odczytu i zapisu jed-
nocześnie. Będzie ona też odpowiedzialna za rozwiązywa-
nie konfliktów. Zobaczymy też jak można naszą bazę klucz-
wartość zamienić w bazę drzewiastą (po dzisiejszym artykule,
myślę, że wszyscy wiecie jak to zrobić). n
Software Developer’s Journal 1/2006
 Bazy
danych
Zbudujmy sobie bazę danych – LhimkDB cz 4
Paweł Marciniak
Dodajemy strukturę drzewa
T
rzy miesiące temu rozpocząłem cykl artyku-
łów opisujący jak zbudować od podstaw ba-
zę danych. Zbudowaliśmy bazę danych –
LhimkDB – do wbudowywania do programów (ang.
embedded database), o architekturze klucz-wartość
(ang. key-value). Teraz dodamy do niej możliwość
zapisu danych w strukturze drzewa (ang. tree struc-
tured database). Wszystkie przedstawione do tej po-
ry warstwy LhimkDB mogą być używane niezależ-
nie. Tak będzie i tym razem, dodanie struktury drze-
wa nie oznacza, że nie można z LhimkDB korzystać
jak z bazy klucz-wartość.
LhimkDB jest pisany w języku Lhimk. Język ten
jest na tyle podobny do C/C++, że nie ma sensu się
go uczyć, czy wyjaśniać jak w nim pisać programy.
Te elementy, które występują w Lhimku, a nie ma ich
w C/C++ są omówione w ramce “Lhimk” lub w samym
tekście artykułu. Jeżeli ktoś nie chce używać Lhimka
(co całkowicie rozumiem), to może z łatwością pokaza-
ny kod przepisać w C++. Można też z Lhimka korzystać
z wewnątrz programów napisanych w C/C++.
Datum
Zanim przejdziemy do struktury drzewiastej, zajmie-
my się rzeczą prostą, przyziemną, ale niezbędną –
możliwością zapisu dowolnych typów danych do bazy.
W bazach danych najmniejszy element, jaki może-
my zapisać, przyjęło się nazywać datum. Jest to typ
danych podobny do typu Variant znanego z języków
wyższego poziomu, lub różnych obiektowych biblio-
tek. Nie ma w nim nic magicznego, po prostu przecho-
wuje on dane wraz z identyfikatorem typu. Dodatkowo
Datum musi umieć wykonać serializację tych danych,
czyli zamianę na strumień bajtów, który zostanie za-
pisany do bazy. W przypadku typów prostych, łańcu-
chów znaków itp. jest to oczywiście banalne. Sytuacja
nieco się komplikuje w przypadku obiektów klas. Na
szczęście Lhimk jest środowiskiem dynamicznej kom-
pilacji, możemy zatem zapisać nazwę klasy i później
z tej nazwy odtworzyć obiekt (wywołując specjalny
konstruktor deserialize). W Lhimku nazwa klasy jest
również URL-em do miejsca w internecie, skąd moż-
na ściągnąć kod tej klasy. Dlatego, nawet jeśli czyta-
my czyjąś bazę danych i nie mamy tych klas, to sys-
tem może je automatycznie załadować i skompilować
(oczywiście w trakcie działania programu). Konstruk-
Paweł od 20 lat zajmuje się tworzeniem oprogramowa-
nia, głównie w C/C++. Od trzech lat rozwija system dy-
namicznej kompilacji Lhimk.
Kontakt z autorem: pawel@lhimk.org
40 www.sdjournal.org
tor desrialize można napisać “ręcznie”, można też
wykorzystywać informacje o klasach z RTTI, do auto-
matycznego generowania takiego kodu.
Klasa Datum spełnia w Lhimku jeszcze jedną
funkcję. Otóż, umożliwia ona programowanie gene-
ryczne (uogólnione). Zobaczmy konkretny przypa-
dek. W miejscu, gdzie chcemy zapisać dane do bazy
danych, musimy zrobić coś takiego:
key->serialize(stream);
value->serialize(stream);
Przy czym, nie znamy typów key i value. Gdybyśmy
założyli, że są to zawsze obiekty, to sprawa by była
rozwiązana, wystarczy zażądać implementacji tych
dwóch metod. Ale tak nie jest, bo mogą to być rów-
nież typy proste. W C++ rozwiązuje się to poprzez
specjalizację metod. W C++ napisalibyśmy to tak:
stream->serialize(key);
stream->serialize(value);
W kodzie klasy Stream, musielibyśmy zdefiniować
wiele specjalizacji metody serialize, ze względu na
typ argumentu:
void serialize(int val);
void serialize(float val);
...
Wtedy kompilator dobierze dla nas „odpowiednią” me-
todę, która dobrze obsłuży nasz typ. Taka jest teoria.
W praktyce zasady automatycznej konwersji pomię-
dzy typami w C++ są dość złożone. Do tego docho-
dzą klasy, które mogą mieć niejawne operatory kon-
wertujące (ang. implicit convertion operators). Łatwo
napisać, nawet bardzo niewielki program w C++, któ-
ry będzie nie do zrozumienia. W większych projektach
stosowanie takich technik jest po prostu zabronione.
Oczywiście, w związku z tymi trudnościami, nie
chciałem w Lhimku implementować specjalizacji me-
tod (inaczej nazywanej polimorfizmem parametrycz-
nym, lub jeszcze inaczej: multimetody). Miałem jesz-
cze jeden powód: szybkość kompilacji, która jest
szczególnie ważna w systemach, gdzie użytkowni-
kom daje się kod źródłowy, a kompilacja następuje
przy starcie programu. Dlatego w Lhimku jest inne
rozwiązania. Do budowania generycznego kodu słu-
ży operator '#'. Np. operator '#s' zamienia wszystko
w string. Możemy napisać:
napis = “Ilość : “ + 100#s + “ wartość: “ + 11.22#s;
Software Developer’s Journal 2/2006
 LhimkDB cz 4 - Dodajemy strukturę drzewa

��� ����� �������

Lhimk ��� ���� ���

Lhimk jest środowiskiem dynamicznej kompilacji dla języka o tej sa- ��� �������� ��������
mej nazwie (Lhimk), który jest oparty na C. Lhimk jest językiem obiek-
��� ����� �����������������������
towym, o bardzo prostej składni, w zasadzie, każdy kto zna C/C++
może od razu zacząć programować w Lhimku. Do składni C są doda- ��� ������� �������
ne klasy z wielodziedziczeniem (ang. multiinheritance) i możliwością
przeciążania operatorów, szablony, sygnały, wyjątki i kilka innych dro- ��� �����������
biazgów. Lhimk jest środowiskiem dynamicznej kompilacji, więc cały
��� ����� ������
kod jest kompilowany w momencie uruchamiania programu. Kompi-
lator jest bardzo szybki, więc trwa to krócej niż ładowanie wielu biblio- ��� ������ ��������
tek w skompilowanych programach. Lhimk jest dostępny częściowo
na licencji LGPL i częściowo na licencji BSD. Wynika to z tego, że ��� ���������� ��������
korzysta z kodu TinyCC, który jest na licencji LGPL, natomiast mo-
��� ��� ������
ją intencją jest dawać wszystko na licencji BSD. Podstawową jed-
nostką kodu w Lhimku jest moduł. Każdy moduł ma unikalny adres,
Rysunek 1. Budowa drzewa przy pomocy typu Datum i list
np.: \lhimk.org\Db\UDB W Lhimku nie ma podziału na pliki nagłów-
kowe i implementację. Jak chcemy się odwołać do jakiegoś typu Wystarczy, że metoda serialize będzie zaimplementowana
lub obiektu z innego modułu, po prostu podajemy całą ścieżkę. To w klasie Datum. Możemy teraz używać bazy danych do prze-
jest np. odwołanie do klasy UDB (odwołania do typów poprzedzo- chowywania dowolnych wartości:
ne są znakiem '@'): @\lhimk.org\Db\UDB\UDB Na końcu jest dwa ra-
zy UDB, ponieważ klasa UDB jest w module UDB. Obiekty globalne
@\lds\SkipList[Datum* T][Datum* K]* list =
(czyli wbudowane funkcje) są po prostu poprzedzane przez '\', np.:
\lds\SkipList[Datum* T][Datum* K]::new("SKIPDB", 1);
\printf(“Hello!\n”); Klasa może mieć metody wirtualne, albo sta-
tyczne. W Lhimku raczej nie używa się referencji do obiektów, a wy- list->beginTransaction();

łącznie wskaźniki (Lhimk ma wbudowany garbage collector). Nowy list[[10#d]] = "abcd"#d;

obiekt najczęściej tworzony jest tak: @\lhimk.org\Db\UDB\UDB *udb =
\lhimk.org\Db\UDB\UDB::new(); Gdzie metoda new jest zwykłą me-
todą statyczną zwracającą UDB*. Szablony są realizowane na pozio-
mie modułu, który jest jednostką kompilacji. Jeżeli chcemy mieć np.
listę integerów, napiszemy to tak: @\lhimk.org\LTL\List\List[int
T] *udb = @\lhimk.org\LTL\List\List[int T]::new(); W ten spo-
sób moduł \lhimk.org\LTL\List\ zostanie przekompilowany z ty-
pem T zdefiniowanym jako int. Jest to podejście dużo prostsze niż
w C++, a czasami daje dużo lepsze możliwości (można np. w zależ-
ności od typu T dodawać do klas poszczególne metody). Sygnały
są odpowiednikami tablicy wskaźników do funkcji. Sygnał deklaru-
jemy tak: signal changed(A*); Potem możemy dodać metodę, która
będzie wywoływana: this->changed << a->handle; //bez ()! Je-
żeli gdzieś w kodzie jest: this->changed->call(a); to zostanie wy-
wołanie: a->handle(); W Lhimku programowanie generyczne jest
możliwe dzięki operatorom #s, #d, #i itp. Np.: napis = “Ilość : “ +
count#s + “ wartość: “ + value#s; Konwertuje count i value na
string, niezależnie od ich typów. Operator #d konwertuje na Da-
tum, #i na integer itd.
To chyba cały podręcznik Lhimka...
Możemy też napisać:
napis = “Ilość : “ + count#s + “ wartość: “ + value#s;
nie martwiąc się o typy zmiennych count i value. W przypadku
typów prostych (wbudowanych) kompilator wykona odpowied-
nią konwersję. W przypadku obiektów klas, będzie wywołana
metoda operator _ hash _ s.
Dokładanie tak samo możemy przekonwertować dowolną
daną dowolnego typu na Datum (tyle, że operatorem '#d'). Za-
tem nasz kod serializacji wygląda tak:
key#d->serialize(stream);
value#d->serialize(stream);
list->commitTransaction();
Struktura drzewiasta cz. 1
Skoro możemy przechowywać wartości dowolnych typów, to
co się stanie jak zapiszemy jako element inną listę? Utworzy-
my drzewo! W zasadzie implementację drzewa dostajemy
prawie za darmo, dzięki programowaniu generycznemu i ty-
powi Datum. Jest to rzecz, nad którą myślałem dwa tygodnie,
a potem napisałem w godzinę – naprawdę! To naturalne roz-
wiązanie było tak proste, że bardzo długo nie mogłem go “na
poważnie” zaakceptować (patrz Rysunek 1).
Zanim naprawdę to zrobimy wprowadzimy jeszcze jedną
ważną konstrukcję: transakcje użytkownika.
Transakcje użytkownika
Do tej pory nasz system był budowany wg zasady: mamy tyl-
ko jeden wątek zapisujący i dowolną ilość wątków czytają-
cych. W prawdziwych zastosowaniach jest to oczywiście nie
do przyjęcia. Trzeba by było wtedy wszystkie zapisy grupo-
wać i robić w jednej zwartej paczce na koniec wykonywania
operacji (np. obsługi zapytania HTTP).
Problemy te rozwiązuje klasa Transaction. Jest to banalne
rozwiązanie polegające na tym, że mamy dwie listy – cache i tar-
get. Wszelkie zmiany w danych (zapis i usunięcie) są zapisywa-
ne najpierw w liście cache, która jest oczywiście listą w RAM-ie.
Dopiero, kiedy potwierdzamy transakcję metodą commit, wszelkie
zmiany z cache'a są zapisywane do targetu. Tylko na ten, bardzo
krótki czas, transakcja ma wyłączność na zapis. Wszelkie kon-
flikty pomiędzy transakcjami są rozwiązywane przez klasę Db,
która ma listę wszystkich transakcji. W skrócie, jest sprawdzane,
czy jakaś transakcja która zaczęła później niż nasza, a skończy-
ła wcześniej, nie zmieniła tych samych danych co my.
Jest tutaj przemycona jedna bardzo ważna i bardzo trudna
do zrozumienia koncepcja. Otóż sprawdzamy konflikty na po-
ziomie zapisu: klucz-wartość. Interesuje nas, czy ktoś nie zmie-

Software Developer’s Journal 2/2006 www.sdjournal.org 41

 Bazy
danych

Listing 1. Sposób korzystania z transakcji W sieci

@\ldb\Db[int T][int K]* db =
• Strona domowa projektu Lhimk i LhimkDB
\ldb\Db[int T][int K]::new("DB", 1);
http://www.lhimk.org
@\ltrans\Transaction[int T][int K]* tr =
• Strona domowa Billa Pugha
db->startTransaction(); http://www.cs.umd.edu/~pugh/
for(i=0; i<maxnum;i++)
{
tr[[i]]=i; tuicyjne jest to, że, skoro są listą, to do nich zapisujemy dane
} (Listing 1).
tr->commit();
db->free(); Struktura drzewiasta cz. 2
Wróćmy teraz do naszego drzewa. Po pierwsze, teraz wsta-
wiamy elementy do transakcji, a nie do listy (jakkolwiek dzi-
nił wartości zapisanej pod tym samym kluczem. Z poprzednie- wacznie by to nie brzmiało), po drugie, drzewo utworzymy
go artykułu pamiętamy, że np. zapis jednego elementu klucz- wstawiając nową transakcję, a nie listę. Tym samym wszystkie
wartość modyfikuje również kilka innych elementów. Te modyfi- wątpliwości się rozwiały: transakcja jeszcze nie „wstawiona”
kacje dotyczą jednak wyłącznie wskaźników, i dopóki baza jest do bazy po prostu zapisuje swoje dane do cache'u. W trak-
spójna, nie wpływają na logikę aplikacji. Dlatego, sprawdzając cie zapisu transakcji, zapiszą się też wszystkie elementy, któ-
konflikty na tym poziomie, mamy ich po prostu dużo mniej i du- re są transakcjami (gałęziami drzewa), bo zapis ten będzie re-
żo więcej transakcji zakończy się sukcesem (jest dużo mniej alizowany w trakcie serializacji. Możemy mieć w jednej bazie
sytuacji, gdzie dwie transakcje zmieniły ten sam obiekt i system UDB (patrz art. sprzed dwóch miesięcy) dowolną ilość list, po-
musi jedną transakcję unieważnić). (Temat do rozważań: dla- nieważ lista musi wiedzieć wyłącznie, gdzie jest jej początek.
czego obiektowe bazy danych się nie przyjęły?) Listy takie nie kolidują ze sobą, po prostu wskazują na swoje
Nasze transakcje, są po prostu jeszcze jedną implementa- elementy. Dziwne, ale to naprawdę działa!
cją listy, tym razem z cache'em i możliwością zapisu. Mało in- Pójdziemy jeszcze krok dalej. Nie będziemy do bazy za-
pisywać obiektów klasy Transaction, będziemy zapisywać
Listing 2. Przykładowy kod klasy Invoice (faktura) obiekty dowolnej klasy, o ile potrafi się zachować jak transak-
cja (w rzeczywistości np. zawiera transakcję). W ten sposób
class Invoice : AccountingDocument { możemy dowolnie kształtować funkcjonalność takich obiek-
... tów. Możemy dodawać własne metody, ale też możemy wyko-
Datum* operator_bba(Datum* key, Datum* val) { nywać dodatkowe działania np. przy wprowadzaniu danych.
char* fname = key->getString(); Możemy np. dodać kontrolę, czy wprowadzane „pola” są
if (fname == "Date") { odpowiednie (czyli tworzyć tzw. semistrukturę, ang. semistruc-
@\ldate\Date* date = val->getClass( tured database). Możemy obsługiwać indeksy, czyli zapisywać
@\ldate\Date*); „wskaźnik” do obiektu w wyznaczonym miejscu, tak, żeby go
this->setDate(date); można było szybko odnaleźć. Możemy też wykonywać dodat-
} else kowe obliczenia. Ilustrację tego można zobaczyć na Listingu
if (fname == "Value") { 2, gdzie pokazany jest kod klasy Invoice (faktura). Oczywiście
float value = val->getFloat(); jest to kod czysto poglądowy, a nie produkcyjny. Najważniejsze
this->setValue(value); w tym przykładzie jest to, że dziedziczymy z klasy Accounting-
} Document, która jest wspólną podstawą dla wszelkich doku-
... mentów księgowych (np. może wykonywać dekretację).
else { W ten sposób powstała bardzo nowoczesna obiektowo-
ERROR(“wrong field”, ERROR_MINOR); drzewiasta (chyba zastrzegę ten nazwę :) baza danych. Ca-
} ła jej konstrukcja i sposób działania jest oparta na tym, że nie
return val; ma kodu “lepszego” i “gorszego”, napisanego w procedurze
}; składowanej SQL albo w kodzie aplikacji. Dzięki temu, moż-
void setDate(@\ldate\Date* date) { na naprawdę w sposób przejrzysty i obiektowy budować duże
this->addToIndex("Date", date); aplikacje biznesowe i portale WWW.
AccountingDocument::operator_bba(this,
"Date"#d, date); Podsumowanie
}; To już koniec naszej serii o LhimkDB. W ciągu czterech odcin-
void setValue(float value) { ków od obsługi trwałej pamięci doszliśmy do struktur obiekto-
AccountingDocument::operator_bba(this, wo-drzewiastych. Stworzyliśmy nie tylko jeszcze jedną bazę
"Value"#d, value); klucz-wartość, ale też zupełnie nową architekturę, pozwalają-
this[["Brutto"]] = value * this[[“VAT]]->getFloat(); cą na lepsze pisanie dużych systemów biznesowych. Przede
}; wszystkim chciałem pokazać, że napisanie takiej bazy danych
}; jest proste, że może to zrobić każdy kto ma kilka wolnych
chwil i niezbyt dużą wiedzę o programowaniu – jak ja. n

42 www.sdjournal.org Software Developer’s Journal 2/2006