Krótka odpowiedź
Tak , możesz napisać znaczący punkt odniesienia dla badanego przypadku, jeśli zrobisz to ostrożnie, i zrozum, że jeśli jest to istotne dla konkretnego przypadku, może nie być tak w innych przypadkach. Dotyczy to również porównywania baz danych tego samego typu (relacyjna baza danych vs. inna relacyjna baza danych) lub baz różnych typów.
Nie , nie można napisać testu porównawczego, który w magiczny sposób udowodni, że konkretna baza danych jest lepsza niż inna w każdym przypadku dla każdej aplikacji.
Długa odpowiedź
Zdecydowanie można powiedzieć, że „przejście z bazy danych do innej poprawiło wydajność naszej witryny”.
Mierzysz wydajność poprzedniej bazy danych poprzez profilowanie lub statystyki wykonawcze, zbierając wystarczającą ilość informacji o zapytaniach i ich szybkości.
Przenosisz aplikację do nowej bazy danych.
Robisz te same środki.
Porównujesz
Na przykład, jeśli pełna lista 3 182 432 produktów załadowanych w 2.834 s. na starej bazie danych i ładuje się w 0,920 s. w nowej bazie danych, biorąc pod uwagę, że w obu przypadkach aplikacja ma pustą pamięć podręczną, jest to wygrana: nowa baza danych poprawiła wydajność witryny w zakresie tego zapytania.
Teraz, jak każda miara wydajności, jest tendencyjna:
Uzgodnione, nowe zapytanie jest szybsze. Ale poczekaj, Twój DBA nie wiedział, jak korzystać z bazy danych, którą posiadałeś wcześniej , więc zapytanie, które ładuje wszystkie produkty, nie jest zoptymalizowane . Jeśli przepiszesz go w ten sposób, będziesz mógł załadować te produkty w 0,855 s. zamiast 2.834.
Ok, masz lepszy wynik. Ale czy nie uważasz, że niesprawiedliwe jest porównywanie bazy danych ze świeżymi danymi właśnie opróżnionymi do 10-letniej bazy danych, dla której ostatni plan konserwacji został uruchomiony trzy lata temu? Nawiasem mówiąc, czy nie uważasz, że powinieneś był aktualizować produkt bazy danych przynajmniej raz w ciągu ostatnich czterech lat?
Niektóre zapytania są szybsze. Niektóre są wolniejsze. Jak obliczyć średni wynik, aby wiedzieć, że ogólnie osiągnąłeś wydajność po przejściu do nowej bazy danych? Ok, czas ładowania wszystkich 3 182 432 produktów jest krótszy. Ale czy to ma znaczenie, gdy zapytanie jest wykonywane w witrynie tylko w rzadkich przypadkach, gdy administrator wykonuje jakieś konkretne zadanie, które wykonał tylko dwa razy w ciągu ostatnich dziesięciu lat? Z drugiej strony wykonywanie wszystkich zapytań na stronie głównej dla nowego użytkownika marnuje 0,281 s. z nową bazą danych, kiedy wynosiła ona 0,207 s. ze starą bazą danych. Ten wynik ma o wiele większe znaczenie, tym bardziej, że zapytania te nie mogą być buforowane przez długi czas i są wykonywane dziesiątki tysięcy razy dziennie.
Obie bazy danych muszą być testowane na tych samych serwerach , tym samym sprzęcie, tej samej strukturze. Na przykład nie można przetestować jednej bazy danych na jednym dysku twardym, a drugiej na macierzy RAID1 dwóch dysków SSD. Gdy migrujesz duży projekt do nowej bazy danych, istnieje szansa, że po prostu będziesz hostować nową bazę danych na stu innych nowo wdrożonych serwerach stelażowych, gdy poprzednia baza danych pozostanie na poprzednich komputerach.
Podsumowując, możesz przeprowadzić analizę porównawczą zapytań do bazy danych aplikacji i uzyskać dokładne pomiary . Ale musisz nadać znaczenie liczbom. W tym stanie kuszące jest stwierdzenie, że zyskałeś wydajność witryny: w przeciwnym razie kierownictwo byłoby wściekłe, gdybym dowiedział się, że wydałeś tysiące dolarów i miesięcy pracy, aby spowolnić pracę.
Najstraszniejszym błędem jest wyciągnięcie tych wniosków z testów porównawczych i wyciągnięcie jakiejś głupoty, takiej jak „Microsoft SQL Server jest trzy razy szybszy niż Oracle”: mówiąc, że to tak, jakby powiedzieć, że „Java jest lepsza niż PHP”. Zdefiniuj lepiej. Lepiej w jakich przypadkach? Do jakiego rodzaju aplikacji? Dla jakiego zespołu programistów?
Im więcej interpretujesz i uogólniasz, tym bardziej rzecz staje się nieistotna i bez znaczenia.
Zapytanie, select [...]które można znaleźć w wersji # 832 w pliku ProductFactory.cs, wiersz 117 wykonuje się w ciągu 0,5 s. z nową bazą danych podczas testowania w warunkach określonych w wymaganiach niefunkcjonalnych, załącznik M, przypadek 3. Pozwala to na spełnienie niefunkcjonalnego wymagania 527 (patrz strona 80, wersja 9). Ten sam wymóg nie był spełniony w poprzedniej bazie danych, gdy wyniki testu były w zakresie 0,9..1,3 s. w tych samych warunkach.
ma znaczenie dla programisty i jest wystarczająco precyzyjny, aby wiedzieć, co zostało przetestowane, jak i jakie były wyniki. To odpowiada na twoje pytanie nr 2.
Niestety zarządzanie nie ma żadnego sensu. Zamiast:
Migracja naszego produktu z MySQL do najnowszej wersji Microsoft SQL Server poprawiła ogólną wydajność naszego produktu o pięć, zmniejszając jednocześnie koszty o dwa i wpływ na środowisko o trzy. Wierzymy, że migracja wszystkich naszych aplikacji do Microsoft SQL Server w przyszłym roku przyniesie jeszcze lepsze wyniki i zwiększy naszą konkurencyjność na rynku.
to czysty marketingowy jibber-jabber i technicznie nic nie znaczy, ale zaskakująco ma wartość dla działów zarządzania i marketingu.
Wreszcie, czy możemy porównać różne typy baz danych? Powiedziałbym, że jest to całkowicie możliwe. Załóżmy, że mam stronę internetową z dużymi zdjęciami. Te zdjęcia są przechowywane w varbinary(max)Microsoft SQL Server 2005 (więc nie mogę użyć filestream). Niepokoi mnie wydajność podczas ładowania tych zdjęć, dlatego postanowiłem zapisać je jako pliki, używając systemu plików jako mojej nowej bazy danych. Po pierwsze, pliki te są przechowywane na tym samym komputerze co baza danych. Profiluję nowe rozwiązanie i uzyskuję wynik, który pokazuje, że w moim przypadku pliki są ładowane o 4% szybciej z systemu plików niż z Microsoft SQL Server. Benchmark jest bardzo jasny. Teraz mogę pomyśleć o wdrożeniu dedykowanego serwera zoptymalizowanego pod kątem bezpośredniego przechowywania plików, zamiast używania serwera zoptymalizowanego pod kątem Microsoft SQL Server.