ålenkå, czyli procesory graficzne czynią CUDA też dla baz danych

Akceleracja za pomocą GPU znalazła zastosowanie nie tylko w przeglądarkach. Ostatnio furorę na serwisach dla programistów czyni projekt ålenkå – czyli engine bazodanowy, wykorzystujący procesor karty graficznej. I nie jest to jakiś dziwny, noSQL-owy system – każdy, kto radzi sobie z tradycyjnymi RDBMS-ami, będzie mógł korzystać też z ålenki.

Do wyścigów ze wspomaganym procesorem graficznym engine bazodanowym, tradycyjni liderzy nie mają nawet co stawać. Rozwijany od pół roku projekt, będący wciąż w fazie testów, został ostatnio sprawdzony w benchmarku TPC-H, dla zbioru danych o rozmiarze 300 GB. Wykorzystano następującą konfigurację sprzętową:

CPU: dwurdzeniowy Intel E5200, RAM: 4 GB RAM, HD: 2 TB, GPU: Nvidia GTX 260 (karta graficzna warta około 700 zł)

Wynik ålenki: 178 sekund. Dużo to czy mało?

W wynikach benchmarka TPC-H widać, że system bazodanowy Microsoftu – SQL Server 2005, uruchomiony na serwerze Hitachi BladeSymphony (8 CPU/8 rdzeni), 128 GB RAM, 290x 36 GB 15K RPM HD potrzebował na jego ukończenie 485 sekund, ponad 2,7 raza więcej. Jest to pozycja 10. w rankingu. Wspomagany przez GPU engine był też szybszy od SQL Servera 2005 działającego na maszynie HP ProLiant DL585 G2 (309 s, miejsce 7.)

Dlaczego porównanie z SQL Serverem? Benchmark TPC-H ma oceniać szybkość wspierania decyzji biznesowych, a w dziedzinie Business Intelligence baza Microsoftu jest jedną z najchętniej używanych.

Obecnie projekt nie dorównuje oczywiście w możliwościach rozbudowanym systemom bazodanowym, ale już radzi sobie z dużymi zbiorami danych, większymi niż dostępny RAM systemu i karty wideo, za pomocą techniki strumieniowania fragmentów, przetwarzania danych i przechodzenia do kolejnych. Obsługuje takie typy danych jak double, long i varchar, zawiera też algorytmy kompresji i dekompresji, by wyeliminować wąskie gardła I/O. Wszystko to w modelu programowania CUDA, który pozwala na zastosowanie pojedynczej operacji jednocześnie na całym zbiorze danych.

Co najistotniejsze, cały projekt jest wydany na wolnej licencji Apache 2.0 – dzięki czemu będzie mógł zainspirować twórców innych opensource'owych narzędzi. Nie jest to jednak jedyne „serwerowe” rozwiązanie korzystające z GPU, które pojawiło się w ostatnich czasach. Od zeszłego roku trwają prace nad projektem KGPU, którego celem jest udostępnienie linuksowemu jądru mocy procesora graficznego – np. w celu przyspieszenia działania szyfrowanych systemów plików.

Więcej o ålence znajdziecie na stronie sourceforge.net/projects/alenka/files/ – tam też dostępny jest kod źródłowy projektu.

źródło: sourceforge.net, hacker news

Podoba Ci się ten tekst? Powiedz o tym innym na Fb: lub na G+:

publikuj:

wydrukuj

5 skomentuj »

Komentarze

#1 asdf 2012-01-27 14:17:03 1
Jakby się takie relacyjne bazy danych na GPU upowszechniły, to może by się okazało, że warto robić stronę internetową np. w C++ (tak, jak dzisiaj jest to możliwe we frameworku C++ Wt). Tradycyjne tłumaczenie dla używania Pythona, Ruby i PHP do budowania stron internetowych jest takie, że operacje bazodanowe są o rząd wielkości wolniejsze niż przetwarzanie logiki aplikacji w ww. językach. Teraz, gdy baza danych jest pierońsko szybka, to może C albo C++ wejdzie do backendowego świata WWW. Wtedy jeden język byłby używany do M, do C, ale nie do V (mam na myśli MVC).
IP: 193.43.229.[...] Opera/9.80 (X11; Linux x86_64; U; pl) Presto/2.10.229 Version/11.61
#2 slawek22 2012-01-27 18:04:18 0
Bardzo fajnie ale dzisiaj I/O to wąskie gardło. ~100 wierszy/sekunda więcej nie wyciągnie najszybszy dysk. Dla dużych, pofragmentowanych tabel to zwykle oznacza 30-40kb/s. No chyba, że SSD ale bazy nie są zbytnio zoptymalizowane do pracy z tymi dyskami (trzeba byłoby je uprościć).

>ale już radzi sobie z dużymi zbiorami danych, większymi niż dostępny RAM

Nie radzi sobie bo nie ma takiej fizycznej możliwości. Jedynym wyjaśnieniem takiego stwierdzenia mogłoby być to że dane w zbiorze testowym dobrze się poddawały kompresji albo były pobierane z bazy względem PK przy zastosowaniu Clustered Index.

Jak dla mnie bez rewelacji. Zrobiliby z tego lepiej jakiś szybki system K/V działający w pamięci karty graficznej ściśle zintegrowany z PHP i paroma innymi językami. Byłby szybki cache.
IP: 83.10.78.[...] Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.77 Safari/535.7
#3 popcorner 2012-01-27 18:16:30 0
@asdf

No to już chyba zamiast jebać się z C++ zyskując 20% wydajności lepiej pośmigać w Javie, czy C# (jak ktoś lubi to w Scali, za jakiś czas w Ceylonie) xD
IP: 156.17.224.[...] Opera/9.80 (Windows NT 6.1; U; pl) Presto/2.10.229 Version/11.61
#4 jacek2v^® 2012-01-28 08:12:00 0
@asdf

To nie tak . Tu nie chodzi o "czystą" bazę SQL, tzw. BI co nie przekłada się prosto na wydajność samej bazy. Co do języków skryptowych typu Python to nie słyszałem takiego wytłumaczenia ich użycia. Języki te stosuje się z uwagi na szybkość i wyższą jakość kodu przy mniejszych nakładach.
IP: 188.146.97.[...] Mozilla/5.0 (Linux; U; Android 2.3.5; pl-pl; HTC Incredible S Build/GRJ90) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1
#5 asdf 2012-01-28 14:17:55 0
@pocorner - nie cierpię Javy, stąd wspomniałem o C++ :)

@jacek2v - Wszystko rozumiem z twojego posta, z wyjątkiem drugiego zdania. Możesz wyjaśnić co masz na myśli? Czysta baza SQL to z BI czy nie z BI? Jeśli masz na myśli, że baza z BI nie nadaje się do użycia na GPU, to ja muszę gorąco zaprotestować - nadaje się. Te obliczenia statystyczne na wielkich danych, to RETE, to się wszystko pięknie nadaje na równoległe obliczenia na GPU.
IP: 193.43.229.[...] Opera/9.80 (X11; Linux x86_64; U; pl) Presto/2.10.229 Version/11.61

Aby dodać komentarz, musisz podać swój nick, treść komentarza oraz poprawnie przepisać oba słowa z obrazka (słowa muszą być rozdzielone spacją).
W treści komentarza można używać języka formatowania BBcode.