Big Data Matters

W ostatni piątek odbyło się seminarium Large Data Infrastructures for US Government  and Industry. Oprócz ciekawostek na temat realiów rynku informatycznego w USA jeden ze słuchaczy zadał pytanie: "When we should talsk about BigData?". Odpowiedź prowadzącego prezentację Lee Turnera była zaskakująco szczera: "I don't know!". Podpowiedź organizatora seminarium Pawła Płaszczaka z GridWiseTech była następująca: "BigData to dane, którymi na aktualny stan technologii nie da się zarządzać za pomocą trywialnych narzędzi." Niestety ta definicja mnie nie usatysfakcjonowała. Dlaczego? Ponieważ według niej zawsze mieliśmy i będziemy mieć do czynienia w informatyce z BigData, a jakość jednak aktualnie ten termin się pojawił podobnie jak Cloud!

Na podstawie mojego doświadczenia twierdzę, że BigData wiąże się ze specyficznymi strukturami baz danych, z którymi mamy do czynienia od momentu istnienia "user-generated content". Specyfika tych struktur polega na tym, że baza danych daje się podzielić na dwie części. Jedna z nich ma składa się z kilku tabel (zwykle nie powiązanych kluczami obcymi z pozostałą częścią bazy), które swoim rozmiarem odstają od reszty bazy. Przykładowo:

• średnia liczba wierszy w tabelach 5 mln
• średnia liczba wierszy w 2 wybranych tabelach 100 mln
• średnia wielkość większości tabel kilkanaście MB
• średnia wielkość 2 wybranych tabel 75 GB

Dodatkowo te największe tabele cechuje wysoka dynamika wzrostu. Zarządzanie taką strukturą danych za pomocą tradycyjnych silników relacyjnych baz danych nie jest ekonomiczne. Rozwiązania o bogatej funkcjonalności zaprojektowane do zapewniania transakcyjności obliczeń zatrudniamy do stosunkowo dużej liczby prostych zapytań na ogromnych wolumenach danych. Dlatego powstały rozwiązania (Hadoop, MapReduce), które wykonują operacje na tej części bazy dużo efektywniej niż tradycyjna relacyjna baza danych. Dla mnie to właśnie jest BigData.