Dlaczego bazy danych nie tworzą automatycznie własnych indeksów?
32
Myślałem, że bazy danych będą miały wystarczającą wiedzę na temat tego, z czym często się spotykają, i będą w stanie odpowiedzieć na postawione im wymagania, aby mogły zdecydować o dodaniu indeksów do bardzo wymaganych danych.
Czy Twój samochód automatycznie naprawia swoją płaską oponę?
Kermit
11
bardziej dokładna analogia to czy ECU zmienia moc dostarczaną do pompy paliwa, aby naprawić natężenie przepływu paliwa / oleju i zrekompensować zabrudzenie przewodów? na które odpowiedź brzmi tak ..
Jharwood
11
Baza danych może już umieścić indeks na stole, który obecnie wymaga od nas polecenia, samochód fizycznie nie może wymienić opony, dopóki nie zbudujemy dla niej broni.
Jharwood
1
Robią - dla kolumn, które mają UNIQUEograniczenia.
dan04
8
Jeśli znajdziesz w Google „samodostrajające się bazy danych”, znajdziesz wiele badań na ten temat. Być może w przyszłości będzie to miało jakiś element.
Martin Smith
Odpowiedzi:
25
Aktualizacja
Jest to teraz zaimplementowane w SQL Server Azure. Generuje rekomendacje
Możesz ustawić Doradcę bazy danych SQL, aby automatycznie wdrażał zalecenia. Gdy rekomendacje będą dostępne, zostaną one automatycznie zastosowane. Podobnie jak w przypadku wszystkich operacji indeksu zarządzanych przez usługę, jeśli wpływ na wydajność jest ujemny, zalecenie zostanie cofnięte.
Oryginalna odpowiedź
Niektóre bazy danych już (automatycznie) tworzą indeksy automatycznie.
W SQL Server plan wykonania może czasem obejmować operatora buforowania indeksów , w którym RDBMS dynamicznie tworzy indeksowaną kopię danych. Jednak bufor ten nie jest stałą częścią bazy danych zsynchronizowaną z danymi źródłowymi i nie może być współużytkowany między wykonywaniem zapytań, co oznacza, że wykonanie takich planów może spowodować wielokrotne tworzenie i upuszczanie tymczasowych indeksów na te same dane.
Być może w przyszłości RDBMS będą mogły dynamicznie upuszczać i tworzyć trwałe indeksy zgodnie z obciążeniem.
Proces optymalizacji indeksu jest w końcu tylko analizą kosztów i korzyści. Chociaż prawdą jest, że ludzie mogą mieć więcej informacji na temat względnego znaczenia zapytań w obciążeniu, zasadniczo nie ma powodu, dla którego informacje te nie mogłyby zostać udostępnione optymalizatorowi. SQL Server ma już moduł zarządzający zasobami, który umożliwia klasyfikowanie sesji do różnych grup obciążeń z różnymi przydziałami zasobów zgodnie z priorytetem.
Brakujące indeksy DMV, o których wspomina Kenneth, nie są przeznaczone do implementacji na ślepo, ponieważ uwzględniają jedynie zalety konkretnego zapytania i nie podejmują próby uwzględnienia kosztu potencjalnego indeksu dla innych zapytań. Nie konsoliduje również podobnych brakujących indeksów. np. wyjście tego DMV może zgłaszać brakujące indeksy na A,B,CiA,B INCLUDE(C)
Niektóre bieżące problemy z pomysłem są
Jakość każdej zautomatyzowanej analizy, która nie tworzy indeksu, będzie w dużym stopniu zależna od dokładności modelu wyceny.
Nawet w obszarze zautomatyzowanej analizy rozwiązanie offline będzie mogło być dokładniejsze niż rozwiązanie online, ponieważ konieczne jest, aby rozwiązanie online nie dodawało dużych zasobów księgowych do serwera na żywo i kolidowało z jego głównym celem wykonywania zapytań.
Indeksy tworzone automatycznie w odpowiedzi na obciążenie będą musiały zostać utworzone w odpowiedzi na zapytania, które uznałyby je za przydatne, więc pozostaną w tyle za rozwiązaniami, które wcześniej utworzą indeksy.
Prawdopodobnie uzasadnione jest oczekiwanie poprawy dokładności modeli wyceny w czasie, ale punkt 2 wydaje się trudniejszy do rozwiązania, a punkt 3 jest z natury nierozpuszczalny.
Prawdopodobnie jednak zdecydowana większość instalacji nie znajduje się w tej wyidealizowanej sytuacji z wykwalifikowanym personelem, który stale monitoruje, diagnozuje i przewiduje (lub przynajmniej reaguje) na zmiany obciążenia pracą.
Projekt AutoAdmin w Microsoft Research działa od 1996 roku
Celem tego projektu jest samodzielne dostrajanie baz danych i administrowanie nimi poprzez wykorzystanie wiedzy o obciążeniu pracą
Strona główna projektu zawiera kilka intrygujących projektów. Jedna jest szczególnie istotna w przypadku tego pytania
Kolejny interesujący problem pojawia się, gdy nie ma dostępnego DBA (np. Wbudowana baza danych lub mała firma). W takich scenariuszach ważne może być ciągłe dostrajanie indeksów przy niskim poziomie dotyku. Zbadaliśmy rozwiązania ... [w] „ Podejście internetowe do dostrajania projektu fizycznego ” w ICDE 2007.
Autorzy stwierdzają
Dzięki coraz bardziej powszechnym funkcjom DBMS, takim jak indeksy online, zachęca się do poszukiwania bardziej automatycznych rozwiązań fizycznych problemów projektowych, które posuwają naprzód stan techniki.
Artykuł przedstawia algorytm
Jego główne cechy to:
Po zoptymalizowaniu zapytań identyfikujemy odpowiedni zestaw indeksów kandydujących, które poprawiłyby wydajność. Ta funkcja umożliwia kontynuowanie przetwarzania zapytań równolegle z indeksami wbudowanymi w tle.
W czasie wykonywania śledzimy potencjalne korzyści, które tracimy, nie mając takich indeksów kandydujących, a także użyteczność istniejących indeksów w obecności zapytań, aktualizacji i ograniczeń przestrzeni.
Po zebraniu wystarczającej liczby „dowodów”, że fizyczna zmiana projektu jest korzystna, automatycznie uruchamiamy tworzenie lub usuwanie indeksu.
Internetowy charakter naszego problemu oznacza, że ogólnie będziemy opóźniać się z optymalnymi rozwiązaniami znającymi przyszłość. Jednak dzięki dokładnemu pomiarowi dowodów upewniamy się, że nie odczuwamy znaczących opóźnień w podejmowaniu decyzji, ograniczając w ten sposób kwotę poniesionej straty
Implementacja algorytmu pozwala na dławienie w odpowiedzi na zmiany obciążenia serwera, a także może przerwać tworzenie indeksu, jeśli podczas tworzenia zmiany obciążenia i oczekiwane korzyści spadną poniżej punktu, który uznaje się za opłacalny.
Wniosek autorów na temat Online a tradycyjne strojenie fizyczne.
Algorytmy online w tej pracy są przydatne, gdy DBA nie są pewni przyszłego zachowania obciążenia lub nie mają możliwości przeprowadzenia kompleksowej analizy lub modelowania. Jeśli DBA ma pełne informacje o charakterystyce obciążenia, lepszym rozwiązaniem byłaby analiza statyczna i wdrożenie za pomocą istniejących narzędzi (np. [2, 3]).
Nasze podejście nie może przebić doradcy indeksu, jeśli całe obciążenie jest znane z góry. Jednak w dynamicznych środowiskach z ewoluującymi i zmieniającymi się obciążeniami podejście oparte na zapytaniach daje lepsze wyniki.
Zakładanie, że jego umiejętności nigdy nie zostanie zautomatyzowane, jest niezwykle niebezpieczne dla kariery DBA. To właśnie zabija karierę facetów z sieci, ponieważ następuje przejście do centrów danych zdefiniowanych programowo. Jako dobre DBA powinniśmy być liderem w dziedzinie automatyzacji.
Gaius,
20
Projekt indeksu, który wprowadziłeś, jest czymś więcej niż sztuką. RDBMS nie jest wystarczająco inteligentny, aby podjąć typowe obciążenia i zaprojektować inteligentną strategię indeksowania. Interwencja człowieka (czytaj: DBA) polega na analizie obciążenia pracą i określeniu najlepszego podejścia.
Gdyby nie istniała kara posiadania indeksów, byłoby po prostu strzelać do nieskończonej liczby indeksów. Ale ponieważ modyfikacja danych (WSTAWKI, AKTUALIZACJE i USUWANIE) ma wpływ na włączone indeksy w tabeli, to narzuty tych indeksów będą zmienne.
Inteligentne tworzenie indeksów, które zmaksymalizują wydajność odczytu, przy minimalnym nakładzie modyfikacji danych, wymaga projektowania i strategii człowieka.
Problem jest zaskakująco trudny do rozwiązania, więc nic dziwnego, że większość baz danych nie tworzy ich automatycznie (BigTable / SimpleDB sobie z tym radzi, ponieważ nie pozwalają na dowolne łączenia, co znacznie ułatwia sprawę) . Ponadto tworzenie indeksów w locie jest czasochłonnym procesem, który wymaga wyłącznego dostępu do całego stołu - zdecydowanie nie jest to coś, co chcesz zrobić, gdy stół jest online.
Jednak biorąc pod uwagę liczbę aplikacji internetowych LAMP, które zostały napisane przez amatorów, którzy nawet nie wiedzą, co to jest indeks , nadal uważam, że ta funkcja byłaby korzystna dla niektórych osób.
Powiedziałbym, że porównywanie BigTable (i jego pochodnych, takich jak Cassandra, HBase itp.) Z rozwiązaniami RDBMS polega na porównywaniu jabłek z pomarańczami - BigTable i pochodne są bardziej jak gigantyczne magazyny klucz-wartość lub kolumny, a klucz wiersza jest z natury indeksem .
Suman
1
Dokładnie. Pytanie jest oznaczone rdbmsi nie sądzę, że BigTable należy do tej kategorii.
ypercubeᵀᴹ
2
@ypercube: ... Tak, wspomniałem o tym w mojej odpowiedzi; ale nadal warto o tym wiedzieć, przynajmniej jako punkt zainteresowania. Ja również wspomnieć kilka innych baz danych, które są RDBMS, które to zrobić, i wyjaśnił, dlaczego nie jest to powszechne. To zdecydowanie nie zasługuje na gorącą opinię ...
BlueRaja - Danny Pflughoeft
1
Nie przegłosowałem. Zgadzam się, że to bardzo trudny problem.
ypercubeᵀᴹ
10
Chociaż istnieją już obszerne odpowiedzi, wydają się one ominąć prawdziwą odpowiedź: Indeksy nie zawsze są pożądane.
Biorąc pod uwagę analogię samochodu wymienioną w komentarzach, lepiej powiedzieć, dlaczego nie wszystkie samochody są wyposażone w pakiety sportów ekstremalnych? Częściowo jest to koszt, ale wynika to również z faktu, że wiele osób nie potrzebuje lub nie chce niskoprofilowych opon i twardego zawieszenia; to niepotrzebnie niewygodne.
Więc może masz 1000 odczytów dla każdej wstawki, dlaczego nie masz automatycznie utworzonego indeksu? Jeśli tabela jest szeroka, a zapytania są zróżnicowane, dlaczego nie mieć ich kilku? Może zatwierdzenie ma krytyczne znaczenie dla czasu, a odczyty nie; w tych okolicznościach spowolnienie wstawiania może być niedopuszczalne. Być może pracujesz z ograniczoną ilością miejsca na dysku i nie możesz sobie pozwolić na dodatkowe indeksy zajmujące miejsce, które masz.
Chodzi o to, że indeksy nie są tworzone automatycznie, ponieważ nie są odpowiedzią na wszystko. Projektowanie indeksów to nie tylko powiedzenie „hej, to przyspieszy moje czytanie”, należy wziąć pod uwagę inne czynniki.
+1, podczas gdy na pewno jest to możliwe i możliwe do zautomatyzowania tych rzeczy, nie zawsze będzie nam lepiej z garstką magicznych indeksów zaimplementowanych przez system, który nie ma wglądu w to, w jaki sposób dane zostaną wykorzystane jutro, nieważne, jak piszesz w porównaniu do odczytu progu kompromisu Pewnego dnia napisałem o tym trochę na blogu , ale najwyraźniej jest o wiele więcej do omówienia.
Aaron Bertrand
> Może zatwierdzenie ma krytyczne znaczenie dla czasu, a odczyty nie są; w tych okolicznościach spowolnienie wstawiania może być niedopuszczalne. Tak dobra odpowiedź, bardzo pomocna.
Siddhartha,
6
Mogą analizować poprzednie zapytania i sugerować / tworzyć indeksy, jednak nie działa to optymalnie, ponieważ indeksy osiągają równowagę, aby przyspieszyć to, co chcesz zoptymalizować kosztem, a serwer nie może poznać twoich zamiarów.
Nie są bystrzy, są kawałkiem kodu. Za każdym razem, gdy wprowadzasz nowe dane do bazy danych, musi ona znaleźć nową lokalizację i mapę, aby znaleźć ją na żądanie. Indeksowanie dźwięków jest łatwiejsze niż jest, po prostu nadajesz nowy numer nowej części danych? A może następne pytanie nie dotyczy ostatniego fragmentu danych, ale około 36271 fragmentów wcześniej? Możesz go łatwo znaleźć za pomocą swojego indeksu, prawda? Ale co jeśli zapytanie zawiera słowo „wędkowanie”, które można znaleźć w starym kawałku 36271 z 1997 r.? Ho? W starym artykule ani słowa o łowieniu ryb.
Gdyby dane przychodziły do bazy danych jedna po drugiej, mogłyby być indeksowane w ten sposób. Ale proste indeksowanie prędzej czy później spowoduje błędne wyniki i / lub spowolnienie działania ...
UNIQUEograniczenia.Odpowiedzi:
Aktualizacja
Jest to teraz zaimplementowane w SQL Server Azure. Generuje rekomendacje
a zarządzanie indeksami można skonfigurować tak, aby było automatyczne .
Oryginalna odpowiedź
Niektóre bazy danych już (automatycznie) tworzą indeksy automatycznie.
W SQL Server plan wykonania może czasem obejmować operatora buforowania indeksów , w którym RDBMS dynamicznie tworzy indeksowaną kopię danych. Jednak bufor ten nie jest stałą częścią bazy danych zsynchronizowaną z danymi źródłowymi i nie może być współużytkowany między wykonywaniem zapytań, co oznacza, że wykonanie takich planów może spowodować wielokrotne tworzenie i upuszczanie tymczasowych indeksów na te same dane.
Być może w przyszłości RDBMS będą mogły dynamicznie upuszczać i tworzyć trwałe indeksy zgodnie z obciążeniem.
Proces optymalizacji indeksu jest w końcu tylko analizą kosztów i korzyści. Chociaż prawdą jest, że ludzie mogą mieć więcej informacji na temat względnego znaczenia zapytań w obciążeniu, zasadniczo nie ma powodu, dla którego informacje te nie mogłyby zostać udostępnione optymalizatorowi. SQL Server ma już moduł zarządzający zasobami, który umożliwia klasyfikowanie sesji do różnych grup obciążeń z różnymi przydziałami zasobów zgodnie z priorytetem.
Brakujące indeksy DMV, o których wspomina Kenneth, nie są przeznaczone do implementacji na ślepo, ponieważ uwzględniają jedynie zalety konkretnego zapytania i nie podejmują próby uwzględnienia kosztu potencjalnego indeksu dla innych zapytań. Nie konsoliduje również podobnych brakujących indeksów. np. wyjście tego DMV może zgłaszać brakujące indeksy na
A,B,CiA,B INCLUDE(C)Niektóre bieżące problemy z pomysłem są
Prawdopodobnie uzasadnione jest oczekiwanie poprawy dokładności modeli wyceny w czasie, ale punkt 2 wydaje się trudniejszy do rozwiązania, a punkt 3 jest z natury nierozpuszczalny.
Prawdopodobnie jednak zdecydowana większość instalacji nie znajduje się w tej wyidealizowanej sytuacji z wykwalifikowanym personelem, który stale monitoruje, diagnozuje i przewiduje (lub przynajmniej reaguje) na zmiany obciążenia pracą.
Projekt AutoAdmin w Microsoft Research działa od 1996 roku
Strona główna projektu zawiera kilka intrygujących projektów. Jedna jest szczególnie istotna w przypadku tego pytania
Autorzy stwierdzają
Artykuł przedstawia algorytm
Implementacja algorytmu pozwala na dławienie w odpowiedzi na zmiany obciążenia serwera, a także może przerwać tworzenie indeksu, jeśli podczas tworzenia zmiany obciążenia i oczekiwane korzyści spadną poniżej punktu, który uznaje się za opłacalny.
Wniosek autorów na temat Online a tradycyjne strojenie fizyczne.
Wnioski tutaj są podobne do wniosków zawartych w innym artykule Autonomiczne oparte na zapytaniach strojenie indeksu
źródło
Projekt indeksu, który wprowadziłeś, jest czymś więcej niż sztuką. RDBMS nie jest wystarczająco inteligentny, aby podjąć typowe obciążenia i zaprojektować inteligentną strategię indeksowania. Interwencja człowieka (czytaj: DBA) polega na analizie obciążenia pracą i określeniu najlepszego podejścia.
Gdyby nie istniała kara posiadania indeksów, byłoby po prostu strzelać do nieskończonej liczby indeksów. Ale ponieważ modyfikacja danych (WSTAWKI, AKTUALIZACJE i USUWANIE) ma wpływ na włączone indeksy w tabeli, to narzuty tych indeksów będą zmienne.
Inteligentne tworzenie indeksów, które zmaksymalizują wydajność odczytu, przy minimalnym nakładzie modyfikacji danych, wymaga projektowania i strategii człowieka.
źródło
W rzeczywistości istnieją takie bazy danych. Na przykład Google BigTable i Amazon SimpleDB automatycznie tworzą indeksy (chociaż nie są to RDBMS) . Jest też co najmniej jeden silnik MySQL RDBMS, który to robi. SQL Server śledzi również indeksy, które Twoim zdaniem powinieneś utworzyć , chociaż nie idzie tak daleko jak ich tworzenie.
Problem jest zaskakująco trudny do rozwiązania, więc nic dziwnego, że większość baz danych nie tworzy ich automatycznie (BigTable / SimpleDB sobie z tym radzi, ponieważ nie pozwalają na dowolne łączenia, co znacznie ułatwia sprawę) . Ponadto tworzenie indeksów w locie jest czasochłonnym procesem, który wymaga wyłącznego dostępu do całego stołu - zdecydowanie nie jest to coś, co chcesz zrobić, gdy stół jest online.
Jednak biorąc pod uwagę liczbę aplikacji internetowych LAMP, które zostały napisane przez amatorów, którzy nawet nie wiedzą, co to jest indeks , nadal uważam, że ta funkcja byłaby korzystna dla niektórych osób.
źródło
rdbmsi nie sądzę, że BigTable należy do tej kategorii.Chociaż istnieją już obszerne odpowiedzi, wydają się one ominąć prawdziwą odpowiedź: Indeksy nie zawsze są pożądane.
Biorąc pod uwagę analogię samochodu wymienioną w komentarzach, lepiej powiedzieć, dlaczego nie wszystkie samochody są wyposażone w pakiety sportów ekstremalnych? Częściowo jest to koszt, ale wynika to również z faktu, że wiele osób nie potrzebuje lub nie chce niskoprofilowych opon i twardego zawieszenia; to niepotrzebnie niewygodne.
Więc może masz 1000 odczytów dla każdej wstawki, dlaczego nie masz automatycznie utworzonego indeksu? Jeśli tabela jest szeroka, a zapytania są zróżnicowane, dlaczego nie mieć ich kilku? Może zatwierdzenie ma krytyczne znaczenie dla czasu, a odczyty nie; w tych okolicznościach spowolnienie wstawiania może być niedopuszczalne. Być może pracujesz z ograniczoną ilością miejsca na dysku i nie możesz sobie pozwolić na dodatkowe indeksy zajmujące miejsce, które masz.
Chodzi o to, że indeksy nie są tworzone automatycznie, ponieważ nie są odpowiedzią na wszystko. Projektowanie indeksów to nie tylko powiedzenie „hej, to przyspieszy moje czytanie”, należy wziąć pod uwagę inne czynniki.
źródło
Mogą analizować poprzednie zapytania i sugerować / tworzyć indeksy, jednak nie działa to optymalnie, ponieważ indeksy osiągają równowagę, aby przyspieszyć to, co chcesz zoptymalizować kosztem, a serwer nie może poznać twoich zamiarów.
źródło
Nie są bystrzy, są kawałkiem kodu. Za każdym razem, gdy wprowadzasz nowe dane do bazy danych, musi ona znaleźć nową lokalizację i mapę, aby znaleźć ją na żądanie. Indeksowanie dźwięków jest łatwiejsze niż jest, po prostu nadajesz nowy numer nowej części danych? A może następne pytanie nie dotyczy ostatniego fragmentu danych, ale około 36271 fragmentów wcześniej? Możesz go łatwo znaleźć za pomocą swojego indeksu, prawda? Ale co jeśli zapytanie zawiera słowo „wędkowanie”, które można znaleźć w starym kawałku 36271 z 1997 r.? Ho? W starym artykule ani słowa o łowieniu ryb.
Gdyby dane przychodziły do bazy danych jedna po drugiej, mogłyby być indeksowane w ten sposób. Ale proste indeksowanie prędzej czy później spowoduje błędne wyniki i / lub spowolnienie działania ...
źródło