Nie widzę sensu używania baz SQL

Napisz mi w 3 minuty w Pythonie (może być z Django) zapytanie, które w 50ms zwróci wiersz na podstawie nazwy użytkownika z tych 10 mln wierszy.

W SQL zrobisz to w 2 minuty. Na CSV daję Ci 3.

Ewentualnie możesz całkowicie oddzielić klasy domenowe od klas reprezentujących encje w bazie, ale znów- znajdą się głosy za i przeciw takiemu rozwiązaniu, a zależnie od wymagań wydajnościowych systemu taka opcja może być zwyczajnie niedopuszczalna.

Oczywiście, moga się pojawić, ale generalnie to rozwiązanie jeśli nie piszemy CRUDów to jest jedyne sensowne rozwiązanie. A DDD które jest oparte o encje ORM to juz w ogóle daje kompletnego raka, choć ja ogólnie nie przepadam za ORM zwłaszcza do selectów.

Jest jeszcze inny aspekt - jak z performance? Przy NoSQL trzeba pamiętac o tym żeby dana baza wspierała "joiny" przez dokumenty, bo inaczej znany i klasyczny problem - N + 1.

@anonimowy: zakładając proste CSV, które nie zawiera , w kolumnach przed nazwą użytkownika - awk -F=, '$2 == "nazwa"'. Jeśli będzie za wolno, to można użyć xsv.

Co do SQL vs NoSQL to moja zasada jest taka - biorę PostgreSQLa i używam tak długo aż nie okaże się, że skala jest za duża i wtedy rozważam coś innego. Jak na razie nigdy nie miałem potrzeby w 100% przejść do drugiego kroku. A jak już mam PostgreSQLa to często nie potrzebuję innych rozwiązań, bo mam:

• Zamiast MongoDB - JSONB
• Zamiast OpenTSDB/InfluxDB - BRIN, cstore, TimescaleDB, hll
• GIS - PostGIS
• Zamiast kolejek Redisa - LISTEN/NOTIFY
• Zamiast ElasticSearch - tsvector

Jak się okazuje, że z którejś funkcjonalności się "wyrosło" to można zastąpić, ale tak naprawdę to spotkałem się z tym tylko przy full-tekstowym szukaniu, gdzie zaczynało się opłacać używać zewnętrznego narzędzia. W przeciwnym wypadku łatwiej i szybciej było uzyskać wszystko w jednej DB.

EDIT:

Nie wiem czy ktoś już na to zwrócił uwagę, ale JOINy to nie są relacje w rozumieniu relacyjnych baz danych. Dodatkowo istnieją bazy danych relacyjne, które nie używają SQLa.

@scibi92: W pełni się zgadzam co do wzmianki o DDD i rozdzieleniu encji. Ja jedynie podzieliłem się obserwacją, nie zachęcałem do wiązania modelu domenowego z ORM (czyli de facto warstwą infrastruktury) .

Jest jeszcze inny aspekt - jak z performance? Przy NoSQL trzeba pamiętac o tym żeby dana baza wspierała "joiny" przez dokumenty, bo inaczej znany i klasyczny problem - N + 1.

Znów wracamy do punktu wyjścia, ponieważ jak już wcześniej wspominałem przy bazach dokumentowych podchodzi się inaczej do modelowania danych, a więc konieczność wykonywania joinów jest o wiele rzadsza. Wszystko zależy od przyjętej strategii- czy stosujemy CQRS czy też nie (tutaj joiny w zasadzie nie powinny występować, a jeśli występują często to robisz to źle), czy mamy task-based UI/API itp. Wtedy ograniczamy konieczność wykonywania joinów do minimum (lub nie mamy ich wcale). No ale załóżmy że na przekór wszystkim dobrym praktykom i zaleceniom nadal chcesz mieć bogate relacje między dokumentami. Wtedy tak, nieodzownym będzie konieczność użycia takiej bazy która pozwala robić joiny przy zapytaniach.

