Kiedy rozmiar połączenia z bazą danych jest droższy niż częstotliwość połączeń?

Question

Czy ktoś może mi dać względny pomysł, kiedy bardziej sensowne jest wielokrotne trafianie w bazę danych dla małych wyników zapytań a buforowanie dużej liczby wierszy i odpytywanie o to?

Na przykład, jeśli mam zapytanie zwracające 2000 wyników. A potem mam dodatkowe zapytania dotyczące wyników, które mogą zawierać 10-20 elementów, czy lepiej byłoby buforować wyniki 2000 lub trafić do bazy danych za każdym razem dla każdego zestawu 10 lub 20 wyników?

Answer 1

Inne odpowiedzi tutaj są poprawne - RDBMS i twoje dane są kluczowymi czynnikami. Jednak innym kluczowym czynnikiem jest to, ile czasu zajmie sortowanie i/lub indeksowanie danych w pamięci w porównaniu do bazy danych. Mamy jedną aplikację, w której, dla wydajności, dodaliśmy kod, aby pobrać około 10.000 rekordów do pamięci w pamięci DataSet, a następnie wykonać podzapytania. Okazuje się, że aktualizowanie tych danych i wybieranie podzbiorów jest wolniejsze niż pozostawienie wszystkich danych w bazie danych.

Moja rada: najpierw wykonaj najprostszy możliwy sposób, a następnie zrób profil i zobacz, czy musisz zoptymalizować wydajność.

Answer 2

To prawdopodobnie różni się od RDBMS do RDBMS, ale moje doświadczenie było takie, że ciągnięcie luzem jest prawie zawsze lepsze. W końcu będziesz musiał pobrać 2000 rekordów, więc równie dobrze możesz zrobić to wszystko naraz. A 2000 rekordów nie jest tak naprawdę dużą ilością, ale zależy to w dużej mierze od tego, co robisz.

Moja rada to profil i zobacz, co działa najlepiej. RDBMS może być podstępną bestią, a buforowanie może być równie trudne.

Answer 3

Rodzaj danych, które odsyłasz, wpływa również na decyzję. Nie chcesz buforować niestabilnych danych lub danych w poszukiwaniu potencjalnych aktualizacji, które mogą się zestarzeć.

Answer 4

To zależy od wielu rzeczy. Wymienię kilka punktów, które przychodzą do głowy:

• Jeśli masz aplikację internetową, która jest .NET buforowanie danych w kliencie, nie chce ciągnąć 2k wiersze.

• Jeśli masz usługę internetową, są one prawie zawsze lepsze Chunky niż Chatty ze względu na dodatkowe obciążenie XML w transporcie.

• W dość przyzwoicie znormalizowanej i zoptymalizowanej bazie danych, naprawdę powinno być bardzo mało razy, że trzeba wyciągnąć 2k wierszy na raz, chyba że robisz raporty.

• Jeśli podstawowe dane zmieniają się w szybkim tempie, należy naprawdę zachować ostrożność, zapisując je na środkowej warstwie lub w warstwie prezentacji, ponieważ to, co przedstawisz, będzie nieaktualne.

• Raporty (dowolne DSS) będą pobierać i chompować znacznie większe zbiory danych, ale ponieważ nie są interaktywne, denormalizujemy i pozwalamy im się bawić.

• W przypadku kaskadowych zrzutów i takich, techniki AJAX okażą się bardziej wydajne i efektywne.

Chyba nie daję ci jednej odpowiedzi na twoje pytanie. "To zależy" jest najlepsze, co mogę zrobić.

Answer 5

Ogólnie rzecz biorąc, opóźnienie w czasie podróży w sieci jest o kilka rzędów wielkości większe niż pojemność bazy danych do generowania i przesyłania danych do sieci oraz pojemność skrzynki klienckiej do korzystania z niej z połączenia sieciowego.

Ale spójrz na szerokości magistrali sieciowej (bity/s) i porównać go do średniej rundy Czas wyłączania dla połączenia bazy danych ...

Na 100BaseT Ethernet, na przykład jesteś około 12 Mb/sekundę transferu danych. Jeśli Twój średni czas podróży w obie strony wynosi 200 ms, wtedy Twoja magistrala może dostarczyć 3 MB w każdym 200 ms podróży w obie strony ..

Jeśli korzystasz z gigabitowej sieci Ethernet, ta liczba przeskakuje do 30 MB na podróż w obie strony ...

Więc jeśli podzielisz żądanie danych na dwie wycieczki, to jest to 400 ms, a każde zapytanie musiałoby mieć więcej niż 3Mb (lub 30Mb na gigibit), zanim to byłoby szybsze ...

Answer 6

"Chyba nie daję ci jednej odpowiedzi na twoje pytanie." To zależy "jest najlepsze, co mogę zrobić."

tak, "to zależy". Zależy to od zmienności danych, które mają być buforowane, i zależy to od poziomu "dokładności" i niezawodności, które są potrzebne do odpowiedzi generowanych na podstawie danych, które mają być buforowane.

Jeśli zmienność danych "bazowych" jest niska, to każde buforowanie, które wykonujesz na tych danych, ma większe prawdopodobieństwo, że pozostanie prawidłowe i poprawne przez dłuższy czas.

Jeśli "buforowanie - odporność na błędy" na wynikach, które zwracasz do użytkowników, wynosi zero procent, nie masz opcji.

Answer 7

Jeśli nie wystąpił duży problem z wydajnością (np. Bardzo utajone połączenie db), pozostawiłbym dane w bazie danych i pozwoliłbym db dbać o rzeczy dla ciebie. Wiele rzeczy są wykonywane efektywnie na poziomie bazy danych, na przykład

• poziomy izolacji (co się dzieje, gdy inne transakcje zaktualizować dane masz buforowanie)
• szybki dostęp za pomocą indeksów (db może być szybciej uzyskać dostęp do kilku wierszy, niż przeszukujesz pozycje w pamięci podręcznej, szczególnie jeśli dane już znajdują się w pamięci podręcznej db, tak jak w scenariuszu). dobrze lub czy "odświeżasz" wszystko od db)

Istnieje wiele potencjalnych problemów, które możesz napotkać, jeśli wykonasz własne buforowanie. Musisz mieć bardzo dobry powód do działania, zanim zaczniesz dbać o całą złożoność.

Tak, krótka odpowiedź: To zależy, ale jeśli nie masz dobrych powodów, to pachnie jak przedwczesna optymalizacja dla mnie.