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-07-31 20:40
1

Tutaj chyba nie ma jednoznacznej odpowiedz, jeżeli dane nie są wrażliwe i zabierają sporo CPU to lepiej przetworzyć je po stronie użytkownika(mam na myśli mało danych dużo obliczeń)
W większości przypadków jednak mamy do czynienia z prostymi zapytaniami i w takiej sytuacji lepiej wysłać jak najmniej danych, lepiej wykonać filtrowania po stronie serwera.

Jeżeli chodzi czy przetwarzać dane po stornie java czy DB to zdecydowanie DB. Dobrze zbudowane zapytanie jest dużo szybsze od java.

edytowany 1x, ostatnio: xxx_xx_x, 2019-07-31 20:41

Pozostało 580 znaków

2019-07-31 20:50
1

Dużo zależy, jakie to przetwarzanie i jaka struktura bazy (a raczej, to struktura bazy powinna być planowana jakoś  pod to jak się będzie tego używało potem).

Generalnie, najlepiej sprawdzić oba rozwiązania jakimiś testami wydajnościowym i zobaczyć.


Spring? Ja tam wole mieć kontrole nad kodem ᕙ(ꔢ)ᕗ
Haste - mała biblioteka do testów z czasem.

Pozostało 580 znaków

2019-07-31 21:10
3

Bierz pod uwage że dziś możesz mieć 10 rekordów a za kilka miesiący 100k, jeśli chcesz fltrować samemu po tych 100k to zaraz ci pamięci zabraknie :)

W sumie słuszna uwaga! - Belka 2019-07-31 21:15

Pozostało 580 znaków

2019-07-31 21:11
0
danek napisał(a):

Dużo zależy, jakie to przetwarzanie i jaka struktura bazy (a raczej, to struktura bazy powinna być planowana jakoś  pod to jak się będzie tego używało potem).

Generalnie, najlepiej sprawdzić oba rozwiązania jakimiś testami wydajnościowym i zobaczyć.

W praktyce chodzi mi o operacje typu wyciąganie z bazy jakiejśtam ilości obiektów, które powiedzmy mają z 10 pól, przy zapytaniu do bazy wybieram dość ogólnie parę warunków, natomiast później wykonuje jeszcze kilka filtrów na streamie zrobionym z listy wyników. Szczerze? Robię to z tego powodu, że zapomniałem jak kleić jakieś sensowniejsze zapytania niż SELECT FROM cośtam WHERE (NOT) coś = coś2 AND coś3 > coś4. Właśnie sobie serwuję przypomnienie SQLa i naszło mnie na takie przypomnienia.

Pozostało 580 znaków

2019-07-31 21:16
2

Po nałożeniu odpowiednich indexów i struktury bazy, zapytanie będzie w przeważającej większości wydajniejsze. Możesz sobie sam napisać benchmark, zwykły pomiar szybkości przetwarzania + wykorzystania pamięci.

Pozostało 580 znaków

2019-07-31 22:11
3

Pytanie jest inne - zastanów się, jakie są szanse, że Ty - jako samodzielny programista - będziesz w stanie zaprojektować system filtrowania/szukania tak samo wydajny (albo może nawet lepszy), niż silnik SQL, który jest na rynku przez kilkanaście/kilkadziesiąt lat, testowany na milionach serwerów, dedykowany do przechowywania i wyszukiwania danych oraz tworzony przez ogromną grupę osób zajmujących się tym zawodowo ;)


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
edytowany 1x, ostatnio: cerrato, 2019-08-01 11:37
Pokaż pozostałe 4 komentarze
Hehe, starszy od ADABASa :) - Marcin.Miga 2019-08-02 08:53
Jeszcze chwila i Cię zdelegalizują. Musisz być ostrożny ;) - cerrato 2019-08-02 08:54
Jeszcze chwila i będę pod konserwatora zabytków podlegał :) - Marcin.Miga 2019-08-02 08:59
i nawet makeup bez jeg ozgody nie będziesz mógł sobie zrobić. Przerąbane... - cerrato 2019-08-02 09:00

Pozostało 580 znaków

2019-07-31 22:34
1

I jeszcze dodatkowa kwestia, czy chcesz trzymać logikę biznesową w SQLach ;) Przy prostych filtrach to jeszcze da radę, jakieś bardziej skomplikowane rzeczy to już zaczyna się problem np z testowaniem