EDIT
A skoro już ktoś wcześniej przedstawiał zapytanie w MongoDB jako kontrargument, to bardzo proszę, ja przedstawiam złożone zapytanie z joinem w RavenDB, bez użycia biblioteki klienckiej która ma pełne wsparcie dla LINQ. Same "surowe" query:

from Orders as o
load o.Company as c
select {
    OrderId: id(o)
    CompanyName: c.Name,
    OrderItemsCount: o.Lines.length
}

Wszystko wykonane po stronie bazy danych, zwraca sam lekki obiekt (widok) z select. Lines to kolekcja w dokumencie Orders, i na tej kolekcji możemy wykonywać złożone "zapytania". o.Lines.length to tylko prosty przykład.

czy stosujemy CQRS czy też nie (tutaj joiny w zasadzie nie powinny występować, a jeśli występują często to robisz to źle)

Nie zgodzę się. Stosowanie lub nie JOINów jest zupełnie niezależne od tego czy używamy CQRS czy nie. Chciałbym zauważyć, że np. taki PostgreSQL wewnętrznie to jest CQRS + EventSourcing i jakoś nie jest to w sprzeczności z JOINami.

No ale załóżmy że na przekór wszystkim dobrym praktykom i zaleceniom nadal chcesz mieć bogate relacje między dokumentami.

Ale tego nie unikniesz. I niby od kiedy brak zależności pomiędzy danymi to "dobre praktyki"? Co mnie ominęło?

hauleth napisał(a):

Nie zgodzę się. Stosowanie lub nie JOINów jest zupełnie niezależne od tego czy używamy CQRS czy nie. Chciałbym zauważyć, że np. taki PostgreSQL wewnętrznie to jest CQRS + EventSourcing i jakoś nie jest to w sprzeczności z JOINami.

Ja piszę o aplikacjach z logiką biznesową a nie technicznej implementacji jakie stosują bazy danych. Tak więc śmiem nie zgodzić się z tym że ty się nie zgadzasz :) Używając CQRS aż prosi się zastosowanie dedykowanych modeli widoków. Oczywiście, z technicznego punktu widzenia możesz mieć CQRS i budować Query Side jako 1:1 replika Command Side, ja jednak będę polemizować że to nie jest najlepsze rozwiązanie w większości przypadków i lepiej wykorzystać zalety skoro już mamy CQRS i budować dedykowane modele po stronie Query.

Ale tego nie unikniesz. I niby od kiedy brak zależności pomiędzy danymi to "dobre praktyki"? Co mnie ominęło?

Chodzi oczywiście o to jak ktoś idzie w pełną normalizację. W przeciwnym razie używanie takiego rodzaju bazy mija się z celem. Pisałem o tym wcześniej w tym wątku więc zachęcam do poczytania.

Ja piszę o aplikacjach z logiką biznesową a nie technicznej implementacji jakie stosują bazy danych.

Dla osoby implementującej DB to właśnie to jest logika biznesowa. Na wyższym poziomie wygląda to dokładnie tak samo - masz strumień danych, z których następnie budujesz widoki w sposób, który będzie pozwalał wydajnie i szybko robić zapytania. Jak na moje to wygląda identycznie z wysokiego poziomu. No i logicznie będziesz miał joiny, bo nie zawsze wszystko jesteś w stanie zdenormalizować lub nie ma to absolutnie żadnego sensu.

śmiem nie zgodzić się z tym że ty się nie zgadzasz

Bo wiesz lepiej niż ja co myślę.

Używając CQRS aż prosi się zastosowanie dedykowanych modeli widoków

Tak, czyli tabeli i widoków z RDBMS.

budować Query Side jako 1:1 replika Command Side, ja jednak będę polemizować że to nie jest najlepsze rozwiązanie w większości przypadków i lepiej wykorzystać zalety skoro już mamy CQRS i budować dedykowane modele po stronie Query.

I dokładnie to tak działa, ale nie ma tutaj specjalnie różnicy czy będziesz to składował tak, że JOINów będzie się używać lub nie. To nie ma najmniejszego sensu co piszesz.

