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

17

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.

scalability

— Jeremy Beard
źródło

15

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.

— Dave Markle
źródło

Dzięki Dave, przybliżasz mnie do tego, co próbuję się dowiedzieć. Mówisz, że Hadoop jest nastawiony na sytuacje z dużymi skanami rozproszonymi - jeśli niektóre / wiele RDBMS ma rozwiązania klastrowe (RAC, odłamki, MPP itp.), Dlaczego oni również nie mogą tego zrobić? Co sprawia, że RDBMS nie jest w stanie posortować 10 bilionów rekordów w ciągu 16 godzin, jak potrafi to bardzo duża klaster Hadoop? patrz tutaj

— Jeremy Beard

2

Nic nie stoi na przeszkodzie, aby klaster RDBMS wykonywał tego rodzaju pracę, a można skonfigurować RDBMS tak, aby skalował się w taki sposób. Problem z RDBMS polega na tym, że aby to zrobić, musisz bardzo uważać na to, jak strukturyzujesz swój schemat i partycje, aby działało. Architektury Big Data wygrywają, gdy dane nie są wystarczająco ustrukturyzowane, aby można je było łatwo i efektywnie podzielić na partycje i zoptymalizować w RDBMS.

— Dave Markle

1

Niekompetentni projektanci db utrudniają skalowanie relacyjnych baz danych. Zbyt wiele firm uważa, że programiści applatiopn mogą projektować bazy danych (lub, co gorsza, używają ORMS do projektowania), kiedy muszą zatrudnić programistów baz danych od samego początku. Drugą osobą zatrudnioną w projekcie obejmującym dane powinien być programista bazy danych.

— HLGEM

3

@HLGEM: Moja odpowiedź na to brzmi „meh”. Najbardziej efektywnymi programistami będą ci, którzy rozumieją obie strony stosu - pomysł, że istnieje coś takiego jak dobry „programista aplikacji”, który cały czas pracuje z RDBMS, nie wiedząc, jak to działa, jest błędem . Podobnie, pomysł, że istnieje coś takiego jak dobry „programista bazy danych”, który nie rozumie ORM lub aplikacji, jest również błędny.

— Dave Markle

6

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ść.

— BenjaminBallard
źródło

6

Aby zakwalifikować się jako pełne ujawnienie, prawdopodobnie powinieneś również wspomnieć, że twój współzałożyciel i dyrektor ds. Technologii Michael Stonebraker był także współautorem wszystkich twoich przykładów. I że wsparcie VoltDB w SQL jest żenująco mały podzbiór .

— Daniel Lyons,

5

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.

— sunil
źródło