Czy dyski SSD zmniejszają użyteczność baz danych


28

Słyszałem dziś tylko o Robercie Martinie i wygląda na to, że jest znaczącą postacią w świecie oprogramowania, więc nie mam na myśli, że mój tytuł wygląda tak, jakby to była przynęta na kliknięcie lub wkładam słowa do jego ust, ale to po prostu jak interpretowałem to, co od niego usłyszałem, z moim ograniczonym doświadczeniem i zrozumieniem.

Oglądałem dzisiaj wideo (o architekturze oprogramowania), na wykładzie Roberta C. Martina, aw drugiej połowie wideo temat baz danych był w centrum uwagi.

Z mojego zrozumienia tego, co powiedział, wydawało się, mówił, że dyski SSD zmniejsza przydatność baz danych ( znacznie ).

Aby wyjaśnić, jak doszedłem do tej interpretacji:

Omówił, w jaki sposób przy dyskach twardych / wirujących dyskach pobieranie danych jest powolne. Zauważył jednak, że obecnie używamy dysków SSD. Zaczyna od „Nadchodzi RAM”, a następnie wspomina o dyskach RAM, ale potem mówi, że nie może nazwać go dyskiem RAM, więc ucieka się tylko do powiedzenia RAM. Tak więc w przypadku pamięci RAM nie potrzebujemy indeksów, ponieważ uzyskanie każdego bajtu zajmuje tyle samo czasu. ( ten akapit jest parafrazowany przeze mnie )

Zatem sugerowanie pamięci RAM (jak w pamięci komputera) jako zamiennika DB (ponieważ tak interpretowałem jego oświadczenie jako) nie ma sensu, ponieważ to tak, jakby powiedzieć, że wszystkie rekordy są przetwarzane w pamięci przez cały czas działania aplikacji ( chyba że pobierzesz z pliku dyskowego na żądanie)

Więc uciekłem się do myślenia przez RAM, on ma na myśli SSD. W takim razie twierdzi, że dyski SSD zmniejszają użyteczność baz danych. Mówi nawet: „Gdybym był Wyrocznią, bałbym się. Podstawą mojego istnienia jest wyparowywanie”.

Z mojego niewielkiego zrozumienia dysków SSD, w przeciwieństwie do dysków twardych, które O(n)wymagają czasu (jak sądzę), dyski SSD są bliskie O(1)lub prawie losowe. Tak więc jego sugestia była dla mnie interesująca, ponieważ nigdy tak o tym nie myślałem. Kiedy po raz pierwszy przedstawiłem się bazom danych kilka lat temu, kiedy profesor opisywał zalety w stosunku do zwykłego systemu plików, doszedłem do wniosku, że podstawową rolą bazy danych jest zasadniczo bardzo zindeksowany system plików (a także optymalizacje, buforowanie, równoczesny dostęp, itp.), więc jeśli indeksy nie są potrzebne na dysku SSD, tego rodzaju bazy danych są mniej przydatne.

Niezależnie od tego, poprzedzając, że jestem nowicjuszem, trudno mi uwierzyć, że stają się mniej przydatne, ponieważ wszyscy nadal używają DB jako podstawowego punktu ich aplikacji, zamiast czystego systemu plików, i czuł się, jakby nadmiernie uprościł rola baz danych.

Uwaga : obserwowałem do końca, aby upewnić się, że nie powiedział nic innego.

Dla porównania: 42:22 pojawia się, gdy pojawia się cały temat bazy danych, 43:52 zaczyna się od „Dlaczego w ogóle mamy bazy danych”

Ta odpowiedź mówi, że dyski SSD znacznie przyspieszają DB. To pytanie dotyczy sposobu zmiany optymalizacji.

Do TL; DR moje pytanie: czy pojawienie się powszechnego użycia dysków SSD na rynku serwerów (bez względu na to, czy nadchodzi, czy już się wydarzyło) zmniejsza użyteczność baz danych?

Wydawało się, że prezenter próbował przekazać, że w przypadku dysków SSD można przechowywać dane na dysku i nie trzeba się martwić, jak wolno będzie je odzyskiwać, tak jak w przypadku starszych dysków twardych, podobnie jak w przypadku dysków SSD, czasy wyszukiwania są bliskie O(1)(Myślę). Tak więc w przypadku, gdy jest to prawdą, hipotetycznie straciłoby to jedną z jego zalet: indeksowanie, ponieważ nie ma już korzyści z posiadania indeksów dla szybszych czasów wyszukiwania.

