Czytałem już twojego bloga. Cieszę się , że poszedłeś o krok dalej i filmy na youtube. Czekam na więcej materiałów o Hadoop no i o Spark :) Brakuje takich materiałów w naszym języku na youtube :)
Na wstępie chciałbym zaznaczyć, że nie neguję sensu używania baz nosql w projektach. Ciekaw też jestem waszych opinii, na przedstawione poniżej moje poglądy i komentarze. Dodatkowo uważam, że głupotą jest trzymanie danych relacyjnych w bazie nosql tak samo jak głupotą jest trzymanie danych nierelacyjnych w bazie relacyjnej. Następnie chciałbym się odnieść do treści materiału: 1. Skalowalność - bazy relacyjne tylko wertykalnie To nie prawda, a przynajmniej w przypadku bazy MS SQL - bez problemu da się ją również skalować horyzontalnie. Co więcej, w przypadku tej konkretnej bazy danych skalowanie horyzontalne da się załatwić na poziomie pojedynczego serwera bazodanowego, rozbijając pliki danych (np. plik A ma dane sprzed 2 lat, plik B ma dane z ostatniego roku, plik C ma dane z ostatnich N miesięcy, plik D ma dane z ostatniego miesiąca) 2. Spójność, transakcje, relacje, "baza danych nas pilnuje i trzyma za rączkę" - słowo klucz w tym miejscu to jest właśnie "spójność", która w bazach relacyjnych jest niejako wymuszona. w Bazach NOSQL bardzo łatwo tą spójność utracić, co szczególnie w systemach, które jakkolwiek zahaczają o finanse może być katastrofalne w skutkach. 3. Z perspektywy systemu rzadko kiedy zdarza się, by obiekt biznesowy składał się tylko z typów prostych. Najczęściej są to obiekty złożone, powiązane ze sobą relacją. Przytoczony przykład obiektu typu faktura jest bardzo fajny. Faktura to w dużym uproszczeniu dane podstawowe typu data wystawienia, numer, ale też, odbiorca, nadawca i pozycje na fakturze. Te 3 ostatnie to nic innego jak obiekty powiązane relacyjnie z podstawowym bytem jakim jest sama faktura. Fakt, da się to zapisać w bazie NOSQL jako jeden wiersz danych. Jeśli korzystamy z dokumentowych baz danych zyskujemy tylko brak operacji JOIN, ale i tak musimy to przełożyć na język obiektowy. fakt, łatwiej pobrać te dane, ale spróbuj przygotować na takiej bazie raporty typu: "wartość zamówień od odbiorcy X", albo "ilość i wartość sprzedanych produktów X". 4. Odporność na awarie Całkowicie nietrafiony argument. Autor zakłada, że w przypadku bazy relacyjnej mamy tylko jedną instancję, a w przypadku bazy NOSQL conajmniej dwie. Zarówno bazy relacyjne jak i nierelacyjne do działania w scenariuszu "always on" wymagają conajmniej 2 instancji. w obu scenariuszach jest to wykonalne i w obu będziemy w czarnej d..., jeśli mamy tylko jedną instancję bazy. 5. Szybkość zapisu / odczytu na przykładzie masowych insertów z urządzeń IOT Fakt, tu bazy NOSQL są lepsze, ale to tylko i wyłącznie z tego powodu, że bez sensu trzymać dane nierelacyjne w bazie relacyjnej. Dane telemetryczne powinny w pierwszej kolejności trafiać do bazy NOSQL, a następnie po przetworzeniu i nadaniu im jakiegoś sensu trafić do bazy relacyjnej, gdzie będą miały jakiś sens w kontekście całego systemu. 6. Cache, logi, search Bez dwóch zdań - idealne są do tego NOSQL 7. Dobór bazy do projektu Osobiście uważam, że duży system powinien być oparty zarówno o bazę relacyjną jak i nierelacyjną.
1. To zależy do rozwiązania bazodanowego. Wiele producentów ma to w ofercie ale działa to często średnio. 2. Bardzo to uprościłeś. Generalnie sprawa rozbija się znów o teorię bazy danych i o tak zwany CAP. Bazy NoSQLowe też temu podlegają en.wikipedia.org/wiki/CAP_theorem. I można wyróżnić bazy NoSQLowe , które mają tranzakcje.
Dzięki za fajny komentarz. Zgadzam się z tym co napisałeś. W materiale sporo generalizuje. W niecałe 6 minut bardziej chciałem zainteresować kogoś rozwiązaniami NoSQL, niż przekonywać, że są lepsze/gorsze. Jest też fala rozwiązań NewSQL, czyli relacyjnych baz zaprojektowanych do skalowania (CockroachDb, Spanner czy Azure SQL). Co do punktu 4 - faktycznie mogłem to bardziej ubrać to w słowa teorii CAP => Partition Tolerance.
Czytałem już twojego bloga. Cieszę się , że poszedłeś o krok dalej i filmy na youtube. Czekam na więcej materiałów o Hadoop no i o Spark :) Brakuje takich materiałów w naszym języku na youtube :)
Dzięki :-) postaram się coś ogarnąć w tych tematach ;-)
Na wstępie chciałbym zaznaczyć, że nie neguję sensu używania baz nosql w projektach.
Ciekaw też jestem waszych opinii, na przedstawione poniżej moje poglądy i komentarze.
Dodatkowo uważam, że głupotą jest trzymanie danych relacyjnych w bazie nosql tak samo jak głupotą jest trzymanie danych nierelacyjnych w bazie relacyjnej.
Następnie chciałbym się odnieść do treści materiału:
1. Skalowalność - bazy relacyjne tylko wertykalnie
To nie prawda, a przynajmniej w przypadku bazy MS SQL - bez problemu da się ją również skalować horyzontalnie. Co więcej, w przypadku tej konkretnej bazy danych skalowanie horyzontalne da się załatwić na poziomie pojedynczego serwera bazodanowego, rozbijając pliki danych (np. plik A ma dane sprzed 2 lat, plik B ma dane z ostatniego roku, plik C ma dane z ostatnich N miesięcy, plik D ma dane z ostatniego miesiąca)
2. Spójność, transakcje, relacje, "baza danych nas pilnuje i trzyma za rączkę" - słowo klucz w tym miejscu to jest właśnie "spójność", która w bazach relacyjnych jest niejako wymuszona. w Bazach NOSQL bardzo łatwo tą spójność utracić, co szczególnie w systemach, które jakkolwiek zahaczają o finanse może być katastrofalne w skutkach.
3. Z perspektywy systemu rzadko kiedy zdarza się, by obiekt biznesowy składał się tylko z typów prostych. Najczęściej są to obiekty złożone, powiązane ze sobą relacją. Przytoczony przykład obiektu typu faktura jest bardzo fajny. Faktura to w dużym uproszczeniu dane podstawowe typu data wystawienia, numer, ale też, odbiorca, nadawca i pozycje na fakturze. Te 3 ostatnie to nic innego jak obiekty powiązane relacyjnie z podstawowym bytem jakim jest sama faktura. Fakt, da się to zapisać w bazie NOSQL jako jeden wiersz danych. Jeśli korzystamy z dokumentowych baz danych zyskujemy tylko brak operacji JOIN, ale i tak musimy to przełożyć na język obiektowy. fakt, łatwiej pobrać te dane, ale spróbuj przygotować na takiej bazie raporty typu: "wartość zamówień od odbiorcy X", albo "ilość i wartość sprzedanych produktów X".
4. Odporność na awarie
Całkowicie nietrafiony argument. Autor zakłada, że w przypadku bazy relacyjnej mamy tylko jedną instancję, a w przypadku bazy NOSQL conajmniej dwie. Zarówno bazy relacyjne jak i nierelacyjne do działania w scenariuszu "always on" wymagają conajmniej 2 instancji. w obu scenariuszach jest to wykonalne i w obu będziemy w czarnej d..., jeśli mamy tylko jedną instancję bazy.
5. Szybkość zapisu / odczytu na przykładzie masowych insertów z urządzeń IOT
Fakt, tu bazy NOSQL są lepsze, ale to tylko i wyłącznie z tego powodu, że bez sensu trzymać dane nierelacyjne w bazie relacyjnej. Dane telemetryczne powinny w pierwszej kolejności trafiać do bazy NOSQL, a następnie po przetworzeniu i nadaniu im jakiegoś sensu trafić do bazy relacyjnej, gdzie będą miały jakiś sens w kontekście całego systemu.
6. Cache, logi, search
Bez dwóch zdań - idealne są do tego NOSQL
7. Dobór bazy do projektu
Osobiście uważam, że duży system powinien być oparty zarówno o bazę relacyjną jak i nierelacyjną.
1. To zależy do rozwiązania bazodanowego. Wiele producentów ma to w ofercie ale działa to często średnio. 2. Bardzo to uprościłeś. Generalnie sprawa rozbija się znów o teorię bazy danych i o tak zwany CAP. Bazy NoSQLowe też temu podlegają en.wikipedia.org/wiki/CAP_theorem. I można wyróżnić bazy NoSQLowe , które mają tranzakcje.
Dzięki za fajny komentarz. Zgadzam się z tym co napisałeś. W materiale sporo generalizuje. W niecałe 6 minut bardziej chciałem zainteresować kogoś rozwiązaniami NoSQL, niż przekonywać, że są lepsze/gorsze. Jest też fala rozwiązań NewSQL, czyli relacyjnych baz zaprojektowanych do skalowania (CockroachDb, Spanner czy Azure SQL). Co do punktu 4 - faktycznie mogłem to bardziej ubrać to w słowa teorii CAP => Partition Tolerance.
Fajny film. Daję suba :)
Marta P. Dzięki 😊
miauuu