Przetwarzanie danych po stronie bazy, czy w aplikacji?

Odpowiedz Nowy wątek
2019-07-31 20:24
0

Hej,

zacząłem się zastanawiać nad pewnym tematem. Otóż gdzie lepiej przetwarzać dane pobierane z bazy? Zauważyłem u siebie tendencję do wyciągania danych z bazy jakimś prostym zapytaniem, filtrując raczej po jednym, czy dwóch kryteriach, a następnie filtruję, zliczam, czy cokolwiek innego np. wrzucając listę w stream (Java) i operując na danych w aplikacji. Zacząłem się jednak zastanawiać co jest dobrą praktyką w takim przypadku. Czy lepiej napisać natywnie jakieś bardziej skomplikowane zapytanie do bazy i starać się jak najdokładniej przefiltrować dane po stronie DB do postaci najbliższej takiej, jaka mi jest potrzebna, czy własnie lepiej zrzucać tę odpowiedzialność na kod aplikacji. Jak to wygląda u was? Co jest lepszą praktyką?

Pozostało 580 znaków

2019-08-05 14:08
0

Obrabianie danych po stronie bazy danych ZAWSZE będzie zdecydowanie bardziej wydajne. Chyba, że mówimy o jakiś małych programikach z małą ilością danych, to może być różnie.

... chyba że mówimy o dużych ilosciach danych, to wtedy baza danych będzie dużo wolniejsza, bo nie da się jej zwykle wygodnie rozproszyć. No chyba że BigQuery albo AWS Athena to jest baza danych w twoim rozumieniu. Przy jakich danych pracowałes że dajesz takie sądy? 1TB? 10TB? 100TB? Pokaż mi która baza to ogarnia, poczekam. - Shalom 2019-08-05 15:47
Bazy danych są tak skonstruowane, żeby obrabianie danych było szybkie. Na pewno istnieją bazy, które kuleją pod tym kątem. Jednakże jeśli zapytania w bazie wykonują się wolniej niż analogiczny algorytm w aplikacji, prawie na pewno oznacza to źle zaprojektowaną bazę (w sensie klucze) albo problemy z SQL. - Juhas 2019-08-05 15:56
No tak było faktycznie, 50 lat temu. Słyszał o takich rzeczach jak map-reduce? Jak przetwarzanie rozproszone? Czym wg ciebie jest ta mityczna baza jak nie aplikacją? - Shalom 2019-08-05 16:17
A co to ma do rzeczy skoro dyskutujemy na temat: "przetwarzanie danych po stronie bazy, czy aplikacji biznesowej"? - Juhas 2019-08-05 16:42
Ma tyle do rzeczy że to zależy ile danych chcesz przetwarzać i w jaki sposób. Twierdzenie że baza jest zawsze lepsza jest równie prawdziwe jak dołożenie indeksu zawsze poprawia szybkość. Takie mity powtarzane przez wielu ludzi, a przez innych przyjmowane jako prawdy objawione bez chwili refleksji. - Shalom 2019-08-05 17:10
Panowie, ale po co te emocje? Chcesz przewalać 10TB danych, to użyj Sparka. Zgadzam się, że bazy danych to również aplikacje (surprise), jednak maja zoptymalizowany storage i algorytmy, aby „robić robotę”. Trzeba tylko wybrać odpowiednią pod swój case, może poeksperymentować z kilkoma. - Charles_Ray 2019-08-05 17:16

Pozostało 580 znaków

2019-08-07 09:28
0
Juhas napisał(a):

Obrabianie danych po stronie bazy danych ZAWSZE będzie zdecydowanie bardziej wydajne. Chyba, że mówimy o jakiś małych programikach z małą ilością danych, to może być różnie.

Oczywiście bzdura.

Bywa wydajne jak akurat podpasują indeksy i jest to typowe filtrowanie, agregowanie - pasujące do danych i danej bazy.
SQL / Bazy nie sa jezykami programowania ogólnego przeznaczenia i czasami, nawet w prostych przypoadkach sa tragicznie powolne.

