Czy normalizacja naprawdę szkodzi wydajności w witrynach o wysokim natężeniu ruchu?

Projektuję bazę danych i chciałbym normalizować bazę danych. W jednym zapytaniu dołączę około 30-40 tabel. Czy to zaszkodzi wydajności strony internetowej, jeśli stanie się kiedyś bardzo popularne? To będzie główne zapytanie i będzie się nazywać w 50% przypadków. Inne zapytania, do których dołączę, dotyczą dwóch tabel.Czy normalizacja naprawdę szkodzi wydajności w witrynach o wysokim natężeniu ruchu?

Mam teraz wybór, aby normalizować lub nie normalizować, ale jeśli normalizacja stanie się problemem w przyszłości, być może będę musiał przepisać 40% oprogramowania i może to zająć dużo czasu. Czy w tym przypadku normalizacja naprawdę boli? Czy powinienem denormalizować teraz, kiedy mam czas?

Źródło

2010-04-24 Luke101

Nie powinieneś ryzykować tak masowego ponownego wpisywania (40% twojego) kodu. Jeśli zaczniesz normalizować, ale z widokami, aby zapewnić abstrakcje niezbędne dla większości kodu ... to powinno to zapobiec większości zmian w kodzie, w przypadku gdy potrzebujesz denormalizacji do schematu, który twoje widoki przedstawiają jako warstwa abstrakcji. –

Pamiętaj o obciążeniu (jeśli chodzi o ilość pracy) związanym z aktualizacją zdenormalizowanych tabel - jeśli zmienisz adres klienta, zamiast zmieniać go w jednym miejscu, musisz teraz przeskanować każdy wiersz w kiedykolwiek zdenormalizowanej tabeli, aby zmienić to. Może widok jest najlepszą opcją, a jeśli to nadal jest zbyt wolne, przydziel więcej zasobów sprzętowych do bazy danych. – slugster

Chciałbym wiedzieć, dlaczego potrzebujesz przede wszystkim 30-40 stolików - i dlaczego te muszą być połączone. Nie wydaje mi się to właściwe, więc chciałbym, abyś wyjaśnił, co robią tabele. –

cytuję: "normalizować poprawności, denormalize dla prędkości - i tylko wtedy, gdy to konieczne"

odsyłam do: In terms of databases, is "Normalize for correctness, denormalize for performance" a right mantra?

HTH.

Źródło

2010-04-24 00:13:54 Sunny

+1. Nie normalizujesz bazy danych - _always_ start z 3NF. Wróć do niższych poziomów dla prędkości, jeśli, _ i tylko if_, staje się konieczne. I upewnij się, że rozumiesz konsekwencje i rozwiązania. Istnieją sposoby na złagodzenie problemów spowodowanych przez denormalizację (wyzwalacze, kolumny obliczeniowe i tak dalej). Zwróć też uwagę na YAGNI :-) – paxdiablo

Czy uważasz, że 30-40 tabel nie będzie stanowić problemu? Ponadto, jeśli normalizacja staje się problemem, czy można dodać lepszy sprzęt, aby zrekompensować koszty normalizacji? – Luke101

@Luke: nie, może to być problem z dołączeniem do 40 tabel, w którym to momencie powinieneś rozważyć denormalizację (ale dopiero po pojawieniu się problemu, nie w oczekiwaniu na problem, który może nie istnieć - zmierz, nie zgaduj). Ale byłbym bardzo zainteresowany schematem 3NF, który wymagałby sprzężenia z wieloma tabelami. Z mojego doświadczenia wynika, że nigdy nie spotkałem się z taką sytuacją. Być może, gdybyś dodał więcej szczegółów na temat tego aspektu, moglibyśmy lepiej zrozumieć i zaoferować bardziej ukierunkowane porady. – paxdiablo

Nie dokonuj wczesnych optymalizacji. Denormalizacja nie jest jedynym sposobem na przyspieszenie witryny. Strategia buforowania jest również bardzo ważna i jeśli zapytanie o 30-40 tabel ma dość statyczne dane, buforowanie wyników może okazać się lepszą optymalizacją.

Należy również wziąć pod uwagę liczbę zapisów do liczby odczytów. Jeśli robisz około 10 odczytów dla każdej wstawki lub aktualizacji, możesz powiedzieć, że dane są dość statyczne, dlatego powinieneś buforować je przez pewien okres czasu.

Jeśli zakończysz denormalizowanie swojego schematu, twoje zapisy również staną się droższe i spowolnią również.

Naprawdę przeanalizuj swój problem, zanim podejmiesz zbyt wiele optymalizacji, a także poczekaj, aby zobaczyć, gdzie są wąskie gardła w systemie, ponieważ możesz być zaskoczony, co należy zoptymalizować w pierwszej kolejności.

Źródło

2010-04-24 00:19:54 jamesaharvey

Tabele 30-40 nie będą wcale statyczne. W normalny dzień spodziewamy się około 1000 aktualizacji i wstawek. – Luke101

Wykonanie 1000 aktualizacji dziennie to mniej niż 1 na minutę. Nazwałbym to dość statycznie. – Gabe

Uzgodnione. I zakładając, że robisz więcej czytań niż piszesz, strategia buforowania okaże się bardzo ważna. – jamesaharvey

Gdy wydajność jest problemem, są zazwyczaj lepsze alternatywy niż denormalizacji:

Tworzenie odpowiednich indeksów i statystyk dotyczących zajętych stolików
buforowanie
zmaterializowane perspektywy (widoki indeksowane w MS SQL Server)
Posiadanie denormalizowanej kopii tabel (używanych wyłącznie dla zapytań, które ich potrzebują), oprócz standardowych tabel używanych w większości przypadków (wymaga napisania kodu synchronizacji, który może być uruchamiany jako tri gger lub zaplanowana praca w zależności od wymaganej dokładności danych)

Źródło

2010-04-24 00:34:22 ckarras

Normalizacja może zaszkodzić wydajności. Jednak nie ma powodu do przedwczesnego denormalizowania.

Zacznij od pełnej normalizacji, a następnie zobaczysz, czy masz jakiekolwiek problemy z wydajnością. Przy tempie, które opisujesz (1000 aktualizacji/wstawek dziennie), nie sądzę, że napotkasz problemy, chyba że stoły są ogromne.

Nawet jeśli istnieje mnóstwo opcji optymalizacji bazy danych (indeksy, przygotowane procedury składowane, zmaterializowane widoki, ...), z których można korzystać.

Źródło

2010-04-24 00:45:19 Foxfire

Może brakuje mi czegoś tutaj. Jeśli jednak Twoja architektura wymaga od 30 do 40 tabel w jednym zapytaniu, to zapytanie jest głównym zastosowaniem witryny, więc masz większe problemy.

Zgadzam się z innymi, nie przedwcześnie optymalizuj witryny. Należy jednak zoptymalizować architekturę tak, aby uwzględniała główny przypadek użycia. 40 połączenie tabeli dla zapytania uruchomionego w ponad 50% czasu nie jest zoptymalizowane IMO.

Źródło

2010-04-24 02:47:59

Czy normalizacja naprawdę szkodzi wydajności w witrynach o wysokim natężeniu ruchu?

Odpowiedz

Powiązane problemy