Odpowiedzi:


59

W bazie danych jest kilka rzeczy, które należy poprawić podczas korzystania z dysków SSD. Na przykład, mówiąc dla PostgreSQL, możesz dostosować effective_io_concurrencyi random_page_cost. Jednak szybsze odczyty i szybszy losowy dostęp nie są tym, co robi baza danych. Zapewnia

Po prostu myli się co do indeksów. Jeśli całą tabelę można wczytać do pamięci RAM, indeks jest nadal przydatny. Nie wierzysz mi? Zróbmy eksperyment myślowy,

  • Wyobraź sobie, że masz tabelę z jedną indeksowaną kolumną.

    CREATE TABLE foobar ( id text PRIMARY KEY );
  • Wyobraź sobie, że w tej tabeli jest 500 milionów wierszy.

  • Wyobraź sobie, że wszystkie 500 milionów wierszy łączy się w plik.

Co jest szybsze

  1. grep 'keyword' file
  2. SELECT * FROM foobar WHERE id = 'keyword'

Nie chodzi tylko o to, gdzie są dane, ale o to, jak je zamawiasz i jakie operacje możesz to zrobić. PostgreSQL obsługuje indeksy B-tree, Hash, GiST, SP-GiST, GIN i BRIN (i Bloom poprzez rozszerzenie). Głupotą byłoby myśleć, że cała ta matematyka i funkcjonalność znikają, ponieważ masz szybszy losowy dostęp.


31
Tylko dodatek - OP powinien uważać, aby nie pomylić „dostępu losowego” z „dostępem adresowanym treściowo”. Jak zauważono OP, „losowy dostęp” oznacza, że ​​dotarcie do każdego bajtu pamięci to O (1). Jednak wyszukiwanie danych w „pamięci o dostępie swobodnym” nadal wymaga sekwencyjnego przeszukiwania; to znaczy, że nie może zwrócić się do pamięci „znajdź mi dane, który wygląda jak ten ” i go magicznie przekazana do ciebie.
Bob Jarvis - Przywróć Monikę

2
@BobJarvis Masz rację. Twój komentarz pomaga jeszcze bardziej wyjaśnić przykład „Co jest szybsze” @ EvanCarroll na temat tego, dlaczego indeksowanie, a nawet subindeksowanie ma znaczenie, a samo chwytanie O(1)nie jest wystarczające dla przypadków użycia, które zapewnia DB
Abdul

12

Na podstawie Twojego postu wydaje się, że wyraźnym komunikatem jest to, że optymalizacje czasu wyszukiwania RDBMS są zastępowane sprzętem, co sprawia, że ​​czas operacji we / wy jest znikomy.

To jest absolutna prawda. SSD na serwerach baz danych w połączeniu z wysoką (rzeczywistą) pamięcią RAM sprawia, że ​​IO czeka znacznie krócej. Jednak indeksowanie i buforowanie RDBMS jest nadal cenne, ponieważ nawet systemy z tym wielkim dobrodziejstwem operacji we / wy mogą mieć i będą mieć wąskie gardła w wyniku źle działających zapytań spowodowanych złym indeksowaniem. Zwykle występuje to tylko w aplikacjach o dużym obciążeniu lub źle napisanych aplikacjach.

Kluczową wartością dla systemów RDBMS jest spójność danych, dostępność danych i agregacja danych. Korzystanie z arkusza kalkulacyjnego programu Excel, pliku csv lub innej metody przechowywania „bazy danych” nie daje żadnych gwarancji.

SSD nie chroni Cię przed głównym serwerem, który stanie się niedostępny z jakiegokolwiek powodu (sieć, uszkodzenie systemu operacyjnego, utrata zasilania). SSD nie chroni cię przed złą modyfikacją danych. Dysk SSD nie przyspiesza uruchamiania analiz w porównaniu z „po prostu ich posiadaniem”.


Chociaż uzyskałem lepszy wgląd, pytałem w kontekście przechowywania danych surowego SSD w porównaniu do przechowywania danych na DB z dyskiem twardym, a twoja odpowiedź jest w kontekście DB na SSD (z powodu złego sformułowania pytania ode mnie)
Abdul,

