„Duża baza danych” to rzeczywiście mglista koncepcja. W odpowiedziach na to pytanie są już bardzo różne odpowiedzi i opinie. Niektóre podejścia do definiowania „małych”, „średnich” i „dużych” baz danych mogą mieć więcej sensu niż inne, ALE WTEDY w pewnym momencie uważam, że każda definicja jest właściwa, prawdziwa i ważna.
Niektóre definicje mają więcej sensu niż inne, ponieważ koncentrują się na różnych aspektach ważnych dla projektowania, programowania, użytkowania, konserwacji i administrowania bazą danych, a te różne aspekty są tym, co naprawdę ma znaczenie dla użytecznej bazy danych. Tak się po prostu składa, że na wszystkie te aspekty wpływa mgliste pojęcie „rozmiaru bazy danych”.
Czy to oznacza, że nie ma znaczenia, czy jesteś w stanie określić, czy dana baza danych jest duża, czy nie?
Zdecydowanie nie. Oznacza to, że będziesz stosować tę koncepcję w inny sposób, oceniając różne aspekty projektowe / operacyjne / administracyjne bazy danych. Oznacza to również, że za każdym razem ta koncepcja będzie mglista.
Na przykład: na strategię indeksu bazy danych (aspekt projektu bazy danych) ma wpływ liczba rekordów dla każdej tabeli (miara „rozmiaru”), rozmiar rekordu pomnożony przez liczbę rekordów (inna miara „rozmiaru”) oraz zapytanie Vs . Współczynnik operacji tworzenia / aktualizacji / usuwania (aspekt wykorzystania bazy danych).
Czasy odpowiedzi na zapytania są lepsze, jeśli indeksy są używane w tabelach z dużą liczbą rekordów. W zależności od charakteru klauzul WHERE, ORDER BY i agregacji rekordów możesz potrzebować kilku indeksów dla niektórych tabel.
Na operacje tworzenia, aktualizowania i usuwania ma negatywny wpływ wzrost liczby indeksów w tabelach, których dotyczy problem. Więcej indeksów dla dotkniętej tabeli oznacza więcej zmian, które RDBMS musi wykonać, poświęcając więcej czasu i zasobów, aby zastosować te zmiany.
Ponadto, jeśli system RDBMS poświęca więcej czasu na zastosowanie tych zmian, wówczas blokady są utrzymywane również przez dłuższy czas, wpływając na czas odpowiedzi innych zapytań wysyłanych do systemu w tym samym czasie.
Jak więc zrównoważyć ilość i wygląd swoich indeksów? Skąd wiesz, czy potrzebujesz dodatkowego indeksu i czy dodając ten indeks nie będziesz miał dużego negatywnego wpływu na czasy odpowiedzi na zapytania? Odpowiedź: Testujesz i profilujesz swoją bazę danych pod kątem obciążenia docelowego zgodnie z wymaganiami dotyczącymi obciążenia / wydajności i analizujesz dane profilowania w celu wykrycia, czy potrzebne są dalsze optymalizacje / przeprojektowanie / indeksy.
Różne strategie indeksu są wymagane dla różnych zapytań vs. Współczynniki tworzenia / aktualizowania / usuwania operacji. Jeśli baza danych jest bardzo obciążona zapytaniami, ale rzadko jest aktualizowana, wydajność całej aplikacji będzie lepsza, jeśli dodasz każdy indeks, który skraca czas odpowiedzi na zapytania. Z drugiej strony, jeśli baza danych jest stale aktualizowana, ale nie ma dużych operacji zapytań, wydajność będzie lepsza, jeśli użyjesz mniejszej liczby indeksów.
Istnieją oczywiście inne aspekty: projekt schematu bazy danych, strategia przechowywania, projekt sieci, strategia tworzenia kopii zapasowych, procedury składowane / wyzwalacze / itp. programowanie, programowanie aplikacji (w oparciu o bazę danych) itp. Na wszystkie te aspekty wpływają w różny sposób różne koncepcje „rozmiaru” (rozmiar rekordu, liczba rekordów, rozmiar indeksu, liczba indeksów, projekt schematu, rozmiar pamięci itp.).
Chciałbym mieć więcej czasu, bo ten temat jest fascynujący. Mam nadzieję, że ten mały wpis będzie dla Ciebie punktem wyjścia w tym fascynującym świecie SQL.