Chodzi oczywiście o to jak ktoś idzie w pełną normalizację. W przeciwnym razie używanie takiego rodzaju bazy mija się z celem. Pisałem o tym wcześniej w tym wątku więc zachęcam do poczytania.

Dalej się nie zgodzę, bo nawet jeśli denormalizację się robi, to rzadko kiedy w 100%. Najczęściej masz formę pośrednią, którą można uzyskać w bazach SQLowych np. poprzez zmaterializowane widoki.

hauleth napisał(a):

Dla osoby implementującej DB to właśnie to jest logika biznesowa. Na wyższym poziomie wygląda to dokładnie tak samo - masz strumień danych, z których następnie budujesz widoki w sposób, który będzie pozwalał wydajnie i szybko robić zapytania. Jak na moje to wygląda identycznie z wysokiego poziomu. No i logicznie będziesz miał joiny, bo nie zawsze wszystko jesteś w stanie zdenormalizować lub nie ma to absolutnie żadnego sensu.

Nie no wiem że to logika biznesowa dla osoby implementującej DB, chodziło mi bardziej o aplikacje typu enterprise. Mea culpa

Bo wiesz lepiej niż ja co myślę.

Wcale tak nie twierdzę, nie wiem po co ta uszczypliwość.

Używając CQRS aż prosi się zastosowanie dedykowanych modeli widoków
Tak, czyli tabeli i widoków z RDBMS.

No i właśnie nie, bo dedykowanych widoków (tabel). Raz jeszcze podkreślę- nie twierdzę że zawsze należy unikać joinów w CQRS i RDBMS, ale tak- twierdzę że należy je ograniczać. O czym więcej za chwilę...

budować Query Side jako 1:1 replika Command Side, ja jednak będę polemizować że to nie jest najlepsze rozwiązanie w większości przypadków i lepiej wykorzystać zalety skoro już mamy CQRS i budować dedykowane modele po stronie Query.

I dokładnie to tak działa, ale nie ma tutaj specjalnie różnicy czy będziesz to składował tak, że JOINów będzie się używać lub nie. To nie ma najmniejszego sensu co piszesz.

Ma sens, tyko chyba nie rozumiesz o co mi chodzi albo zwyczajnie zakładasz że w CQRS chodzi o oddzielenie jednej bazy od drugiej. Weźmy taki przykład- stosujeszCQRS, masz dwie bazy- jedną od zapisów (Command) i jedną od zapytań (Queries). Zakładając że masz kanoniczną aplikację zarządzania zamówieniami online i używasz RDBMS:

• Po stronie command masz normalizację
• Po stronie Query tworzysz dedykowane widoki. Nie w zrozumieniu widoków w SQL, tylko widoki w sensie tabele. Np. widok dedykowany podsumowaniu zamówienia zawierający cenę, ilość produktów w zamówieniu, najdroższy produkt w zamówieniu i najtańszy (specjalnie używam prymitywnego przykładu, żeby nie było). Wszystko w jednej tabeli, rekord zapisany w momencie składania zamówienia i gotowy do użytku. Kiedy przychodzi do zapytania bazy o widok zamówienia dla zamówienia XYZ, baza po prostu wyciąga gotowy rekord. Nie ma tutaj dodatkowych obliczeń bo wszystko jest już przygotowany na obsłużenie konkretnego widoku w aplikacji. Dla czego? Bo dziś przechowywanie takich gotowych danych jest tanie, więc skoro możemy to mieć gotowe i od razu zwrócić kiedy zajdzie taka potrzeba, to czemu nie.

Daruj sobie komentarze że coś co piszę nie ma sensu. Może dla Ciebie nie ma, ale nie moja wina jeśli nie miałeś okazji pracować przy takich systemach.

Dalej się nie zgodzę, bo nawet jeśli denormalizację się robi, to rzadko kiedy w 100%. Najczęściej masz formę pośrednią, którą można uzyskać w bazach SQLowych np. poprzez zmaterializowane widoki.

