Wiele dostępów do bazy danych czy jeden ogromny dostęp?

Jakie jest lepsze podejście, jeśli chodzi o wydajność i optymalne wykorzystanie zasobów: wielokrotny dostęp do bazy danych za pośrednictwem AJAX w celu uzyskania tylko potrzebnych informacji, gdy jest to potrzebne, lub wykonanie jednego dostępu w celu odzyskania obiektu zawierającego wszystkie informacje, które mogą być potrzebne , z dużym prawdopodobieństwem, że nie wszystko jest rzeczywiście potrzebne?

Wiem, jak przeprowadzić analizę porównawczą rzeczywistych zapytań, ale nie wiem, jak przetestować, co jest najlepsze, jeśli chodzi o wydajność bazy danych, gdy tysiące użytkowników uzyskuje dostęp do bazy danych jednocześnie i jak działa pula połączeń.

Nie ma jednej poprawnej odpowiedzi na to; jak każda optymalizacja, zależy w dużej mierze od kontekstu / użycia.

Należy jednak wziąć pod uwagę następujące zasady:

x
+: Data is stable / static
-: Data is dynamic / volatile

y
+: Data is frequently used
-: Data is infrequently used

++: fetch large chunks in the fewest number of fetches 
    and persist the data as long as possible within tolerances for staleness.

+-: do what is expedient to the logic & usage; if it is convenient to 
    fetch / calc as needed do so, if it is convenient to pre-fetch and 
    persist then do so. Seek to optimize only if absolutely necessary.

-+: fetch / calc as needed; but if optimization is required consider 
    pre-fetching or pre-calculating if possible, or negotiate a tolerance 
    for less than real time accuracy to reduce volatility.

--: fetch / calc as needed and don't worry about it further unless a 
    specific case is unacceptably expensive; if so see -+.

Pamiętaj o pierwszej zasadzie optymalizacji: mierz, nie zgaduj . Wypróbuj oba, oprzyrząduj je za pomocą kodu stopera i zobacz, co trwa dłużej.

Pamiętaj też o starym dowcipie, że „są tylko dwa trudne problemy w informatyce: unieważnienie pamięci podręcznej i dobre nazywanie rzeczy”. Jeśli wyciągniesz wszystko z bazy danych od razu i zatrzymasz w pamięci, będziesz mieć pamięć podręczną. A teraz masz nowy problem: za każdym razem, gdy coś się zmienia w dowolnym miejscu w systemie , musi dokonać tej samej zmiany w dwóch miejscach: bazie danych i pamięci podręcznej. Jeśli masz więcej niż jeden serwer rozmawiający z bazą danych lub wiele interfejsów API, które zmuszają serwer do modyfikowania danych, może to być bardzo trudne bardzo szybko.

Nie ma ŻADNEGO srebrnego rozwiązania dla tego pytania. Myślę, że musisz WYPRÓBOWAĆ możliwe kompromisy i dostroić serwer (y), aby osiągnąć jak najlepszy efekt.

Pierwszy punkt: zanim zaczniesz wprowadzać jakiekolwiek ulepszenia, musisz USTAWIĆ swój bieżący test porównawczy wydajności , zmierzyć go i przyjąć jako punkt odniesienia w porównaniu możliwych rozwiązań w celu jego poprawy.

Po drugie, należy monitorować użycie aplikacji . Sposób, w jaki aplikacja jest wykorzystywana przez użytkowników końcowych. Zmniejszenie zwracanych nieprzetworzonych danych niepotrzebnych użytkownikom końcowym może zaoszczędzić wiele cennych zasobów serwerowych . Na przykład: nie ma sensu zwracać 5000 rekordów, gdy użytkownicy są zainteresowani pierwszymi 50.

Trzeci punkt: musisz zrozumieć częstotliwość połączeń i możliwe implikacje. Na przykład: jeśli większość wywołań to zapytania do tabeli wartości, prawdopodobnie prawdopodobnie stworzyłbyś infrastrukturę do buforowania tych połączeń . Innymi słowy, jeśli dane nie zmieniają się często, rozważ opcję buforowania. Oczywiście minimalizacja liczby połączeń zawsze powinna przyczynić się do zwiększenia wydajności.

Zdobycie wszystkiego naraz zapewni lepszą wydajność, chyba że „wszystko” obejmuje takie obiekty jak BLOB lub podobnie duże obiekty danych. Narzut związany z wydajnością do szeregowania wszystkiego, przesuwania go po kablu, a następnie deserializacji na drugim końcu jest dość znaczny, z dużym opóźnieniem sieci. Pamięć jest tańsza niż przepustowość sieci i prawdopodobnie pozostanie na jakiś czas jeszcze. Twoja jedyna prawdziwa odpowiedź będzie pochodzić z testu porównawczego, ale jeśli tylko próbujesz ocenić jeden nad drugim, to właśnie w ten sposób się pochylę.

Jeśli podejmujesz decyzję architektoniczną, REST jest jedną z opcji. Dzięki REST zawsze żądasz zasobu wiele razy, tzn. Nie wysyłasz żądania uzyskania 2 obiektów, ponieważ każdy obiekt ma swój własny adres URL. Problem wydajności związany z robieniem tego stylu prawdopodobnie zostanie rozwiązany, gdy wyjdzie HTTP / 2.0. W przeciwnym razie po prostu zoptymalizuj, aby uczynić to tak szybko, jak to możliwe. Wiele firm robi to w ten sposób.