Przetwarzanie danych po stronie bazy, czy w aplikacji?

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

Rejestracja: 3 lata temu

Ostatnio: 22 godziny temu

Lokalizacja: PL

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

Rejestracja: 8 lat temu

Ostatnio: 5 godzin temu

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

Rejestracja: 5 lat temu

Ostatnio: 3 minuty temu

Lokalizacja: Poznań

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

Rejestracja: 9 lat temu

Ostatnio: 49 sekund temu

Lokalizacja: Grudziądz/Bydgoszcz

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 :)


It's All About the Game.
W sumie słuszna uwaga! - Belka 2019-07-31 21:15

Pozostało 580 znaków

2019-07-31 21:11

Rejestracja: 3 lata temu

Ostatnio: 22 godziny temu

Lokalizacja: PL

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

Rejestracja: 9 lat temu

Ostatnio: 49 sekund temu

Lokalizacja: Grudziądz/Bydgoszcz

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.


It's All About the Game.

Pozostało 580 znaków

2019-07-31 22:11
Moderator Kariera

Rejestracja: 2 lata temu

Ostatnio: 42 minuty temu

Lokalizacja: Poznań

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 ;)


Naczelny forumowy hejter Apple

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

Rejestracja: 5 lat temu

Ostatnio: 3 minuty temu

Lokalizacja: Poznań

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
Moderator

Rejestracja: 12 lat temu

Ostatnio: 11 godzin temu

Lokalizacja: Wrocław

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
Moderator

Rejestracja: 16 lat temu

Ostatnio: 2 minuty temu

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

Rejestracja: 3 lata temu

Ostatnio: 22 godziny temu

Lokalizacja: PL

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

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