Spring? Ja tam wole mieć kontrole nad kodem ᕙ(ꔢ)ᕗ
Haste - mała biblioteka do testów z czasem.

Pozostało 580 znaków

2019-08-01 00:43
2

Wczytywanie połowy bazy do pamięci, a następnie filtrowanie i projekcja po stronie aplikacji jest złą praktyką i praktycznie zawsze złym pomysłem.

danek napisał(a):

I jeszcze dodatkowa kwestia, czy chcesz trzymać logikę biznesową w SQLach ;)

Nie musi trzymać logiki biznesowej w SQL. Istnieją narzędzia, które pozwalają wygenerować zapytanie SQL i zwrócą kolekcję odfiltrowanych i zmapowanych obiektów.


"HUMAN BEINGS MAKE LIFE SO INTERESTING. DO YOU KNOW, THAT IN A UNIVERSE SO FULL OF WONDERS, THEY HAVE MANAGED TO INVENT BOREDOM."
edytowany 1x, ostatnio: somekind, 2019-08-01 00:43
Podobno można używać client side evaluation jako odciążnika bazy, bo "łatwo" można dodawać kolejne instancje aplikacji, zatem niekoniecznie zła praktyka. - WeiXiao 2019-08-01 01:26
Przy jakiej skali to zaczyna wyprzedzać bazę? - somekind 2019-08-01 10:23
nie wiem, wypadałoby to sprawdzić. - WeiXiao 2019-08-01 18:16
Bo coś mi mówi, że to nie jest ten przypadek. - somekind 2019-08-02 01:58

Pozostało 580 znaków

2019-08-01 09:49
2

Jeśli chodzi o filtrowanie to jak najbardziej lepiej po stronie bazy. Ale ABSOLUTNIE nie wrzucać tam logiki i robić jakichś procedur, bo ugryzie cię to w dupę i to bardzo mocno. Testowalność takich rzeczy jest zerowa, plus vendor lock over 9000.


Masz problem? Pisz na forum, nie do mnie. Nie masz problemów? Kup komputer...
Pokaż pozostałe 7 komentarzy
Ale doczytaj dalej. Jeżeli masz dane relacyjne, to po co chciałbyś migrować na nosql? rozumiem część systemu, ale np. cały? - WeiXiao 2019-08-02 00:12
A kto mówi o migrowaniu? Ale aplikacje się rozwija, dochodzą nowe funkcjonalności i może nagle potrzeba ci key-value store, albo fulltext index albo graph search albo event stream? Jak cała logika twojej aplikacji siedzi w bazie to możesz sobie najwyżej pomarzyć o dodaniu czegoś takiego, bo nie ma jak tego zintegrować. - Shalom 2019-08-02 00:14
to jest case dependent, nie ma odpowiedzi. - WeiXiao 2019-08-02 00:17
Albo ktoś stwierdził, że wszystko i tak siedzi na SQLu, wiec nie ma co ukrywać tego faktu i wysilać się na jakieś abstrakcje i reguły, przecież do każdego miejsca w kodzie można wrzucić jakaś adnotacje z HQLem i będzie działać - hcubyc 2019-08-02 00:18
Widywałem systemy z logika w bazie co je stosowało w rozwoju i migracji na inny silnik. Projekty które trwają kilkanaście lub kilkadziesiat lat czasami się jednak migruje. Logika w bazie to najgorsze gowno. Baza jest stworzona do danych - nie do logiki a poza trudna migracja jest jeszcze skrzynia innych powodów. - somedev 2019-08-06 06:01

Pozostało 580 znaków

2019-08-01 09:59
0
Shalom napisał(a):

Jeśli chodzi o filtrowanie to jak najbardziej lepiej po stronie bazy. Ale ABSOLUTNIE nie wrzucać tam logiki i robić jakichś procedur, bo ugryzie cię to w dupę i to bardzo mocno. Testowalność takich rzeczy jest zerowa, plus vendor lock over 9000.

Czyli - biorąc po lupę bardzo prosty przykład - lepiej po stronie bazy wyszukać wszystkie wypłaty danego pracownika, ale np. zsumować je wszystkie lepiej po stronie aplikacji? Bo w sumie takie sumowanie to już jest jakaś (biedna, bo biedna ale zawsze jakaś) logika. Dobrze rozumiem?

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

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