4
@Abdul To porównanie jest pomostem typu jabłko-zawieszenie. Surowe urządzenie zapewnia dużą przestrzeń dyskową; baza danych umożliwia uporządkowanie i dostęp do pamięci zgodnie z modelem danych. Josh ma tutaj na myśli to, że jeśli przejdziesz do tego z gwiaździstym wzrokiem pomysłem, że surowy dysk SSD jest cudowną rzeczą, ponieważ jest „szybki” i że po prostu napiszesz kod, aby zrobić całą pamięć na tym surowym wolumenie , ostatecznie skończysz pisać bazę danych.
Blrfl,

8

Wujek Bob prawdopodobnie mówił o bazach danych w pamięci, takich jak Redis lub Gemfire . W tych bazach danych wszystko w bazie danych jest naprawdę zawarte w pamięci RAM. Baza danych może być początkowo pusta i być przechowywana z danymi krótkotrwałymi (wykorzystywanymi jako pamięć podręczna) lub może zostać uruchomiona przez załadowanie wszystkiego z dysku i okresowe zmiany punktów kontrolnych na dysk.

Staje się to coraz bardziej popularne, ponieważ RAM staje się tani, a terabajt danych może być przechowywany w klastrowej bazie danych w pamięci. Istnieje wiele przypadków użycia, w których szybkość natychmiastowego dostępu do rzeczy sprawia, że ​​warto umieścić pamięć RAM, a nie nawet szybki dysk, taki jak SSD. Możesz nawet kontynuować używanie SQL dla niektórych z nich, jeśli ma to sens.

Dlaczego to ma martwić Oracle? Dane rosną i jest mało prawdopodobne, że RDBMS znikną. Jednak wiele czasu poświęconego inżynierii firmy Oracle na przestrzeni lat sprawiło, że pobieranie danych na wirujących dyskach jest naprawdę szybkie. Oracle będzie musiała dostosować się do zupełnie innej warstwy pamięci. Są z Oracle Database In Memory , ale są narażeni na inną konkurencję niż w przeszłości. Pomyśl, ile czasu zajęło upewnienie się, że optymalizator zapytań wybiera odpowiednie strategie na podstawie układu rzeczy na dysku ...


Ach Nigdy nie wiedziałem, że istnieją takie rzeczy, jak bazy danych w pamięci
Abdul,

1
Jako kolejny przykład SQLite może działać w pamięci, więc nie trzeba używać innej bazy danych
użytkownik151019,

8

Społeczność Wiki post zbierający odpowiedzi pierwotnie pozostawione jako komentarze do pytania


Powiedziałbym wręcz przeciwnie. Ponieważ prędkości odczytu / zapisu są tak szybkie, teraz możesz uzyskać akcelerowaną przez GPU bazę danych (np. BlazingDB lub Alenka ) w celu szybszego zgniatania liczb. Teraz możesz uruchamiać jeszcze bardziej złożone zapytania. Teraz zapytania, których ludzie nawet nie rozważaliby, mogą być uruchamiane z rozsądną prędkością. Im bardziej złożone i im więcej danych, tym lepiej - cybernard

Podczas gdy Bob Martin jest już od dawna i jego opinie są na ogół warte wysłuchania (jeśli nie zgadzam się z :-), w tym przypadku myślę, że nurkuje w tłumie „Śmierć relacyjnych baz danych jest na nas” (z których Jestem członkiem stowarzyszonym :-). W przypadku niektórych rzeczy w ograniczonych okolicznościach można przedstawić nieco przekonujący argument, że nierelacyjne technologie baz danych mogą zapewnić przewagę. To powiedziawszy, jednak IMO, model relacyjny, który jest wadliwy na wiele różnych sposobów, wciąż zapewnia najlepszy dostępny obecnie model bazy danych ogólnego przeznaczenia. YMMV. - Bob Jarvis

Podstawowym powodem, dla którego korzystamy z baz danych, nie jest to, że dyski są wolne (w rzeczywistości pierwotnie było to cytowane jako powód, aby nie korzystać z baz danych), ale raczej dlatego , że dane są skomplikowane . Podstawowym celem bazy danych jest umożliwienie wielu aplikacjom / użytkownikom znalezienia właściwych danych, a nawet jednoczesnej ich zmiany w kontrolowany sposób. Wykonanie tego szybko jest tylko drugorzędnym celem baz danych. - RBarryYoung

RDBMS wkrótce nie odejdzie; są najlepszym wyborem dla niektórych typów aplikacji, a NoSQL (Mongo itp.) jest najlepszym wyborem dla innych. Konie na kursy. - sh1rts

Baza danych pomaga organizować dane. Zresztą tak naprawdę nie był przeznaczony do szybkiego dostępu do danych. - JI Xiang

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.