Dlaczego relacyjne bazy danych nie mogą sprostać skalom Big Data?

Często powtarza się, że problemem Big Data jest to, że relacyjne bazy danych nie mogą być skalowane w celu przetworzenia ogromnych ilości danych, które są obecnie tworzone.

Ale jakie są ograniczenia skalowalności, z którymi nie wiążą się rozwiązania Big Data, takie jak Hadoop? Dlaczego Oracle RAC, MySQL sharding lub MPP RDBMS, takie jak Teradata (itp.), Nie osiągają tych osiągnięć?

Interesują mnie ograniczenia techniczne - mam świadomość, że koszty finansowe klastrowania RDBMS mogą być wygórowane.

MS właśnie rozmawiało na temat technologii w Holandii, gdzie omawiali niektóre z tych rzeczy. Zaczyna się powoli, ale dostaje się do mięsa Hadoop około 20 minut.

Istotą tego jest to, że „to zależy”. Jeśli masz rozsądnie zaaranżowany (przynajmniej w pewnym stopniu) łatwy do podziału zestaw danych, który (przynajmniej w pewnym stopniu) jest jednorodny, powinno być dość łatwe skalowanie do tych dużych ilości danych za pomocą RDBMS, w zależności od tego, co robisz .

Hadoop i MR wydają się być bardziej nastawione na sytuacje, w których zmuszony jesteś do dużych rozproszonych skanów danych, szczególnie gdy dane te niekoniecznie są tak jednorodne lub tak ustrukturyzowane, jak to, co znajdujemy w świecie RDBMS.

Jakie ograniczenia nie są związane z rozwiązaniami Big Data? Dla mnie największym ograniczeniem, do którego nie są zobowiązani, jest ustalenie z góry sztywnego schematu. Dzięki rozwiązaniom Big Data wrzucasz teraz ogromne ilości danych do „skrzynki”, a następnie dodajesz logikę do swoich zapytań, aby poradzić sobie z brakiem jednorodności danych. Z punktu widzenia dewelopera kompromisem jest łatwość implementacji i elastyczność interfejsu użytkownika, w porównaniu do złożoności zapytań i mniejszej spójności danych.

Pionier i badacz bazy danych Michael Stonebraker napisał artykuł, w którym omawia ograniczenia tradycyjnych architektur baz danych. Ogólnie rzecz biorąc, skalują się one przy użyciu droższego sprzętu, ale mają trudności z skalowaniem równoległym z większą ilością sprzętu towarowego i są ograniczone przez starszą architekturę oprogramowania, która została zaprojektowana dla starszej epoki. Twierdzi, że era BigData wymaga wielu nowych architektur baz danych, które wykorzystują nowoczesną infrastrukturę i optymalizują pod kątem określonego obciążenia. Przykładem tego jest projekt sklepu C, który doprowadził do komercyjnej bazy danych Vertica Systems, oraz projekt sklepu H, który doprowadził do VoltDB, bazy danych SQL OLTP w pamięci zaprojektowanej do dużych obciążeń BigData. (Pełne ujawnienie, pracuję dla VoltDB).

To seminarium internetowe może Cię zainteresować na ten temat. Odpowiada na niektóre mity, które powstały w wyniku sukcesu baz danych NoSQL. Zasadniczo twierdzi, że SQL nie był problemem, nie trzeba rezygnować z tradycyjnych funkcji bazy danych, takich jak spójność, aby uzyskać wydajność.

Nie jest do końca prawdą, że RDBMS nie może być skalowany. Jednak częściowa prawda zawarta w oświadczeniu zależy od architektury. Na podanej liście Oracle RAC różni się od reszty (podzielony na MySQL i Teradata). Główną różnicą jest wspólna architektura dysku w porównaniu z architekturami współdzielonymi niczym.

Architektury dysków współużytkowanych, takie jak Oracle RAC, podlegają skalowaniu, ponieważ w pewnym momencie wszystkie inne uruchomione maszyny powinny zsynchronizować się z pewną częścią danych. Na przykład globalny menedżer śluzy jest zabójcą. Możesz dostrajać go do pewnego stopnia, ale ostatecznie uderzysz w ścianę. Jeśli nie możesz łatwo dodać maszyn, powinieneś mieć mniej, ale super mocnych maszyn, które mogą poparzyć twoją kieszeń. W przypadku architektury współdzielonej (lub danych dzielonych), każda maszyna przejmuje na własność niektóre dane. Nie musi synchronizować się z innymi komputerami, jeśli chce zaktualizować niektóre dane.

Potem pojawia się rasa baz danych NoSQL. Traktowałbym je jako podzbiór tradycyjnych baz danych RDBMS. Nie wszystkie aplikacje na tym świecie będą wymagały wszystkich funkcji oferowanych przez RDBMS. Jeśli chcę używać bazy danych jako pamięci podręcznej, nie dbam o trwałość. Być może w niektórych przypadkach nie dbałbym również o spójność. Jeśli wszystkie moje wyszukiwanie danych opiera się na kluczu, nie potrzebuję wsparcia dla zapytań o zakres. Mogę nie potrzebować indeksów wtórnych. Nie potrzebuję całej warstwy przetwarzania zapytań / optymalizacji zapytań, którą posiadają wszystkie tradycyjne bazy danych.