Jeżeli prowadzi się własny biznes, istnieje całkiem spora szansa na to, że ma się w tej firmie komputery. Oczywiście, nie ma przymusu. Żeby prowadzić warzywniak na rogu, można sobie poradzić bez komputerów (chyba). Podobnie z warsztatem kowalskim, czy szewcem. Ale "nowoczesne" biznesy raczej się bez komputerów nie obejdą.

Komputery przechowują dane, c'nie? Jak się biznes rozrasta, danych również przybywa. Najpierw mieliśy parę plików w PDF, potem wystarczały nam tabelki w Excelu, potem przerzuciliśmy się na Accessa, bo jest bardziej pojemny, potem pojawiła się "poważna" baza typu MySQL, MS SQL albo Postgres - jeżeli jednak nasz biznes idzie nadzwyczaj dobrze, może się w końcu okazać, że i tutaj trafimy na sufit w postaci ograniczeń wielkościowych, lub - co bardziej prawdopodobne - wydajnościowych, naszego "wiaderka" z danymi. Co wtedy?

Nie ma sie co oszukiwać. Danych zawsze przybywa. Megabajt dziś, gigabajt jutro, terabajt pojutrze. Okienka, zamiast otwierać się w sekundę, otwierają się teraz w minutę. Albo wcale. Okazuje się nagle, że potrzebujemy jakiegoś całkiem nowego rozwiązania, które będzie umiało sobie poradzić ze stałym przyrostem danych, bez utraty szybkości działania, spójności danych, wygody dostępu, a także takiego, które będzie równocześnie odporne na awarie sprzętu. Terabajty, a już na pewno petabajty danych, wymagają czegoś więcej, niż jedna zakurzona skrzyneczka gdzieś w kącie naszego biura. Czym więcej skrzyneczek, tym większa szansa, że któraś z nich ulegnie awarii. A system musi działać...

Rozwiązań jest - na dzień dzisiejszy - całkiem sporo. Jest Hadoop, jest MongoDB, jest Cassandra, Dynamo, Virtuoso i mnóstwo innych, mniej lub bardziej efemerycznych rozwiązań umożliwiających składowanie całkiem konkretnych ilości danych w sposób nie do końca uporządkowany, za to wydajny i bezpieczny. Wszystkie one mają jednak różnego rodzaju wady, wokół których programiści muszą budować obejścia.

Na przykład większość baz typu NoSQL nie wspiera JOIN-ów między tabelami, lub wspiera je po łebkach i po macoszemu. Programiści muszą więc budować jakieś zawiłe struktury logiczne na poziomie aplikacji, co jest upierdliwe, błędogenne i przez to droższe w utrzymaniu.

Panaceum na te bolączki - a przynajmniej tak to wygląda z zapowiedzi - ma być produkt pt. "CockroachDB", czyli baza, która - podobnie jak karaluchy - przetrwa każdą katastrofę i będzie po prostu działać. A oprócz tego zapewni łatwy, wygodny dostęp do danych, spójność przy zapisie i odczycie oraz liniową skalowalność. W dodatku ma to być produkt OpenSource.

Twórcy CockroachDB pracowali kiedyś dla Google, mają więc sporo doświadczenia z bardzo dużymi zbiorami danych. Projekt jest jeszcze na wczesnym etapie - na tyle wczesnym, że nie są jeszcze znane szczegóły sposobu komunikacji ze światem zewnętrznym. Ma być JSON, ma być jakiś tam SQL, ale to wszystko póki co w głębokich planach. Póki co twórcy skupiają się na opracowaniu odpowiednio "pancernej" architektury, która - w razie awarii - ma zapewnić nie tylko "przeżywalność" danych, ale też brak spadku wydajności.

Co z tego wyniknie?

Niestety, jakkolwiek niewiarygodnie mogłoby to wyglądać, nie jestem wróżką i w związku z tym nie mam najbledszego pojęcia. Ale będę od czasu do czasu zaglądał na stronę projektu. Są entuzjastycznie nastawieni, mają wiedzę i pomysły. Może za piętnaście lat karaluchowe bazy danych będą napędzać jakieś wielkie biznesy.

Pożyjemy - zobaczymy...