Ale przecież ja o tym pisałem wielokrotnie że przy NoSQL i szczególnie dokumentach- ani nie stosuje się pełnej normalizacji, ani pełnej denormalizacji. I kilkakrotnie były moje wypowiedzi przekręcane. Jeśli pisałem że nie stosuje się pełnej normalizacji to ktoś to interpretował że wszystko się denormalizuje i "olaboga, jak później robić updaty na wielu dokumentach kiedy jeden dokument się zmienił?!!!!!". A kiedy pisałem że właśnie nie robi się również pełnej denormalizacji to "olaboga, to przecież masz to samo co w SQL bo musisz joiny robić!!!!!!". No i jak tu rozmawiać?

Obecnie porównywania mają w sobie tyle prawd i rozsądku co walka łyżek z widelcami.. co ciekawe wyszła z tego niezła zadyma xD

Prawda jest taka, że sporo zależy od potrawy :D, częściowo też od kultury np w krajach azjatyckich dominują pałeczki, a w szpitalu można zaskoczyć się piciem zupy przez słomkę np. w przypadku urazu żuchwy.

Nawet człowiek, który zmuszony jeść gołymi rękami wyjdzie cało z tej niedorzecznej sytuacji więc jakie znacznie ma to co jest lepsze? Światek IT zwykle komplikuje to co oczywiste, zwłaszcza jeśli wchodzą do tego czyjeś ograniczające przekonania dotyczące jego ulubionych zabwek i bum bam mamy znowu zadymę. To tylko pokazuje jak nisko bądź płytko patrzymy.

W przypadku konsumpcji trzeba patrzeć nie tam gdzie sztućce, lecz na sposób, który zapewni nam jedzenie. Jak mamy jedzenie to problem rozwiązany. Wtedy jak komuś odwali to może nawet pozwolić sobie na to jeść kiełbasę przy użyciu łyżki, proszę bardzo tu droga wolna i możesz stać się pionierem :D W przypadku baz jest nie inaczej. Projekt ma być odpowiedzią biznesu, która robi wartość i poprzez sprzedaż kasuje klientów, chodzi o zysk, coraz większy zysk, inaczej naprawdę nie wiem po co pchać się w to wszystko. Emocje? Psychicznie wyjdziesz lepiej jak założysz swój własny magiczny ogród czy tam w wersji startupowej ogródek.

Wróćmy do projektu, mianowicie jak projekt zacznie się zwracać wtedy zmiany i nowe wyzwania są nieuniknione. Wtedy można zmienić bazy do woli, można robić hybrydy i pisać własne potwory, jaki to jest problem gdy stać firmę na to wszystko? W końcu dane to dane, można je przełożyć z jednej bazy do drugiej, co więcej nie chodzi tu tylko o bazy. Takim sposobem można przepisać wszystko - pełen czad, ilość ekscytujących wrażeń nieskończona. Można wiele, o ile wcześniej odrobi się życiowe lekcje ogarniania rzeczywistości.

Myśle, że ludzie w IT mają dwa razy baziej zaciśnięte klapki na oczach w przeciwieństwie do innych osób, i że próbują poprzez narzędzia opisywać swoje CV, a potem życie i lub wpływ tych narzędzi na jego sens, akurat w CV jakoś trzeba się wyróżniać, zwłaszcza w dobie gdy coraz więcej juniorów napływa. W wątku brakuje mi tylko benchmarków wbijące w glebę inne podbazy, jakieś uśmiechnięte twarze zgarbionych pracoholików i budzi się w nas wiara, wiara sukcesy z nadbazą - jesteśmy lepsi to nam ludziom ze światka IT, nadaje nam wartość, nową siłę - mamy zajawkę, i promocją niebanalnego rozwoju, a także zapowiedź niezwykłych wakacji - wakacji z bazą sql/nosql xD

Dla osób, które nadal zastanawiają się po której stronie jestem. SQL czy NoSQL mówię wprost. Mogę dane trzymać nawet w kiblu, o ile to zwiększy sprzedaż - i piszę to całkowicie poważnie. W tym wszystkim zwyczajnie chodzi o kasę, nie o modę czy metodę, chodzi o kasę, która w odróżnieniu od wszystkich zabawek robi jednak różnicę.