Odc 22: Dlaczego warto znać nierelacyjne bazy danych nosql?

Cześć,
Dziś wprowadzę Cię w świat nierelacyjnych baz danych. Opowiem Ci o kulisach ich powstania oraz dlaczego firmy takie jakie Yahoo, Amazon, Facebook czy Google potrzebowały innego produktu jak bazy SQL.
Wśród nierelacyjnych baz danych możemy wyróżnić: bazy klucz-wartość, bazy dokumentów(JSON, XML), bazy kolumnowe i bazy grafowe.
Zapraszam do oglądania :D
#nosql #bigdata #hadoop
Zapisy na kurs: www.nieinforma...
Blog: www.darekbutki...
Kod z odcinka: www.nieinforma...
Facebook: / nieinformatyk
Instagram: / nieinformatyk
Twitter: / nieinformatyk
Zasubskrybuj mój kanał: www.youtube.co...
Witaj na moim kanale :)
Jestem programistą baz danych Oracle oraz developerem hurtownii danych (ETL). W tym miejscu dzielę się z oglądającymi wiedzą dotyczącą relacyjnych baz danych, praktycznych technik pisania SQL oraz optymalizacji kodu PL/SQL. Jeśli chcesz zdobyć praktyczną i rzetelną więdzę o bazach danych to trafiłeś na właściwe miejsce.
Więcej informacji o baza danych znajdziesz zupełnie ZA DARMO na www.nieinforma...

[@martinnereg6769]

Spoko filmik, teraz już wiem czym jest Nosql i czym się różni o spójnego modelu relacyjnego. Przydatna wiedza w dzisiejszym cyfrowym świecie. Dzięki za twój czas i powodzenia. Pozdrawiam.

[@TeIAviv]

👍

[@micha8617]

Skoro skalowanie horyzontalne nie jest możliwe w RDBMS to dlaczego mamy możliwoćś postawienia clustera np. używając Galery, Azure SQL czy Aurory? Możemy przecież mieć klika shardów które ogarniają nam traffic...

[@nieinformatyk]

Dlaczego uważasz, że skalowanie horyzontalne jest niemożliwe? Oczywiście, że jest, tylko nie działa rewelacyjnie, np. Oracle Real Application Cluster to technologia sprzed kilkunastu lat. Założenie było właśnie takie by obsługiwać duże systemy na więcej niż jednym serwerze. Mówimy oczywiście o systemie rozproszonym a nie zwykłej replikacji(kopia bazy na innym serwerze jako standby). Dlaczego więc się mówi, że RDBMS nie są w stanie być skalowane horyzontalnie? Bo RDBMS powstawały w latach 70 - a wtedy nikt nie myślał w kategoriach jednej bazy na wielu serwerach. W związku z tym rozproszona relacyjna baza danych to trochę tak jakby zbudować samochód sportowy a potem spróbować zrobić z niego jednocześnie ciężarówkę o dużej ładowności - niby się da coś przewieźć, ale to nie to samo, co JELCZ 🙂 W związku z tym dedykowane systemy do rozproszonego przetwarzania jak Hadoop radzą sobie z tym dużo lepiej, bo powstały po to by takie przetwarzanie obsługiwać. Druga rzecz to kwestia spójności ACID, która w RDBMS jest najważniejsza. Two-phase commit to przykład problemów z jakimi trzeba się liczyć w rozproszonych systemach: albo spójność albo wydajność. RDBMS powstał przy założeniu, że dane są strukturalne, opisane i mają być w 100% spójne. Mocno uogólniając nosql to bazy stawiające wydajność ponad spójność - stąd lepiej nadają się do rozproszonych systemów. Jak zawsze coś za coś, nie da się mieć wszystkiego 🙂

[@epicpartypl]

Siema, pod filmem przydałyby się tytuły i autorzy tych książek jakby ktoś chciał sobie przeczytać ;)

[@nieinformatyk]

Jakby ktoś nie potrafił odczytać z nagrania: H.Garcia-Molina: Systemy baz danych Thomas Connolly, Carolyn Begg - Systemy baz danych. Praktyczne metody projektowania, implementacji i zarządzania. H.Garcia-Molina, Jeffrey D.Ullman, Jennifer Widom: Implementacja systemów baz danych Dan Sullivan - Nosql przyjazny przewodnik Guy Harrision - Nosql, newsql i big data, Bazy danych następnej generacji

[@ceplusista]

wiecej minusow niz plusow, co nie wpadnie projekt oparty o mongo to zaraz sie pojawia temat ze lepiej byloby jednak przepisac na relacyjne ale jest juz za pozno. tak to jest jak biora do projektow bazy ktore nie byly stworzone do powszechnego uzytku.

[@nieinformatyk]

jaki jest główna wada baz MongoDB z którą się zetknąłeś?