Swego czasu przypadkiem udało mi się ośmieszyć kilka razu różne procedury oraclowe (PLSQL) , kiedy napisałem - zupełnie na wariata prosty naiwny algorytm w javie.
Sam się zdziwiłem. (wszelkiego rodzaju pętle LOOP. END LOOP zwykle nie wychodzą na zdrowie enginom bazodanowym).

Ogólnie jak komuś zależy na szybkości to po prostu najlepiej w ogóle bazy danych (głównie SQL) omijać szerokim łukiem to nie do szybkości służy. (Mimo, że może ktoś kiedyś zrobi wolfensteina 3d w SQLu...).
Większość algorytmów, dzięki którym bazy są szybkie jest też dostępna w popularnych jezykach programowania. Można też ich użyć w C#/Javie itp. (przykłady: https://github.com/npgall/cqengine , https://rosettacode.org/wiki/Hash_join)


Bardzo lubie Singletony, dlatego robię po kilka instancji każdego.
edytowany 7x, ostatnio: jarekr000000, 2019-08-07 09:38
Pokaż pozostałe 4 komentarze
Poza tym pytanie dotyczy obrabiania danych, a nie programowania. SQL służy do danych, a nie do stosowania jakiś finezyjnych algorytmów. - Juhas 2019-08-08 14:46
Ja jak najbardziej o obrabianiu danych. - jarekr000000 2019-08-08 15:11
OK, a co rozumiesz przez obrabianie danych? Bo może tu jest różnica. Mówiąc w temacie baz danych mam na myśli wszelakie filtrowanie, ewentualnie updatey z filtrowaniem. Nie mam na myśli stosowanie na tych danych jakiś wyrafinowanych algorytmów. Bo w takim przypadku faktycznie może być różnie. - Juhas 2019-08-09 10:40
Obrabianie danych to obrabianie danych. Można też powiedzieć przetwarzanie. W zasadzie każdym system informatyczny się tym zajmuje. Bazy danych też się czasem przydają do tego (ale nie tak często, jak są stosowane). - jarekr000000 2019-08-09 11:27

Pozostało 580 znaków

2019-08-11 08:33
1

Nawet zakładając, że baza danych ma wydajny model obliczeniowy do wykonania obliczeń, to trzeba uważać, aby jej nie zapchać. Zwykle dodanie CPU/RAM do bazy SQL jest trudne, a dodanie instancji aplikacji trochę prostsze. Jak kod aplikacji wywróci się z OutOfMemoryError, to skutki są mniej dotkliwe niż crash serwera bazy danych.

Pozostało 580 znaków

2019-08-11 10:48
0

Raczej są małe szanse, że baza się totalnie wychrzani. Jak będzie przeładowana to raczej będzie zamulać, plus może ubijać poszczególne zapytania/wywalać timeouty, ale samego silnika raczej to nie uwali.


That game of life is hard to play
I'm gonna lose it anyway
The losing card I'll someday lay
So this is all I have to say

Pozostało 580 znaków

2019-08-11 22:35
0

Mi to trochę przypomina sytuację przegięcia "nie wymyślania koła od nowa". System baz danych są na tyle wygodne , że sporo programistów przyzwyczaiła się do nich i nie potrafiłoby zaimplementować prostych algorytmów złączeń, które wykorzystują bazy, już nawet pomijając efektywność odczytów, zapisów i reprezentacji fizycznej danych.

Jakby systemy relacyjnych baz danych nie miały problemów ze skalowalnością, to nie byłoby w ostatnich latach takiego natłoku systemów przetwarzania dla dużych zbiorów danych, zapewniających dostępność na poziomie paru 9, rezygnujących z pewnych założeń co do spójności by być w stanie operować przy danych założeniach czy będących w stanie operować będąc rozproszonym w różnych centrach danych na całym świecie. To tylko kolejne aplikacje i jak się okazuje nie zawsze istnieje gotowe rozwiązanie, które pasuje idealnie.

edytowany 4x, ostatnio: nalik, 2019-08-11 22:48

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

1 użytkowników online, w tym zalogowanych: 0, gości: 0, botów: 1

Robot: CCBot