Wiele zapytań vs jedno duże zapytanie

Question

hej pytanie dotyczace wydajności oraz szybkości.

 

Jaka jest lepza praktyka dotyczace łączenia kodu php z sql?

Lepiej sotosować rozbudowane zapytania czy wiele zapytań mniejszych, które zwracają dane, po połączeniu, których otrzymam identyczny wyniki co z dużego zapytania?

Mam tu na myśli 11 joinów w dużym zapytaniu.

Answer 1

Nie ma uniwersalnej odpowiedzi na takie pytanie. Generalnie wiele zapytań do bazy to wiele połaczeń, wiele wątków na bazie... pytanie jaki jest czas wykonywania tego jednego dużego zapytania. Bo może się okazać, że np. to jedno leci w 300ms, a przy pojedynczych czas wykonania wszystkich sięgnie rzędu 500-600ms. To, że zapytanie jest krótkie to jedno, ale patrz na całość.

Trzeba też zastanowić się nad ewentualnym skalowaniem bazy, co będzie wtedy lepsze - więcej polączeń czy mniej, ale dłuższe zapytania.

No i w ogóle pytanie o jak dużych bazach i jakim ruchu mówimy, czy rozmawiamy tu o mikro bazie gdzie jest kilkadziesiąt czy kilkaset rekordów czy o BigData. Oraz o ruchu, czy jest to ruch rzędu kilku RPS czy kilku tysięcy RPS, bo to wszystko ma znaczenie.

Ale tak swoją drogą to jeśli potrzebujesz az 11 joinów to zastanowiłbym się nad strukturą tej bazy... Można porobić sobie np. widoki i z nich pobierać dane, a już baza będzie odpowiedzialna za ich aktualizację, porobić jakieś cache albo w ogóle zmienić strukturę.

Czasami nawet okazuje się, że bazy z tak dużą relacyjnością wcale jej nie potrzebują i można przejść na rozwiązania nierelacyjne, np. mongo, które jest bardzo szybkie.

Comments

Słyszałem o mogno jednakże, na jednym z artykułów, w wadach mongo napisane było, ze bardzo ciężko jest je zabezpieczyć  i wycieki danych z tego faktu są spore.

---

jak ktoś się nie zna to zepsuje każdą baze:) pracuję z bazami mongo gdzie mamy tysiace rps i tez i update i nie ma problemow. Kwestia odpowiedniego ustawienia, tak samo jak np. oracle. szczerze to widzę naprawde wiele zalet mongo i jestem bardzo zadowolony z tych baz.

---

Bardzo dziękuję za odpowiedź , ruszę w tym kierunku  :)

Answer 2

Ogólnie wydajniejsze jest "pozostanie w warstwie bazy danych" więc zapytanie większe. Nie bez powodu zalecenia architektury np. DDD, mówią o agregacji do specyfikacji zapytania i separacji przez repozytorium.

Comments

Nie zawsze, czasami w warstwie aplikacji lepiej jest zachować niektóre wyniki. Wg mnie nie znając całej architektury apki i wielkości ruchu, ilości wątków itp to nie można niż stanowczo polecać. Inne podejscie możesz mieć w mikro apce gdzie masz kilkanaście czy kilkadziesiąt requstow na sekundę,a inne w apce gdzie masz tysiące rps. Ponadto nie wiemy nic o innych zapytania, może mają one jakieś części wspólne, może w ogóle warto pozbyć się niektórych joinow itp itd. Teoria z książek to jedno, a praktyka to drugie.

---

Teoria z książek to jedno, a praktyka to drugie.

Wbrew pozorom to nie teoria. A samo zdanie to także nie argument (jeśli się bliżej przyjrzeć). Napisałem w pierwszym słowie jak widzisz "ogólnie". Kolega pytał przecież o ogólną wykładnię, więc ją dostał. Łamanie samej zasady owszem jest wykonywane ale przesłanki powinny być bardzo poważne i świadome. Odpowiedź w stylu "to nie takie proste", (w mojej ocenie) nie wnosi nic konstruktywnego. Oczywiście można zawsze tworzyć anemiczną domenę lub typowy CRUD bądź doprowadzić do patologicznego stosowania procedur wyzwalanych co będzie sklejało z warstwą persystencji. Problemy skalowalności/wydajności/dostępności/... w nietrywialnych architekturach nie powinny wpływać na model domeny a takie będą konsekwencje jeśli zapytania będą rozdrobnione z powodów technicznych (które sam opisałeś). Lepiej bardziej skomplikowane zapytania gromadzić w specyfikację i nie pozwalać na wpływ surowych SQL'owych zapytań na kod samej logiki aplikacji separując ją np. poprzez repozytorium (w końcu na SQL'u świat się nie kończy). Można także oczywiście te problemy obsługiwać przez inne style architektoniczne (CQRS, Microservice, Reactiv prg.. ). Ale jakiekolwiek nie będą możliwe jeśli.. "wyciek paradygmatu złączeń kartezjańskich" będzie obecny w domenie :)

Ww. podejście oczywiście obowiązuje do poważniejszych zastosowań. Możemy ustalić roboczo że dla takich dla których "książka zgadza się z praktyką". Inaczej będzie jeśli świadomie decydujesz o "bardzo wczesnej optymalizacji małego rozwiązania". Tylko że drut i sznurek to w mojej ocenie to nie jest "dobra praktyka" a zrobienie "szybko po małym koszcie... dziś" z (oby) świadomą decyzją że tak zrobimy. A jakże często jest to wynik nawarstwiania się reaktywnego rozwiązywania problemów.