*) Relacyjne bazy danych można zastosować prawie w każdym przypadku, jednak ich złożoność może stać się ograniczeniem. W przypadkach, w których liczy się skalowalność, proste rozwiązania wygrywają. Wiele zastosowań znacznie bardziej doceni prostotę modelowania, oprogramowania i administracji, które nie zawsze są udziałem relacyjnych baz danych (Hamilton, 2009).
Chmura stawia nowe wymagania
Zastosowanie koncepcji chmury ma sens wtedy, kiedy poziom wykorzystania zasobów takich jak procesor, pamięć, czy przepustowość łączy, znacznie różni sie w czasie oraz kiedy dostępność usługi powinna być taka sama zarówno w momentach dużego obciążenia (peak) jak i bliskiego średniej. Wtedy to, możliwość szybkiego zwiększenia np. liczby serwerów obsługujących nasze rozwiązanie (skalowania) bez konieczności ich fizycznego zakupienia, staje się nieoceniona. Szczególnie jeżeli z tej mocy obliczeniowej możemy zrezygnować (i w efekcie nie płacić za nią), kiedy już nie będzie potrzebna. Takie możliwości daje chmura (o czym pisałem w poprzednim poście). Możliwości te są szczególnie istotne dla firm, które nie chcą (lub nie mogą) wyłożyć znacznej sumy pieniędzy na sprzęt i infrastrukturę, i pomimo tego, że korzystanie z chmury w ostatecznym rozrachunku może być droższe, zyskana elastyczność będzie dla nich korzystniejsza.
Wielu z dostawców infrastruktury i platform w chmurze twierdzi, że zaletą takich rozwiązań jest brak konieczności podejmowania kluczowych decyzji "z góry". Chmura umożliwia "reagowanie" na zwiększającą się liczbę klientów (użytkowników) i związany z tym wzrost konsumpcji zasobów w miarę upływu czasu. Elastyczność ta dotyczy zarówno infrastruktury (IaaS) jak i platformy (PaaS). Dlatego, przy projektowaniu rozwiązania należy zwrócić uwagę, aby całość dobrze dostosowywała się do obciążenia, również baza danych. Co więcej nie chodzi tu tylko o możliwość zwiększenia ilości zasobów, ale także o czas w jakim jest to możliwe, gdyż zwiększenie obciążenia nie zawsze jest możliwe do przewidzenia (Perry, 2011).
Przy wyborze dostawcy chmury ważna jest ekonomia (musi się to opłacać), ale również bliskość zasobów do użytkownika końcowego (tak by transfer danych był jak najkrótszy, ang. geolocation). Oznacza to, że wraz z ekspansją biznesową firmy, konieczna może stać się przeprowadzka geograficzna lub całkowita zmiana dostawcy usługi. Konieczność tą rozumieją bardzo dobrze dostawcy rozwiązań, silnie pracując nad tym aby ich oprogramowanie było niezależne od infrastruktury (ang. cloud agnostic). Klient powinien mieć możliwość łatwego przeniesienia rozwiązania (i systemu bazy danych) np. między Amazon Web Services, a lokalnym providerem. Ponieważ wśród dostawców infrastruktury również zachodzą dynamiczne zmiany, niezależność od infrastruktury jest obecnie jednym z większych wyzwań dostawców oprogramowania bazodanowego.
Przedstawiciele dostawców systemów baz danych dedykowanych dla chmury, zapytani co będzie wiodącym zastosowaniem ich produktów (killer apps) wskazali m.in.: zastosowania analityczne (ludzie gromadzą duże ilości danych i chcą je przetwarzać), różnorodność urządzeń i aplikacji łączących się bezpośrednio (bez warstwy middleware) z bazami danych (tablet, smartfon, notebook, serwer innego serwisu, ...) oraz gromadzenie i przetwarzanie danych nieustrukturyzowanych tj. zdjęcia, wideo, czy audio (Perry, 2011).
Reasumując, najważniejsze wyzwania jakie stoją przed twórcami baz danych zorientowanych na chmurę to:
- szybkość i prostota oprogramowania oraz administracji bazy danych,
- efektywne przetwarzanie różnorodnych danych (również nieustrukturyzowanych) w dużej ilości,
- skalowalność w oparciu o tanią i standardową infrastrukturę (commodity servers, wirtualizacja),
- elastyczność rozumiana jako szybkość skalowalności,
- elastyczność rozumiana jako łatwość dostępu dla różnych urządzeń/konsumentów danych,
- uniezależnienie użytkownika od dostawcy chmury (łatwe przeniesienie rozwiązania do innej chmury geograficznie i logicznie).
Bazy w chmurach
Rozwiązań klasy NoSQL jest obecnie bardzo wiele. Zazwyczaj są to rozwiązania oparte o rozproszony system plików i model danych klucz-wartość (ang. key-value data store). Są oczywiście rozwiązania komercyjne tj. Xeround oraz open-source. Wiele firm stworzyło wysokowydajne i skalowalne produkty na własne potrzeby i udostępniło je w oparciu o model open-source.
Miało to miejsce w przypadku bazy danych Cassandra (obecnie projekt Apache), z której korzysta m.in. Facebook (gdzie pierwotnie powstała) i Twitter. Cassandra jest próbą połączenia rozproszonego systemu wzorowanego na Amazon Dynamo i moelu danych opartego o Google BigTable. Jest to baza optymalizowana pod odczyt danych, w której informacja podczas zapisu jest propagowana do wszystkich węzłów. Daje to dostępność informacji do odczytu w wielu punktach (węzłach), ale kosztem spójności - propagacja danych między węzłami trwa i zaraz po zapisie nowej informacji do bazy, przez krótki okres czasu informacja we wszystkich węzłach nie będzie spójna - model spójności tzw. eventually consistent (Bunch, 2010).
Innym przykładem może być HBase - wysokowydajna baza danych również oparta o koncepcję BigTable, będąca "nakładką" na rozproszony system plików o nazwie Hadoop. Projekt Haddop (obecnie prowadzony również w ramach Apache) jest open-source'ową implementacją wypracowanej przez Google w ramach Google File System koncepcji MapReduce. Jest to rozwiązanie, które zostało zaprojektowane na potrzeby przetwarzania wsadowego (batch processing) na dużych zbiorach.
Dalsze przykłady można mnożyć. Bunch et al. (2010) stworzył ciekawe (i jedno z pierwszych) porównanie wydajności różnych rozwiązań klasy NoSQL. Brano pod uwagę rozwiązania, które współpracują z platformą AppScale i opisano m.in. rozwiązania: wspomniane Cassandra i HBase, Hypertable (stosowany przez chińską przeglądarkę Baidu), Voldemort (rozwijany przez LinkedIn), MongoDB (stosowana przez SourceForge, Github i Electronic Arts), MemcacheDB (połączenie frameworku do cache'owania memcached i bazy Berkeley DB) i MySQL (jedyna relacyjna baza danych w porównaniu).
Adopcja nowej technologii
Podobnie jak w przypadku platform programistycznych, adopcja nowych rozwiązań bazodanowych w organizacjach odbywa sie bottom-up (Perry, 2011), czyli nośnikami zmiany są programiści poszukujący nowych, adekwatnych rozwiązań dla swoich problemów. Dlatego też bardzo istotne jest nie tylko udostępnianie produktu do testów jako wersja do ściągnięcia, ale również jako PaaS. Daje to możliwość przetestowania bazy od razu w chmurze, zanim podjęta zostanie decyzja o jej wdrożeniu. Podobnie dzieje się to w małych firmach (które nie mają rozbudowanych działów wsparcia infrastruktury) i dużych korporacjach (w których zorganizowanie serwera i uzyskanie zgody na "postawienie" nowego systemu bazy danych może trwać dość długo).
To jednak nie koniec relacyjnych baz danych
Chmura nie oznacza końca relacyjnych baz danych. Zastosowania, w których relacyjne bazy danych do tej pory dobrze się sprawdzały, nie znikną. Rynek rozszerza się i robi miejsce dla baz typu NoSQL. Co więcej, dostawcy rozwiązań dedykowanych dla chmur sięgają również do rozwiązań hybrydowych - łączących zalety relacyjnych i nierelacyjnych baz danych. Pamiętajmy, że na świecie jest ogromna liczba programistów i inżynierów, którzy kariera zawodowa związana jest głównie z bazami relacyjnymi. Wielu dostawców związanych z chmurą bierze na cel właśnie tą grupę i próbuje tworzyć rozwiązania umożliwiające dostęp do silników swoich produktów przez interfejs SQL (Perry, 2011).
Co więcej, podobnie jak Amazon, także Google oferuje w chmurze zarówno usługę związana z relacyjna baza danych, jak również bazę NoSQL. Widać, że nierelacyjne bazy danych stają się obowiązkowym uzupełnieniem oferty dostawców PaaS i IaaS.
+++
+++
Polecane posty i artykuły:
- Chmura dla początkujących - model chmury i jego warstwy
- Czy chmura to już standard? - rynek usług związanch z cloud services (równiez w Polsce)
- Panel na temat baz danych w chmurze - poniżej (Perry, 2011)
+++
*) Rysunek za safecloudcrm.com
Bunch, Chris, Chohan, Navraj, Krintz, Chandra, Chohan, Jovan, Kupferman, Jonathan, Lakhina, Puneet, Li, Yimin, Nomura, Yoshihide (2010), "An Evaluation of Distributed Datastores Using
the AppScale Cloud Platform", IEEE Cloud10: International Conference on Cloud Computing, July, 2010, dostępne pod http://cs.ucsb.edu/~ckrintz/papers/cloud10.pdf, pobrane 28.11.2011
Hamilton, James (2009), "One Size Does Not Fit All", Perspectives - James Hamilton's Blog, obulikowane 3.11.2009, dostępne pod http://perspectives.mvdirona.com/CommentView,guid,afe46691-a293-4f9a-8900-5688a597726a.aspx, pobrane 21.11.2011
Perry, Gava (2011), "Video: Cloud Databases Panel at GigaOm Structure", dostępne pod http://gevaperry.typepad.com/main/2011/06/video-cloud-databases-panel-at-gigaom-structure.html, opublikowane 23.06.2011, pobrane 21.11.2011
