Indeks szaleństwa: jak uniknąć chaosu w bazie danych

2025

Spisu treści:

Partner treści Techopedia
Partner treści Techopedia

Przez Techopedia Staff, 5 października 2016 r

Na wynos: gospodarz Eric Kavanagh omawia indeksowanie baz danych z dr Robin Bloor, Dezem Blanchfieldem i Bertem Scalzo z IDERA.

Obecnie nie jesteś zalogowany. Zaloguj się lub zarejestruj, aby zobaczyć wideo.

Partner treści Techopedia

Personel Techopedia jest powiązany z Bloor Group i można się z nim skontaktować, korzystając z opcji po prawej stronie. Aby uzyskać informacje o tym, jak współpracujemy z partnerami branżowymi, kliknij tutaj.

Profil
Stronie internetowej

Eric Kavanagh: Panie i panowie, witam i witam ponownie. Jest środa, o czwartej na wschodzie, a ci z was, którzy znają program, wiedzą, co to znaczy, czas na kolejny odcinek Hot Technologies. W rzeczy samej. Nazywam się Eric Kavanagh, będę moderatorem dzisiejszej sesji: „Index Insanity: Jak uniknąć chaosu w bazie danych”. Lub, jak wspomniałem w ostatnim e-mailu, aby wyjść: „wranglowanie bazy danych”. Gorące określenie w dzisiejszych czasach „wranglowanie”. Wszyscy to robią. Naprawdę jest slajd o twoim. I dość o mnie.

Tak więc seria Hot Technology naprawdę została zaprojektowana, aby zdefiniować konkretną przestrzeń, w przeciwieństwie do Briefing Room, który jest tylko odprawą analityków na żywo jeden do jednego, dla Hot Tech mamy dwóch analityków. Dzisiaj będzie to nasz własny doktor Robin Bloor i nasz naukowiec Dez Blanchfield. I mówimy o temacie, który moim zdaniem jest naprawdę bardzo symboliczny dla tego, co dzieje się dzisiaj na rynku.

Najważniejsze jest to, że obecnie jesteśmy w świecie złożoności. Naprawdę, jeśli myślisz wstecz o piętnaście lub dwadzieścia lat, był to wtedy zupełnie inny świat, szczególnie w odniesieniu do technologii baz danych. Bazy danych były kiedyś dość proste. Było ich tylko garstka; większość z nich była relacyjna. Teraz mamy całą masę technologii baz danych. Dosłownie dziesiątki opcji na stole dla każdego, kto chce zbudować aplikację lub zrobić coś z danymi. Wszystko się zmienia, co wpływa na ludzi, którzy próbują zarządzać tymi systemami. Dzisiaj porozmawiamy z Bertem Scalzo, który jest prawdziwym ekspertem w tej dziedzinie; jest starszym zarządcą produktu dla IDERA, o tym, co możesz zrobić, aby uzyskać kontrolę nad wszystkimi tymi danymi. Po tym przekażę to doktorowi Robin Bloor, aby go zabrał. Robin, podłoga jest twoja.

Robin Bloor: Dobra, dzięki za wprowadzenie. Myślę, że - ponieważ jest to dwuręczna sprawa, myślę, że po prostu porozmawiam o optymalizacji bazy danych jako wprowadzenie do tego show Hot Tech. Zacząłem życie - w technologii i analizach - zacząłem to robić, ponieważ pisałem artykuły na temat możliwości baz danych na platformie DEC VAX. Z tego powodu wydawcy baz danych zwykli mnie informować. Przyszło mi do głowy, dlaczego miałabyś mieć bazę danych? Mam na myśli, że w tamtych czasach okropnie dużo osób tworzyło pliki o kluczowej wartości i używało ich do pewnego rodzaju błędnego sekwencyjnego indeksowania, jak je nazywamy, ale do tworzenia pewnego rodzaju możliwości bazy danych, a wiesz, dlaczego miałbyś coś jeszcze?

I odpowiedź na to pytanie, myślę, że Michael Stonebraker udzielił na to najlepszej odpowiedzi i powiedział: „Baza danych może wiedzieć więcej o tym, gdzie są dane i jak szybko je uzyskać, niż jakikolwiek program może wiedzieć”. I myślę, że to interesujące; taka jest natura gry. Ale w 19 - dobrze około 1989 roku, który rozpocząłem w analizie technologii i wiesz, w tamtym czasie bazy danych były bardzo proste, a relacyjne bazy danych były bardzo proste. Miały tak mało możliwości, to znaczy, mogły oczywiście przechowywać dane, i można było wykonać kopię zapasową, a oni mieli, byli zgodni z ACID, ale naprawdę mieli bardzo słabe optymalizatory. W rzeczywistości trudno byłoby argumentować, że w ogóle mieli możliwości optymalizacji.

A później stały się coraz lepsze, ale wiesz, kiedy baza danych nie działa - ponieważ te kangury wydają się wskazywać w ten czy inny sposób - istnieje wiele powodów, dla których działa wolno. I to prowadzi mnie do sedna: bazy danych mają wiele funkcji, ale najważniejsza z nich to optymalizacja zapytań. Gdyby tego nie zrobili, nie wykorzystalibyście ich. Chodzi o szybkie uzyskiwanie informacji, jest w stanie to zrobić, gdy jest wielu współbieżnych użytkowników, a to jest trudny problem. A kiedy faktycznie spojrzysz na, nazwijmy je dojrzałymi bazami danych, jeśli lubisz - ale z pewnością Oracle, w nieco mniejszym stopniu, Microsoft SQL Server, z pewnością Teradata i DB2 - optymalizatory tych baz danych już od dziesięcioleci budynek. Wiesz, nie zrobili - ktoś nie usiadł - sześciu facetów w dwumiejscowym, rocznym projekcie i po prostu powalili jednego. To tak nie działa. Możliwości optymalizacji stopniowo rosły i zajmuje dużo czasu. W każdym razie porozmawiajmy o tle bazy danych. O bazie NoSQL mówi się teraz bardzo dużo, a baza danych grafów jest bardzo entuzjastyczna. I użycie SQL nad Hadoop i tego typu rzeczy. Ale prawda jest taka, że jeśli chcesz teraz bazy danych, jeśli chcesz w pełni funkcjonalny, zdolny do obsługi OLTP i dużego ruchu zapytań, jest to relacyjna baza danych lub nic.

Wśród relacyjnych baz danych Oracle dominuje w popularności. Myślę, że Microsoft SQL Server jest drugi. Oba mogą być używane do OLTP i obciążeń związanych z zapytaniami, ale tak naprawdę nie można uniknąć mieszania tych obciążeń. Potrzebujesz różnych incydentów dla obciążeń OLTP i obciążeń związanych z zapytaniami. Istnieją alternatywy dla SQL i grafu. Większość firm dokonuje standaryzacji w oparciu o jedną konkretną bazę danych, dlatego - mam na myśli po dziesięcioleciach walki z innymi graczami, Oracle stała się najbardziej dominującą. Po prostu dlatego, że ostatecznie mogli sprzedawać licencje korporacyjne, a więc firmy korzystałyby z alternatywnych produktów tylko w wyjątkowych produktach, Oracle po prostu ich nie robił. Bazy danych są strategiczne, ponieważ również ewoluują. I wiesz, że przeprowadziłem trochę badań dla tej prezentacji, i to trochę - przyjdę do niej za chwilę, ale to trochę interesujące, jak ewoluują, pod względem patrzenia na to z pozycji DBA. To właśnie nazywam niewidzialnym trendem. To prawo Moore'a. Z grubsza wygląda to tak: Największa baza danych i nowe bazy danych, nie ma starej bazy danych, która miałaby o wiele więcej danych do spożycia. Zwykle jest to baza danych, która jest stosowana do nowego problemu. I faktycznie rosną pod względem ilości danych. Z grubsza u kostki Moore'a prawo. Zatem prawo Moore'a jest dziesięciokrotnie większe co sześć lat. VLDB mają tendencję do wzrostu o tysiąc razy co sześć lat. W 1991 r. W 1992 r. Duże bazy danych były mierzone w megabajtach. W latach '97 i '98 gigabajty. 2003, „4, terabajty. 2009, '10, zacząłeś widzieć bazy danych petabajtów. Wydaje mi się, że w tej chwili istniała jedna lub dwie bazy danych eksabajtów, ale największa, o jakiej słyszałem, to 200 petabajtów na czas, i wiesz, nie dostanie danych do baz danych petabajtów. Ale większość z nich to oczywiście nowe duże firmy Web 2.0, być może masz Facebooka w tym kierunku.

Ale w każdym razie, jeśli faktycznie na to spojrzysz, oczekując, że baza danych przejdzie tego rodzaju eskalację objętości, to wymaga dużo. I, co niezwykłe, z pewnością do poziomu petabajtów, wydaje się, że poradzili sobie dość dobrze. Mam na myśli, że mówię raczej o starszych produktach niż o czymkolwiek nowym. Wydaje się, że poradzili sobie wyjątkowo dobrze. Jeśli spojrzymy na wydajność bazy danych, wąskie gardła, to zabiera mnie z powrotem do czasu, w którym faktycznie dbałem o nie i musiałem się o nie martwić. Wiesz, że jest to zasadniczo awaria sprzętu. Występują wąskie gardła procesora, być może istnieją wąskie gardła pamięci, być może istnieją wąskie gardła dysku. Może to być sieć, która powoduje smutek, a także możesz mieć problemy z blokowaniem, w zależności od tego, co robisz, ale zwykle dzieje się tak, ponieważ program nie wie, kto wywołać blokadę. Tak więc, jeśli zamierzasz dostroić bazę danych, tak naprawdę próbujesz ją dostroić, aby tańczyła między tymi pięcioma możliwymi wąskimi gardłami, jak to możliwe. I to nie jest łatwe, ponieważ ilość pamięci, którą można skonfigurować na dowolnym serwerze, dramatycznie wzrasta. Potem procesory stały się wielordzeniowe, dyskowe, no cóż, teraz możemy to zrobić, myślę, nawet na serwerach towarowych, myślę, że możesz zrobić setki i setki terabajtów, ćwierć petabajtów, może nawet na serwerze towarowym. Więc ze wszystkich tych rzeczy można się bawić, sieć może oczywiście działać z różnymi prędkościami, ale przede wszystkim, gdy mamy do czynienia z bazami danych, naprawdę chcemy mieć kable światłowodowe między serwerami i nic innego na tym, szczególnie w ten sposób.

Czynniki wydajności bazy danych. Chodzi mi o to, że pomijam, o co w tym wszystkim chodzi, ponieważ wiem, że Dez ma zamiar o tym mówić, ale zły projekt bazy danych oznacza słabo działającą bazę danych. Nieprawidłowy projekt programowania może oznaczać rzucanie bardzo głupim SQLem w bazę danych, co zajmie okropnie dużo dłużej. Mieszanie współbieżności i obciążenia, zbyt duża współbieżność spowoduje problemy z wąskim gardłem. Mieszanie obciążenia, gdy masz duże zapytania z bardzo małymi, krótkimi, ostrymi zapytaniami, które powodują problemy. Wystąpił problem z równoważeniem obciążenia. Zajmuje się tym większość baz danych, ale jeśli nie masz wyrafinowanego produktu, to wiesz, po prostu dodanie kilku serwerów, to nie wszystko, co naprawdę chcesz zrobić, aby zwiększyć rozmiar klastra. Musisz właściwie zrównoważyć obciążenie, zanim uzyskasz optymalną wydajność. Musisz zaplanować wydajność. Absolutnie. Zwłaszcza teraz w dzisiejszych czasach, kiedy ilość danych rośnie znacznie bardziej niż w przypadku baz danych. I istnieją problemy z całą warstwą danych dotyczące sposobu, w jaki je pobierasz, w jaki sposób przenosisz dane. Niedostarczenie danych do bazy danych na czas może być później problemem z wydajnością, ponieważ przeszliśmy z baz danych pracujących w systemie Windows do operacji dwudziestu czterech na siedem na trzysta siedemdziesiąt pięć i nie ma okien, w których można by spowolnić baza danych nie działa lub jest mało prawdopodobne, że będą w dzisiejszych czasach.

Problem Oracle DBA. Właśnie o tym myślałem. Byłem w DBA Oracle z Oracle 7 i pamiętam, jak to dostroić. A jeśli teraz spojrzysz na Oracle, to jest sposób, sposób - ma sposób, znacznie więcej możliwości. Ma indeksowanie map bitowych i takie tam, ale w rzeczywistości poświęciłem czas na sprawdzenie i sprawdzenie, ile parametrów strojenia faktycznie znajduje się w bazie danych Oracle. Istnieje ponad trzysta pięćdziesiąt parametrów dostrajania i jest jeszcze sto ukrytych parametrów, o których mogą wiedzieć specjaliści DBA, ale o normalnych DBA Oracle nie wiedzą. A to oznacza, że dostrajanie tego rodzaju bazy danych jest trudne. To wcale nie jest prosta sprawa. Musisz to wyczuć, musisz to robić przez długi, długi czas i musisz dokładnie wiedzieć, jaki problem rozwiązujesz, ponieważ strojenie rozpoczyna się, gdy wydajność maleje, ale może nie być to wydajność wszystkiego. Może to być wydajność określonych zapytań, które mogą mieć znaczenie, i możesz to naprawić, przypinając określone dane i pamięć, albo możesz to naprawić przez indeksowanie, lub może być konieczne rozpoczęcie partycjonowania w inny sposób. Chodzi o wiele rzeczy, które możesz zrobić. W związku z tym nie zamierzają tego robić w swoich głowach - DBA potrzebują narzędzi. Myślę, że przekażę teraz Dezowi, który powie ci o indeksowaniu.

Eric Kavanagh: Dobra, Dez, zabierz to.

Dez Blanchfield: Dziękuję Robin i uwielbiam stronę tytułową. Myślę, że rzuciłeś tam rękawicę, abym zbliżył się nawet do czegoś tak ekscytującego. Ale użyłem obrazu naszej małej galaktyki, ponieważ mój pogląd na to, w co zmieniło się dzisiejsze wyzwanie dla administratorów baz danych, ponieważ jest to obraz mentalny, który zwykle wyczarowuję, gdy wchodzę do środowiska i nie jestem już dłużej w świecie administrowania bazami danych lub projektowania baz danych na tym poziomie. Ale, podobnie jak ty, Robin i ja mieliśmy wiele lat zaangażowania w świat baz danych, zarówno jako administrator, programista, jak i architekt, a potem zdaliśmy sobie sprawę, że mogę zrobić lepsze rzeczy, aby uzyskać skorupę. Ale wydaje się, że patrzysz na tę galaktykę danych, a tym bardziej dzisiaj, kiedy przechodzimy od, jak wskazałeś, przeszliśmy od megabajtów do petabajtów i egzo-skali w bardzo krótkim czasie., w wielkim schemacie rzeczy. Ale zdanie, które mam na myśli, jest takie, że indeksy baz danych są teraz czarną sztuką i nie są tak naprawdę czymś, w co zwykli śmiertelnicy powinni się wtrącić, dla aplikacji biznesowych klasy korporacyjnej i rodzaju formułowania ciebie tylko rozmawialiśmy. Chciałem jednak szybko zapoznać się z historią tego rodzaju, którą miałem ze światami baz danych, i przybliżyć kontekst, w którym zamierzamy wyciągnąć wnioski, a następnie przejrzeć dzisiaj materiał z naszymi przyjaciółmi z IDERA, ponieważ myślę, że istnieje wiele różnych sposobów myślenia o tym, jak uzyskać dostrajanie wydajności bazy danych, a jednym z nich jest rzucanie bzdur. W wielu sklepach, z którymi się zetknąłem, niezmiennie nie dochodzą do punktu dostrajania wydajności w warstwie bazy danych, a zwłaszcza w warstwie indeksu, dopóki nie przejdą trudnej drogi myślenia, że mogą rzucić na nią tuner .

Wiele osób po prostu podchodzi do tego z dużym żelaznym podejściem, i mam tutaj zdjęcie z lampą błyskową, ponieważ jeśli kiedykolwiek oglądałeś jakieś stare filmy lub z pewnością najnowszy program telewizyjny z lampą błyskową, jak w Błysk Gordon, stara postać, a teraz nazywany „Błyskiem”, ma tendencję do biegania bardzo, bardzo szybko i niezmiennie jego energii się kończy. I tak się dzieje, gdy rzucasz wielkim żelazem w wydajność bazy danych. Niezmiennie, z mojego doświadczenia, możesz włożyć do gry wysoką wydajność, ciężką pracę, możesz zoptymalizować swoje systemy operacyjne i dostroić je do pewnego momentu. Możesz mieć pewność, że masz szybkie, wielordzeniowe, wielowątkowe procesory, aby aplikacja działała szybciej, możesz wrzucić do niej dużo pamięci RAM, możesz mieć szybsze płyty o dużej przepustowości, możesz przejść od dysków twardych do buforowania dysków twardych do stanu półprzewodnikowego oraz wysokiej wydajności macierz pamięci. I nawet teraz ludzie wrzucają takie technologie jak flash i NVMe do swoich silników baz danych, myśląc, że uzyskają ten czas logowania dwa razy większy wzrost wydajności. I niezmiennie zyskują. Ale wszystko wraca do tych samych podstawowych problemów związanych z dostrajaniem wydajności. Wiele połączeń sieciowych o niskim opóźnieniu, dzięki czemu klastry działają szybko. Oraz klastrowej infrastruktury bazy danych, dzięki czemu masz więcej niż jedną maszynę do wykonania całej pracy. Ale zwykle wracasz do tego samego podstawowego problemu z wydajnością, czyli odczytu danych. Zapisywanie danych jest w większości dość liniowym wyzwaniem i chyba, że jest wykonane poprawnie.

A potem mamy wyzwanie w dzisiejszym świecie: nie wszystkie bazy danych są sobie równe. Istnieją bazy danych i „baza danych z wyceną”. Kiedy myślimy o silnikach baz danych, ludzie często myślą o tradycyjnych, zwykle podejrzanych, jak w świecie SQL. Wiesz, mamy Oracle i Microsoft SQL Server, a wokół nich jest kilka w świecie open source z MySQL, który jest teraz własnością Oracle, ale wciąż jest open source. A potem mamy nietypowych podejrzanych, silniki NoSQL, które wciąż mają problem z indeksowaniem i zarządzaniem wydajnością, i nie będę wchodził w ich szczegóły, ale jest ich coraz więcej pojawiają się z dnia na dzień i wyglądają jak silniki baz danych z punktu widzenia programistów i wydajności, ale są to bardzo różne bestie i mają na świecie swoją własną niszę wydajność w pamięci lub skala liniowa na dysku. Ale tak wygląda świat w świecie baz danych. To jest 2016, to jest trzecia wersja mapy wielu ludzi, którzy tworzą tę ciągłą mapę krajobrazową tego, jak wyglądają bazy danych, i właśnie tam - nawet nadludzki architekt baz danych lub administrator bazy danych nie miałby sensu z tego. Dosłownie setki, setki i setki różnych marek, modeli, producentów baz danych, niezmiennie zgodne z SQL. Co ciekawe, wszyscy wracają do tego samego wyzwania. Wydajność i dostrajanie wydajności wokół silnika bazy danych, a zwłaszcza według sposobu indeksowania danych.

Więc po prostu szybko omówmy indeksowanie baz danych, ponieważ jest to interesujący temat i, jak sądzę, trzeba się bardziej szczegółowo zająć w wersji demo. Uważam jednak, że jest dość dobrze przyjętą i standardową praktyką branżową, że dostrajanie wydajności indeksów baz danych jest miejscem, w którym świat zaczyna się i kończy, o ile zapewnia się dostęp do danych w szybkim i szybkim formacie. Ale czym jest indeksowanie baz danych? Jeśli myślimy o indeksowaniu w formie, do której jesteśmy przyzwyczajeni jako zwykli ludzie, pomyśl o stronie indeksu w książce. Jeśli chcesz znaleźć coś w książce - szczególnie takie jak encyklopedia lub coś w rodzaju jakiejś formy odniesienia - jeśli szukasz czegoś takiego jak ta strona, na której szukam takich tematów jak tamy w encyklopedii. Chcę znaleźć każde odniesienie do tam, zlewni wody i dużego obszaru gromadzenia się, ogólnie stworzonego przez człowieka. Wrócę do tyłu, znajdę ją na uporządkowanej alfabetycznie liście od A do Z, od lewej do prawej, i znajdę D. Znajdę słowo „tamy” i widzę to na na stronach 16, 38, 41 znajduje się odniesienie do nich, a następnie mogę przejść do tych stron, mogę zeskanować oczy i znaleźć odniesienie do słowa „dam”. Jest to zasadniczo ta sama koncepcja w bazie danych, ale jest to obecnie nauka rakietowa na wiele sposobów. Do tego stopnia, że skutecznie każdy administrator bazy danych, który kiedykolwiek dobrze poznałem, uważa indeksy za jedno z najważniejszych narzędzi do dostrajania wydajności w dowolnym świecie baz danych, niezależnie od tego, jakie jest ich doświadczenie, jeśli chodzi o rzucanie cyną w to, lub bez względu na przypadek.

Zasadniczo, gdy mówimy o indeksowaniu baz danych, istnieje wiele typowych podejść. Im bardziej złożone indeksy baz danych, tym bardziej złożone podejście do indeksowania danych. Ale zasadniczo, gdy myślisz o indeksowaniu danych - wyobraź sobie, że mamy plik z listą nazw; nie mogą być sortowane w kolejności alfabetycznej. Wyobraźmy sobie, że jest ich dwadzieścia. Jeśli będziemy sortować - jeśli będziemy szukać danych na tej liście, od góry do dołu, i powiedzmy, że jest to lista nazwisk. Jeśli wybiorę losową nazwę i zacznę przewijać tę listę od góry do dołu w formacie liniowym i jest to lista nieuporządkowana, istnieją dwa kryteria, o których myślę jako mój średni czas wyszukiwania i maksymalny czas wyszukiwania - i Mam literówkę w drugiej linii, przepraszam - powinienem być „maksymalnym czasem wyszukiwania”, ale mój średni czas wyszukiwania to w zasadzie N plus jeden, podzielony przez dwa, i to średnio zajmuje mi pięćdziesiąt procent czasu aby skanować z góry listy, na dół listy, aby znaleźć dowolne losowe rzeczy na tej liście. Drugi wiersz, liniowy, powinien być „maksymalnym czasem przeszukiwania”. Maksymalny czas przeszukiwania to zasadniczo liczba elementów, i to znaczy, że jeśli mam listę dwudziestu rzeczy, to może zająć mi to najwięcej czasu aby wyszukać coś w tej bazie danych, należy przejść od góry do dołu, co powiedzmy 20 elementów w tym uproszczonym przykładzie. Jest to bardzo powolny proces i naprawdę nie ma sposobu, aby poprawić wydajność. Są też inne sposoby pobierania tych danych i tworzenia indeksu, który jest w rzeczywistości krótką listą wskaźników wskazujących, gdzie znajdują się rzeczywiste dane, takich jak dane binarne, drzewo B, mapa bitowa, mieszanie, klastrowanie i nieklastrowanie, a następnie istnieją różne typy danych, takie jak dane przestrzenne, filtrowane, XML i pełny tekst.

Binarny jest bardzo często używany do rzeczy, w których dane mu się nadają. B-drzewo jest prawdopodobnie jednym z najczęściej spotykanych w sensie ogólnym, historycznie, ponieważ jest to powszechny sposób strukturyzowania indeksu na dowolną formę danych i pozwala rejestratorom, selekcjom, wstawianiu i usuwaniu relatywnie łatwo przesuwać wskaźniki wokół odniesienie do wskaźników, punktów. Istnieją inne typy, takie jak mapa bitowa, w których typy danych dotyczą, jeśli mamy powiązany zakres jakiejś formy. Hashowanie działa bardzo dobrze w przypadku dużych obiektów, zwłaszcza blogów i obrazów. I widać, że istnieje wiele różnych rodzajów podejść naukowych, matematycznych, do indeksowania danych. Dla zwykłego śmiertelnika jest to interesujące wyzwanie do rozmowy na tym poziomie. Kiedy mówisz o tym na poziomie wydajności dla administratora bazy danych, naprawdę stają się naukowcami rakietowymi, a ludzie robią w nich stopnie naukowe, i wiem, że doktor Robin Bloor z pewnością to zrobił i napisał o tym książki dla takich jak IBM i inne duże marki w ciągu ostatnich kilku dekad. I tak, moim zdaniem jest to, że właściwie minęliśmy czas, w którym kiedyś wiesz, że osobiście byłbym w stanie usiąść przed systemem i byłbym w stanie go rozdzielić i pokazać ci dokładnie tam, gdzie występowały problemy z wydajnością w wierszu polecenia lub w narzędziu uruchamiania graficznego interfejsu użytkownika, i zacznij zagłębiać się w dane i powiedz, gdzie były problemy, i buduj w tym indeksy lub subindeksy, lub indeksy pierwotne i wtórne dane i zacznij ich używać do znajdowania rzeczy. Ale kiedy myślisz o tym krajobrazie, pokazałem ci, gdzie mamy setki marek, marek i modeli, a także producentów i typów baz danych, jesteśmy już dobrze i naprawdę minęli ten czas, w którym człowiek może stworzyć wyczucie rodzajów silników baz danych, które mamy. W szczególności, nawet jeśli wrócimy do Oracle, obecnie dominują marki na platformach relacyjnych baz danych.

Liczba baz danych, z którymi muszą sobie poradzić albo z zastrzeżonej platformy, takiej jak ERP, HR lub system finansowy, lub czy są to domowe platformy z różnych powodów, liczba baz danych i tabel i rekordów baz danych, które ostatecznie zajmowanie się jest po prostu astronomiczne i fizycznie nie można tego zrobić ręcznie. I mamy teraz dodatkową komplikację, w której serwer bazy danych może po prostu siedzieć pod twoim biurkiem. Wiesz, jako małe dziecko po szkole, pracowałem nad oprogramowaniem bazodanowym na systemach Apple IIes, a następnie na komputerach DOS, takich jak dBase II, dBase III, przeszedłem epokę z komputerami mainframe i mid- zakres, a nawet VAX i PDP oraz plik dziennika na tym. I podobnie jak Sabre, a potem, kiedy pojawiły się niektóre bazy danych SQL. Ale w dzisiejszych czasach, gdy myślimy o silnikach baz danych, wyglądają jak lewy dolny róg. Serwer bazy danych nie jest już tylko jedną maszyną siedzącą na podłodze pod biurkiem; to setki komputerów obsługujących kopie silników baz danych i klastrów, które skalują nawet do setek terabajtów danych, jeśli nie petabajtów danych, czyli tysięcy terabajtów. I nawet do skrajności, jak wspomniał doktor Robin Bloor, że niektóre konkretne przypadki użycia - linie lotnicze, w szczególności agencje rządowe - mogą dostać się do eksabajtów. Nadal są dość niszowe, ale setki terabajtów, a nawet dziesiątki petabajtów nie są już niczym niezwykłym, szczególnie od boomu dotcom do teraz, coś, co nazywamy firmami Web 2.0, takimi jak Facebook, Google, Yahoo i tak dalej.

Mamy również komplikację, ponieważ teraz sprawy przenoszą się do usług zewnętrznych. Mamy platformę infrastrukturalną i oprogramowanie jako podejście usługowe zapewniające infrastrukturę. W szczególności usługa platformy, gdzie nie możemy po prostu kupić takich produktów jak Oracle i ich platforma chmurowa, bazy danych i serwery. Pozwala nam to na bardzo szybki rozwój aplikacji i podłączenie bazy danych z powrotem do serwerów. Nie musimy myśleć o tym, co jest pod maską. Minusem jest to, że często nie myślimy o tym, jak projektujemy i wdrażamy bazę danych z powrotem, dopóki nie zacznie się boleć, a wydajność stanie się problemem, a następnie będziemy musieli poszukać odpowiedniego narzędzia, aby zdiagnozować, dlaczego nasza baza danych boli i gdzie występują problemy z wydajnością. I niezmiennie sprowadza to z powrotem do tego powszechnego problemu, w jaki sposób zaindeksowaliśmy te dane i typy indeksów, których użyliśmy dla tych danych, a następnie sprowadza nas z powrotem do nadludzkich wymagań dotyczących wydajności. A ktoś, kto ma dostęp do odpowiednich systemów i odpowiednich narzędzi do działania, dostroi te silniki, zacznie znajdować punkt zapalny i patrzy, gdzie są zapytania, gdzie przenoszą się dane, rodzaje zapytań, jak są one zorganizowane, kto robi zapytania i czy zapytania są w kolejce i muszą być buforowane. Jakiej replikacji szukasz?

Tak więc jesteśmy dobrze i - moim zdaniem - w momencie, w którym nawet najlepsi guru bazy danych na świecie, w szczególności nasi architekci baz danych oraz nasi administratorzy baz danych i bazy wydajności, moim zdaniem, muszą bardzo dobrze zacząć korzystać z odpowiednich narzędzi w celu zapewnienia optymalnego dostrajania indeksu wydajności dla dowolnego silnika bazy danych. Ponieważ skala, z którą mamy do czynienia i szybkość, z jaką rzeczy się poruszają, po prostu nie możemy tego zrobić ręcznie, a próba zrobienia tego niezmiennie może wprowadzić inne problemy z wydajnością, ponieważ możemy nie mieć doświadczenia w tej przestrzeni, która staramy się rozwiązać problem. I wierzę, że właśnie tutaj mamy zamiar przekazać Bertowi i mamy zamiar porozmawiać o tym, jak rozwiązali ten różnorodny problem i jakiego rodzaju rzeczy ich narzędzie może zrobić, szczególnie w świecie Oracle. I z tym, Bert, przekażę ci.

Bert Scalzo: Dziękuję. Witam wszystkich, nazywam się Bert Scalzo, pracuję dla IDERA. Jestem starszym menedżerem produktu dla niektórych naszych produktów bazodanowych. Będę dzisiaj demonstrować niektóre z nich. Ale chcę porozmawiać o indeksach, ponieważ zgadzam się ze wszystkim, co wszyscy tu powiedzieli, szczególnie z ostatnim slajdem, że indeksy są teraz tak złożone, że potrzebujesz narzędzia, i mam nadzieję cię przekonać. Tak więc projektowanie indeksu Oracle nie jest tak łatwe, jak kiedyś. Wielu ludzi nie będzie miało pewności siebie, kiedy spojrzą na opcje, i podoba mi się to, że wycofałem się z historii, „w tych sprawach jedyną pewnością jest to, że nic nie jest pewne”. myślę o indeksach w tych dniach, ponieważ nawet jeśli uważasz, że znasz odpowiedź, powinieneś indeksować X, Y lub Z, naprawdę nie możesz być pewien, dopóki jej nie wypróbujesz, ponieważ te optymalizatory czasami zachowują się inaczej niż się spodziewasz. I tak jest wiele prób i błędów przy projektowaniu indeksu. W dawnych dobrych czasach, jeśli potrzebny był indeks, na ogół były tylko dwa pytania lub jedno pytanie. Czy to było wyjątkowe czy nie? Być może pomyślałeś o innych rzeczach, takich jak: „Ile indeksów mogę mieć maksymalnie na jednej tabeli?”, Ponieważ zbyt wiele indeksów spowalnia wstawianie, aktualizowanie i usuwanie. Być może również byłeś w systemie bazy danych, miałeś ograniczenia co do liczby kolumn w indeksie wielokolumnowym, ponieważ czasami istniały ograniczenia na podstawie wielkości strony lub bloku silnika bazy danych, ale w rzeczywistości było to dość proste w dawnych dobrych czasach. Zindeksowałeś to albo nie. I tak naprawdę wszystko było na B-drzewie. Mogliśmy zezwolić na duplikaty lub nie, i to było o tym. Życie było dobre, życie było proste.

Cóż, dziś życie nie jest ani tak dobre, ani takie proste. Umieściłem czerwony znak Ghostbuster w sposób, w jaki to robiliśmy, ponieważ teraz mamy B-drzewo kontra bitmapa, w porównaniu do bitmapy. Za chwilę wyjaśnię, co niektóre z nich są. Klastrowane i nieklastrowane, niepowtarzalne lub duplikaty, kolejność przesyłania do przodu lub do tyłu, oparte na funkcjach, podzielone na partycje lub niepodzielone na partycje. Jeśli dotyczy partycjonowania, czy jest to partycjonowanie globalne czy lokalne? Wyjaśnię to również. Jest też coś o nazwie zorganizowana tabela indeksowana. I faktycznie jest pół tuzina innych, których odrzuciłem tutaj, ponieważ myślę, że mam już dość, aby przekonać cię, że indeksy są znacznie trudniejsze, niż mogłeś przypuszczać. W tym slajdzie zacznę od lewej górnej części diagramu i mam tabelę. Pierwszą rzeczą, którą muszę zdecydować, jest to, czy w zależności od wersji bazy danych i dostawcy bazy danych dopuszczają tabele obiektów, czy są tylko relacyjne? Zejdę po prawej stronie i powiem, że budujemy relacyjny stół. Teraz następne pytanie, które muszę sobie zadać, brzmi: czy jest to klaster? I wielu z was, którzy robili Oracle od pewnego czasu, pamięta, że klastry wróciły na Oracle 6 dni. Prawdopodobnie nie są już dzisiaj bardzo intensywnie używane, ale najpierw pozwól mi zejść z tej gałęzi.

Gdybym chciał umieścić tabelę w klastrze, musiałbym mieć indeks klastrowany w tej tabeli. Teraz, w Oracle, kiedy klastrowałeś tabelę, w zasadzie przechowywałeś wiersze lub wiersze były blisko siebie, gdzie wartości były podobne. Tak więc musisz mieć indeks klastrowany, a indeks klastrowany może być niepodzielony na partycje. Innymi słowy, tak naprawdę nie było żadnych metod partycjonowania dla tego, jak zrobiłbyś tabelę klastrową. To było ściśle niepodzielone na partycje. A ponieważ nie był podzielony na partycje, był globalny. Za chwilę wyjaśnię, co jest globalne. I to zawsze było B-drzewo. Innymi słowy, kiedy zszedłem z tej gałęzi, było to dość proste, nie miałem wielu możliwości. Teraz, jeśli wykonałem indeks nieklastrowany w tabeli klastrowanej, co było dozwolone w niektórych wersjach, znowu nie byłby podzielony na partycje; jeśli nie jest podzielony na partycje, wtedy jedynym wyborem jest globalny. A więc masz do wyboru B-drzewa lub bitmapę. Znowu zależało to od twojej wersji bazy danych. Ale teraz wróćmy do stołu relacyjnego i zacznijmy znowu schodzić po prawej stronie, a teraz będziemy mieć prosty, stary, regularny stół ze stosami: relacyjny. To będzie na stole. W pewnym sensie najpierw schodzę po prawej stronie. Więc to organizacja, kupa. Następne pytanie, które muszę sobie zadać, brzmi: „Czy chcę podzielić ten stół na partycje, czy nie?”. Czasami partycjonujesz się, ponieważ myślisz: „Hej, optymalizator będzie mądrzejszy w zakresie optymalizacji zapytań. „Jednak wiele DBA powie ci, że robisz to z powodów administracyjnych. Jeśli masz tabelę liczącą sto miliardów wierszy, jeśli podzielisz ją na partycje lub segmenty, gdy chcesz dodać dane do ostatniego segmentu, możesz upuścić i zindeksować tylko kilka milionów wierszy. Możesz wstawić te dane, a następnie odbudować ten indeks tylko na tym wiadrze.

Chociaż dla niektórych była to dobra technika optymalizacji, np. Eliminacja partycji, jej prawdziwą wartością była możliwość administrowania lub wykonywania zadań administracyjnych na mniejszych elementach. Kiedy idę na stos organizacyjny, pierwsze pytanie brzmiało: „Czy podzieliłem go na partycje, czy nie?”. Przejdźmy w lewo, nie podzielę tabeli na partycje. Teraz może to wydawać się dziwne, kiedy ci to powiem, ale możesz mieć tabelę niepodzieloną na partycje, a następnie nie możesz podzielić indeksu tak, jak jesteś przyzwyczajony, lub możesz podzielić indeks na partycje. Zatrzymaj się i pomyśl. Twój stół ma w zasadzie jedno wiadro, jak zawsze myślałeś, a jednak indeks będzie zawierał wiele wiader. Kiedy tak się dzieje, gdy występuje rozbieżność między liczbą segmentów a tabelą a liczbą segmentów w indeksie, to właśnie rozumie się przez globalny. I tak, jeśli tabela nie jest podzielona na partycje, a indeks podzielony na partycje, jest uważany za globalny, ponieważ występuje niezgodność. Teraz pozwól mi wrócić na stos organizacji i zejść na dół po stronie partycji. Teraz, jeśli mam tabelę partycji i powiedzmy, że tabela ma cztery segmenty, cztery partycje, mój indeks może mieć cztery segmenty, aby mój indeks pasował do projektu tabeli. A więc to już koniec, po prawej stronie. To byłoby uważane za lokalne. Indeks lokalny oznacza w zasadzie, że partycjonowanie tabeli i indeksu odbywa się w ten sam sposób i ma taką samą liczbę segmentów. A kiedy już mam lokalny indeks, może to być B-drzewo lub bitmapa, a ta zielona strzałka, która idzie w górę, pokazuje, że nawet jeśli jest to B-drzewo, nadal można dokonać wyboru. Może być oparty na funkcjach. Ponadto, jeśli jest to mapa bitowa, istnieją różne rodzaje map bitowych. Istnieje coś takiego jak indeks łączenia bitmap. Jeśli zajmujesz się magazynowaniem danych, jest to bardzo popularny rodzaj indeksu lub schematu gwiazdy. Tak się dzieje, że indeks ma identyfikatory wierszy dla tego, na co wskazuje w tabeli, ale będzie także miał identyfikatory wierszy dla tabel nadrzędnych, więc kiedy jesteś - musisz zaprojektować schemat gwiazdy i szukasz w tabeli faktów ten indeks w tabeli faktów wskazuje na dane, które Cię interesują, i na każdy wiersz w twoich wymiarach, więc musisz mieć tylko jeden indeks.

I tak naprawdę powstało z powodu czerwonej cegły, która była bazą danych wiele lat temu - wiele osób może o tym pamiętać. I tak, jeśli spojrzysz na to zdjęcie - i pamiętaj, że nie umieściłem wszystkiego na tym zdjęciu, ponieważ obraz byłby o wiele większy - wciąż istnieją dodatkowe problemy, które mam tutaj w tekście w prawej górnej części . Czy to indeks odwrotnego rzędu? I możesz powiedzieć: „Dlaczego miałbym chcieć indeksu odwrotnego zamówienia? To nie ma żadnego sensu. ”Cóż, jeśli jesteś w środowisku klastrowym w Oracle, jeśli robisz prawdziwe klastry aplikacji, jeśli utrzymujesz swoje indeksy w porządku, więc nie cofaj, jeśli masz dużo przetwarzania, które uderza te same wartości lub te same wartości indeksu, to co by się stało, to byś miał gorące obszary swojego B-drzewa. Oznacza to, że będziesz mieć spory i być może blokowanie, aby spróbować uzyskać dostęp do tych rzeczy, i robisz to między węzłami w sieci. Cóż, jeśli umieścisz indeks odwrotnej kolejności, teraz możesz to cofnąć. Możesz powiedzieć: „Cóż, podobne wartości znajdują się w różnych częściach drzew, więc nie mam moich oddzielnych węzłów konkurujących o gorące obszary w drzewie”. I zauważ też, że unikat nie działa z niektórymi opcjami . Jeśli spojrzysz, ponumerowałem trzy, pięć, osiem i jedenaście, więc są przypadki, w których nie mogę mieć unikalnego indeksu. Podobnie, są pewne przypadki, w których nie mogę mieć indeksu wstecznego, a następnie pojawiają się dodatkowe problemy, takie jak rejestrowanie lub brak rejestrowania oraz równoległe i nierównoległe. Mogę przypisać rzeczy do określonego obszaru w pamięci.

I to pomija wiele funkcji Oracle. Powiedziałbym, że kiedy spojrzysz na Oracle 12, prawdopodobnie jest jeszcze około pół tuzina rzeczy, które mógłbym dodać do tego obrazu. Indeksowanie jest naprawdę skomplikowane i zgadzam się z poprzednim mówcą, aby nawigować po nim i dokonać dobrego wyboru, potrzebujesz narzędzia. Być może potrzebujesz takiego zdjęcia i jakiejś metodologii, w jaki sposób wybierasz rzeczy i mam nadzieję, że to narzędzie pomoże ci się tam dostać. A potem będzie próba i błąd. Podczas indeksowania zawsze mówię ludziom: „patrz, zanim skoczysz”. I wtedy możesz zobaczyć małego psa, skacze bez patrzenia, skończy w wodzie z rekinem lub facet przygotowuje się do skoku do wody i on sam się przebije. Musisz pomyśleć o indeksowaniu, ponieważ utworzenie indeksu nie zawsze oznacza, że wszystko będzie lepiej. W rzeczywistości utworzenie indeksu może spowolnić proces. Wydajność zapytań może być o rząd wielkości lepsza, z jednym wyborem nad drugim. I dam ci dobry przykład. Jeśli wykonujesz schemat gwiazdy, a na tablicach wymiarów używasz indeksów bitmap w jednym przypadku, a w innym przypadku mówisz: „Użyję indeksów B-drzewa”, masz mapę bitową w porównaniu z B- drzewo. Mogę powiedzieć, że jedno rozwiązanie będzie o rząd wielkości, a może o kilka rzędów wielkości szybsze od drugiego. Należy jednak pamiętać, co działa w jednym środowisku, na przykład w środowisku hurtowni danych, prawdopodobnie nie jest dobrym wyborem w środowisku OLTP.

Na przykład, jeśli weźmiesz tabelę transakcyjną i umieścisz indeksy mapy bitowej w tabeli transakcyjnej, obliczenie i zresetowanie map bitowych, tych długich łańcuchów itd. Jest drogie, więc w tabeli OLTP możesz uderzyć w tabelę tak mocno, że mapa bitowa indeks może ulec uszkodzeniu i spowolnić system, ponieważ po prostu nie są przeznaczone do aktualizacji. Świetnie nadają się do szybkiego dostępu, ale nie nadają się do aktualizacji. Myślę, że indeks wymaga prób i błędów. Naprawdę nie ma już złotej reguły - w tym równaniu jest zbyt wiele różnych zmiennych, aby ostatecznie wiedzieć - i ostatecznie będziesz musiał spojrzeć na wykonanie lub wyjaśnić plany w bazie danych, aby sprawdzić, czy dokonujesz dobrych wyborów. A czasami analiza planu może być niemal nauką samą w sobie. Nie zamierzam tego dzisiaj omawiać - to kolejny temat - ale nie bierz projektu indeksu za pewnik. Istnieją uzasadnione powody, dla których istnieją wszystkie te szalone typy indeksów, które pokazałem wam na poprzednim zdjęciu, i o których mówił poprzedni mówca. Nie zostały one utworzone, ponieważ fajną funkcją było umieszczenie gdzieś listy kontrolnej dla dostawcy bazy danych; istnieją przypadki użycia lub scenariusze, w których te indeksy są ważne i będą miały znaczącą różnicę. Teraz pokażę kilka przykładów różnego rodzaju indeksów w jednym z naszych narzędzi. Pozwól mi tylko podnieść ekran, żebyś mógł go zobaczyć. Okej, więc tutaj siedzę w środku - pozwól mi zminimalizować tę aplikację. Siedzę w VMware i korzystam z VM Windows Server 2012.

I widzisz, mam prawie każde narzędzie znane człowiekowi. Jako menedżer produktu muszę być świadomy swojej konkurencji, więc nie chodzi tylko o to, jakie mam narzędzia, ale co robią moi konkurenci? Mamy tutaj to narzędzie o nazwie DBArtisan, które już uruchomiłem, ale idę - więc po prostu o tym wspomnę. To, co możesz zobaczyć, to naprawdę miłe narzędzie, ponieważ zamiast korzystać, powiedzmy, menedżer korporacyjny dla Oracle i SQL Management Studio dla SQL Server, MySQL Workbench dla MySQL i dwanaście innych baz danych, które obsługujemy, cóż, mam wszystkie bazy danych wbudowane w to jedno narzędzie. Jest DB2, MySQL, Oracle, Postgres, SQL Server i Sybase, i to - Mam tylko sześć baz danych w tej konkretnej rzeczy, ponieważ nie mogę - narzędzie obsługuje dwanaście baz danych, ale moja biedna maszyna wirtualna, jednocześnie działa sześć baz danych i próbuje zrobić demo, to tyle, ile mój sprzęt ułatwi. Wróćmy teraz do Wyroczni, a jeśli zauważysz, wszystkie te rzeczy są takie same. Jeśli chcę zmierzyć moją wydajność w programie DB2, mam te same wybory, co w przypadku Oracle. Teraz pod przykryciem robimy wiele różnych rzeczy, więc nie musisz wiedzieć, co się dzieje, ale zapewniamy spójny interfejs, dzięki czemu możesz być ekspertem w wielu platformach baz danych. Obejmowałoby to pracę z indeksami, tematem tej dyskusji.

Pozwól mi tu przyjść i zacznijmy od przejrzenia niektórych tabel, a mam bazę filmów z kilkoma tabelami. A jeśli spojrzę na konkretną tabelę, na przykład tabelę klienta, kiedy ją tu przywołuję, widzę mój projekt tabeli, oto moje kolumny w mojej tabeli i oto informacje o każdej kolumnie. Mam właściwości tabeli, ale zwróć uwagę, że mam tutaj kartę indeksów i widzę tutaj indeksy tabeli. Zauważ, że jednym z tych indeksów jest mój indeks PK, mój klucz podstawowy. Te inne wydają się być tylko indeksami służącymi poprawie dostępu do zapytań, być może sprawdzamy je według imienia lub nazwiska albo patrzymy na telefony i kody pocztowe. A jeśli wybiorę konkretny indeks, taki jak ten kod pocztowy, i kliknę go dwukrotnie, teraz widzę, że, hej, to nie jest unikalny indeks, a oto niektóre inne typy, bitmapy, nieunikalne, unikalne, bez względu na to, czy jest posortowane, czy to logowanie, czy nie, czy to odwrotna kolejność, czy jest to podstawa funkcji. Och, tutaj jest fajny, którego nie opisałem. Możesz mieć niewidoczne indeksy. I powiedziałbyś: „Dlaczego, do cholery, chciałbym zrobić niewidzialny indeks?” Cóż, dam ci dobry przykład. Jesteś w systemie produkcyjnym i masz problem z wydajnością i nie masz pewności, że utworzenie indeksu rozwiąże problem, więc nie chcesz tworzyć indeksu i spowalniać produkcji, ale w jakiś sposób chcesz móc to przetestować. Możesz utworzyć indeks produkcyjny jako niewidoczny, co oznacza, że niewiele kodów aplikacji wywołujących optymalizator użyje tego indeksu. Został utworzony, jest poprawny, ale nie będzie używany. Następnie możesz wziąć zapytanie, które według ciebie mogłoby pomóc, lub szereg zapytań, i możesz wskazać i powiedzieć: „Hej, optymalizatorze, jest tam niewidoczny indeks, którego chcę, abyś używał i pozwolił wiem, czy zrobiłem coś lepszego. ”A teraz przetestowałem coś w produkcji, ale nie zepsułem działających aplikacji. Takie zastosowanie ma niewidoczny indeks. To brzmi głupio, kiedy o tym słyszysz, ale ma swoje zastosowanie.

Możemy również w indeksach określić, czy są one równoległe, a także ile wystąpień są równoległe. Teraz w środowisku klastrowym lub nierzeczywistym klastra aplikacji, więc równoległy tryb bez stelaża oznaczałby, ile podprocesów może wywołać moje zapytanie, aby spróbować, i procesów roboczych, aby spróbować zrealizować to szybciej lub szybciej . I równoległymi instancjami byłoby, jeśli jestem w prawdziwym klastrze aplikacji, powiedzmy, że mam dziesięć węzłów, na ile węzłów mogę dzielić pracę? Może to cztery z dziesięciu, a na każdym z nich cztery podprocesy. To jest przykład. A potem mamy kompresję klucza. Czy faktycznie można kompresować indeksy? Tak lub nie. A potem oczywiście masz parametry przechowywania, które możesz określić w indeksach. Teraz ich nie omówiłem, ponieważ tak naprawdę są one bardziej parametrem pamięci niż problemem indeksu. I w końcu musimy zdecydować, czy utworzyć te partycjonowane czy niepodzielone na partycje. Pozwól mi to upuścić na chwilę. Przejdę do innego schematu. To jest schemat gwiazdy i na przykład ta tabela okresów jest tabelą wymiarów. Jeśli kiedykolwiek robiłeś projekt schematu gwiazdy, zwykle masz wymiar czasu, a więc w tej bazie danych i schemacie gwiazdy okres jest wymiarem czasu. Teraz wiem, że będzie to wyglądać zabawnie, powiesz: „Ojej, spójrz na wszystkie te kolumny - czy facet słyszał kiedyś o normalizacji?”. Cóż, kiedy jesteś w hurtowni danych lub projekcie schematu gwiazdy, zazwyczaj mają nie - masz tabele, na które zwykła osoba patrzy i mówi: „Ojej, nie są one zbyt dobrze zaprojektowane”. Ale tak właśnie robisz w środowisku hurtowni danych.

Teraz patrz, co się stanie, ponieważ, okej, są wszystkie te kolumny, spójrz na to, mam indeks dla każdej kolumny. Teraz w środowisku OLTP byłoby to niemożliwe. Spowolniłoby to wszystkie moje operacje. W środowisku hurtowni danych upuszczałbym je podczas cyklów ładowania partii. Załaduj bez obciążenia lub indeksów, a ja odtworzę indeksy. A jeśli podzielę tabelę na partycje, to zamiast konieczności upuszczania indeksu dla każdego segmentu w tabeli, mógłbym po prostu upuścić indeks na segmencie lub segmentach, w których dane będą wprowadzane podczas tego cyklu ładowania wsadowego. Następnie odtwórz tylko część indeksu dla tych segmentów. Dzięki temu jest bardzo łatwy w zarządzaniu. A jeśli spojrzę - oto kolumna zatytułowana „Flaga świąteczna” i zasadniczo jest to tak lub nie. Zauważ, że jest to indeks bitmapowy i dla większości z was powiesz: „Cóż, to ma sens”. Tak lub nie, T lub N, są tylko dwie wartości, które mają sens. A ponieważ kiedy czytasz dokumentację dotyczącą indeksów bitmapowych, zawsze mówią ci, aby wybrać coś o niskiej liczności.

Teraz pozwól mi przejść do jednej z moich tabel faktów, więc tutaj mamy moje zamówienia. I to są moje zamówienia na dzień. Przekonasz się teraz, że znowu mam sporo kolumn i znowu, będę miał więcej niż kilka indeksów. I tutaj mamy coś, co nazywa się uniwersalnym kodem cenowym. To było dla sklepu detalicznego, więc znasz te małe kody kreskowe, gdy kupujesz coś w sklepie, jest to uniwersalny kod ceny. Teraz istnieją miliony uniwersalnych kodów cen. Teraz, dla tej konkretnej firmy, która sprzedawała rzeczy, mieli prawdopodobnie od 1, 7 do 2 milionów uniwersalnych kodów cenowych, więc spodziewacie się, że nie będzie to indeks bitmapowy, ponieważ 1, 7 miliona różnych wartości brzmi jak wysoka kardynalność. Ale w rzeczywistości w środowisku hurtowni danych powinna to być mapa bitowa. Teraz wyjaśnię dlaczego. Cóż, dla tego uniwersalnego kodu cenowego może być 1, 7 miliona różnych wartości, liczba wierszy w tej tabeli zamówień wynosi od setek milionów do miliardów wierszy. Mój indeks to niska liczność w porównaniu do wielkości lub liczności tabeli. To sprawia, że jest to niska liczność. To sprawia, że indeks bitmapowy jest przydatny, mimo że jest sprzeczny z intuicją i ma 1, 7 miliona różnych wartości, które wybrałbyś tutaj. Teraz, gdybym wiedział, że chcę użyć indeksu dołączania map bitowych, obecnie produkt tego nie obsługuje, otrzymuję ten dodatek w następnej wersji, ale to byłaby kolejna alternatywa tutaj. Pamiętaj, że w schemacie gwiaździstym indeks bitmapowy znajdowałby się w tabeli faktów, a jeden indeks w drzewie B wskazywałby na wiersz w tabeli faktów, a następnie na każdy wiersz widoczny w tabeli wymiarów dla tego faktu . Masz więc inną opcję. A więc, zobaczmy, chcę teraz wyjść z tabel i chcę ci tylko szybko pokazać, że mam te same informacje, pod indeksami, i zamierzam zrobić to samo podstawowe.

Powodem, dla którego o tym wspomniałem, jest to, że można zauważyć, że nie ma tutaj kluczy podstawowych. Klucze podstawowe są wykonywane z ograniczeniem klucza, więc w rzeczywistości są objęte definicjami ograniczeń. Byłyby to indeksy, które nie są częścią ograniczenia. Teraz możesz powiedzieć: „Cóż, poczekaj chwilę, może to wyglądać na klucz obcy, a klucz obcy jest ograniczeniem”, ale klucze obce i większość baz danych nie tworzy automatycznie indeksu w kolumnie klucza obcego, nawet jeśli jest to wskazane i proszę bardzo - znów mam te same wybory. A jeśli chcę zmienić tylko kompresję, mogę to zrobić.

Teraz kompresja działa tylko na indeksie B-drzewa. Pozwala to, gdy spojrzysz na różne węzły B-drzewa, pozwala to na kompresję niektórych wartości. Naprawdę nie jest to kompresja jak kompresja tabeli, jest to kompresja tego, co jest przechowywane w drzewie B w węzłach innych niż liście. Nie oszczędza mnóstwo miejsca, ale może mieć znaczenie. Zauważyłem, że zbliżam się do czasu, więc chcę wrócić i przestać się dzielić. I mamy nasz produkt na czternastodniowy okres próbny na idera.com. Jest to całkiem dobry produkt, szczególnie jeśli pracujesz z wieloma platformami baz danych. Jeśli pracujesz z dwiema lub trzema różnymi bazami danych, to narzędzie znacznie ułatwi Ci życie. Mamy narzędzia, które pomogą Ci w projektowaniu i wyborze indeksu, mamy narzędzie o nazwie DB Optimizer. Po prostu nie mogłem tego dziś opisać, byłoby to zbyt wiele. A jeśli chcesz się ze mną skontaktować, tam jest mój adres e-mail, możesz go złapać na mój prywatny e-mail, a ja mam blogi, mam stronę internetową i blogi oraz profil LinkedIn. Więc skontaktuj się ze mną na dowolny temat, nawet jeśli nie jest to związane z produktem, jeśli chcesz po prostu rozmawiać o bazach danych, jestem geekiem w sercu i uwielbiam gadać o technobabble.

Eric Kavanagh: Dobra, cóż, Dez, Robin, jestem pewien, że każdy z was ma przynajmniej kilka pytań, zostało nam jeszcze kilka minut. Dez, co myślisz?

Dez Blanchfield: Mam jedno świetne pytanie, które muszę zadać, to było w mojej głowie. Jaki jest najbardziej szalony scenariusz, jaki widziałeś? Przeczytałem twojego bloga, śledzę cię uważnie, jesteś prawdopodobnie jedną z niewielu osób, które żyły w prawie każdym mało prawdopodobnym, i myślę, że dr Robin Bloor jest drugim, którego spotkałem moje życie. Ale wiesz, prawdopodobnie widziałeś każdy szalony scenariusz, jakie są najbardziej szalone scenariusze, które widziałeś, na które natknąłeś się i jak ludzie, którzy po prostu nie mogli sobie poradzić, udało ci się przejść i wykonywać sztuczki umysłowe Jedi z tym całym DBArtisan?

Bert Scalzo: Kiedyś mieliśmy klienta, który podczas projektowania bazy danych bardzo dokładnie myślał, jak myślą w projekcie układu plików, i tak dalej - po normalizacji bazy danych, pierwszą rzeczą, którą próbujesz zrobić, to się pozbyć powtarzających się grup. Cóż, mieli kolumnę i zrobili z niej długi, BLOB lub CLOB, i umieściliby w niej wartość, numer jeden, średnik, wartość numer dwa, średnik, wartość liczby, średnik i mieliby tysiące wartości tam, ale musieli przeszukać tę kolumnę i stwierdzili: „Dlaczego to działa tak wolno?” A ja mówię: „Cóż, nie możesz stworzyć indeksu tego, co zrobiłeś, to po prostu niedozwolone. ”Tak więc pokazaliśmy im, korzystając z planów, że powinni oni znormalizować ten stół. Nie dlatego, że normalizacja jest jakimś ćwiczeniem akademickim, które poprawia sytuację, ale dlatego, że chcieli zapytania na tym polu, co oznaczało, że chcieli mieć możliwość zindeksowania go, a ty nie mogłeś zindeksować go na grupie powtarzającej się, a przynajmniej nie łatwo . I to chyba najgorsza rzecz, jaką kiedykolwiek widziałem.

Dez Blanchfield: Tak, ciekawe, jak często się zdarza, myślę, że wyzwanie z bazami danych, ludzie zapominają, że to nauka. I są ludzie, którzy robią stopnie naukowe i doktoraty w tej całej przestrzeni, piszą na niej papiery, a ty napisałeś całą łup, w tym swoje podręczniki TOAD i inne rzeczy z pamięci. Trend w kierunku „dużych zbiorów danych” w formie wyceny po wycenie - widzę, że wielu ludzi zapomina o podstawach architektury baz danych i technologii baz danych, nauki baz danych, jeśli chcesz. Co widzisz w tej dziedzinie, jeśli chodzi o odejście od tradycyjnych platform bazodanowych i tradycyjnego myślenia o bazach danych, które skutecznie przykuliśmy do ziemi, a było to jedynie dostosowanie wydajności i skalowanie. Czy widzisz, jak wiele osób uczy się ponownie i ma doświadczenie, gdy po prostu tam siedzą i mają chwilę „a-ha”, jak moment eureki, kiedy zdają sobie sprawę, że te duże dane to tak naprawdę naprawdę duże bazy danych? Czy to coś na zewnątrz, a ludzie ci odpowiadają i pytają: „Zapomnieliśmy, co wiemy i czy możesz nas sprowadzić z ciemnej strony?”

Bert Scalzo: Cóż, nie, i to jest okropne, że trzeba przyznać, ale dostawcy relacyjnych baz danych wypili również Kool-Aid. Jeśli pamiętasz, nie wiem, jakieś dziesięć lat temu, zaczęliśmy umieszczać nieustrukturyzowane dane w relacyjnych bazach danych, co było czymś dziwnym do zrobienia, a następnie dane, relacyjne bazy danych, teraz dodają typ NoSQL rzeczy. W rzeczywistości w Oracle 12, CR2 - wiem, że jeszcze go nie ma - ale jeśli spojrzysz na wersję beta, jeśli jesteś w wersji beta, obsługuje dzielenie na fragmenty. I tak, teraz masz relacyjną bazę danych, która nie dodała koncepcji z shardowania NoSQL. I tak, moment „a-ha” wydaje się być bardziej dla ludzi po stronie relacyjnej, którzy idą „a-ha”. Nikt nigdy nie zrobi tego dobrze, nawet menedżerowie baz danych, więc mamy muszę przejść i dołączyć do ciemnej strony.

Dez Blanchfield: Racja, więc mówisz o przejściu na wiele niechlujnych danych, o ile dobrze rozumiem, umieszczając się w tym, co nazywamy teraz platformami dużych zbiorów danych, co jest dość zabawne, ponieważ są nie tak stare, ale czy to nie znaczy, że ponownie koncentrują się na tym, co robią ze swoją relacyjną bazą danych, aby uzyskać większy zwrot z inwestycji?

Bert Scalzo: Nie, zazwyczaj, jeśli mają taką potrzebę - byłoby to zacytowanie „potrzeby dużego typu danych”, stwierdzili, że zamiast iść na inną platformę bazy danych i zrobić coś w sposób -relacyjny sposób, dostawcy baz danych udostępniają im te same nierelacyjne techniki w relacyjnej bazie danych, aby wykonywać te czynności. Mam na myśli, że dobrym przykładem jest, jeśli masz nieustrukturyzowane dane, takie jak typ danych JSON lub jakiś inny złożony typ danych, który ma znaczenie osadzone w samych danych, dostawcy baz danych nie tylko to obsługują, ale dadzą ci ACID zgodność z nieustrukturyzowanymi danymi. Relacyjne bazy danych wykorzystują nowsze techniki i technologie, a zatem znowu „a-ha” wydaje się bardziej nie takie, że: „Hej, my, twórcy aplikacji, czegoś się nauczyliśmy i musimy się tego ponownie nauczyć”, to „Hej, robimy to teraz, w jaki sposób mogę to zrobić w tradycyjnie relacyjnej bazie danych i zrobić to tak, jak tutaj w tej bazie danych? ”, która staje się coraz bardziej powszechna i, jak powiedziałem, sami dostawcy baz danych umożliwiają że.

Dez Blanchfield: Racja, kim są tradycyjni podejrzani w tej przestrzeni dla narzędzia DBArtisan i tym podobnych? Odrobiłem pracę domową na temat tego, co ostatnio napisałeś, i z pamięci napisałeś coś, myślę, że był to jeden z twoich blogów, dotyczący ekstremalnej wydajności baz danych w świecie Oracle. Nie pamiętam, kiedy to było, myślę, że kiedyś w tym roku z pamięci, lub z końca ubiegłego roku napisałeś to. I wydawało mi się, że był to tradycyjny, zwykle podejrzany o temat, o którym dzisiaj mówimy, gdzie ludzie przechodzą do bardzo dużych środowisk baz danych i szukają tego, co nazywacie ekstremalnymi korzyściami. Kim są zwykle podejrzani, którzy widzą, że biorą DBArtisan i dobrze go wykorzystują?

Bert Scalzo: Cóż, mamy wielu klientów, tak naprawdę, dzisiaj współpracowałem z bardzo dużą agencją rządową, która - i mają dosłownie prawie 1000 kopii naszego oprogramowania, ponieważ pozwala to ludziom skupić się na tym, co robią. robię, a nie jak to zrobić. I jest w porządku, to znaczy, każdy powinien wiedzieć, jak coś zrobić, ale produktywność wykonuje „to”. Jeśli firma poprosi mnie o wykonanie zadania, to jest to wszystko, co ich interesuje. Kiedy dostałem znacznik wyboru z informacją, kiedy zadanie zostało wykonane? Nie jaką techniką lub jakim technobabble użyłem, żeby się tam dostać. A zatem nasze narzędzie pozwala im skupić się na tym, co pozwala im być o wiele bardziej produktywne, i to naprawdę ogromna zaleta, i jak powiedziałem, niektóre bazy danych oferują narzędzie tylko dla ich platformy baz danych. Oferujemy go dla dwunastu platform baz danych. Mam ten sam przepływ pracy, ten sam graficzny interfejs użytkownika, te same nawigacje. Jeśli wiesz, jak przyznać uprawnienia użytkownikowi lub jak utworzyć tabelę lub utworzyć indeks w bazie danych, możesz to zrobić we wszystkich dwunastu, ponieważ jest to ten sam wygląd i działanie oraz ten sam przepływ pracy. Ma to ogromną wartość dla naszych klientów.

Dez Blanchfield: Tak, chyba ludzie chcą uzyskać o wiele więcej za swoje zasoby ludzkie. Minęły już czasy posiadania indywidualnego specjalisty od Oracle, Ingres i DB2. Oczekuje się, że ludzie będą Jackiem wszystkich branż, więc myślę, że to coś absolutnie uratowało im życie.

Jeszcze jedna ostatnia rzecz, zanim przekażę ją doktorowi Robin Bloor. Wspomniałeś, że istnieje czternaście dni do pobrania za darmo, co się dzieje - jeśli mam zamiar iść dalej i mam zamiar to zrobić, przy okazji, umieszczę to w laboratorium technologicznym Bloor i zakręcę tym i weź się w garść - nie miałem okazji tego zrobić przed dniem dzisiejszym. Wspomniałeś o czternastodniowym okresie próbnym, powiedziałeś, że używasz go na maszynie wirtualnej na swoim komputerze, zakładam, że to laptop. Jakie są, jak wygląda konfiguracja na poziomie podstawowym, aby ktoś mógł się zorientować i skorzystać z czternastodniowej wersji próbnej, tuż przed oddaniem Robinowi jego pytań?

Bert Scalzo: Dowolne środowisko Windows, więc Windows 7, maszyna wirtualna z jednym procesorem i czterema gigabajtami pamięci. Nie jesteśmy naprawdę grubym ani drogim narzędziem. Teraz, jeśli chcesz uruchomić serwer bazy danych na tej samej maszynie wirtualnej w tym samym systemie Windows, tak, musisz dodać więcej, ale jeśli korzystasz z bazy danych na serwerze bazy danych lub na oddzielnej maszynie wirtualnej, maszynę wirtualną należy załadować i nasz produkt jest bardzo lekki: jeden procesor, cztery gigabajty pamięci, prawie każda wersja systemu Windows - i obsługujemy instalacje trzydzieści dwa i sześćdziesiąt cztery bity. Ale musisz zainstalować klienta dostawcy bazy danych. Jeśli więc chcesz połączyć się z Oracle, musisz zainstalować klienta sieci SQL, ponieważ tego właśnie wymaga Oracle, aby móc rozmawiać z bazą danych.

Dez Blanchfield: Brzmi całkiem prosto. Myślę, że bardziej niż cokolwiek innego, co mam nadzieję, że ludzie zabiorą, poza tym, że to narzędzie uratuje im życie, to to, że powinni pobrać, pobrać i bawić się nim, biorąc pod uwagę, że oferujecie czternastodniowy bezpłatny okres próbny. I może działać na ich bieżącym laptopie bez instalowania żadnych dodatkowych elementów, ponieważ jeśli już administrują bazami danych, już pracują z bazami danych, mają wszystkie te narzędzia i czy działają na lokalnej maszynie wirtualnej, czy na lokalny pulpit, wygląda na to, że instalacja jest łatwa i bezproblemowa. Więc bardzo polecam ludziom to zrobić.

Robin, jestem pewien, że masz pytania, a Eric, prawdopodobnie masz trochę od publiczności, więc Robin, a może przekażę ci to, a potem z powrotem do Erica?

Robin Bloor: Tak, dobrze, cóż, mam coś do powiedzenia, to znaczy zawsze uważałem ten obszar za fascynujący, ponieważ był - przeciąłem mu zęby. Ale prawda jest taka, że prawdopodobnie od około 1998 r., 1999 r. Traciłem już to, do czego Oracle jest zdolna. I znałem Sybase i Microsoft SQL Server, oba są dość proste w porównaniu do tego, co Oracle może zrobić. Rozśmieszyłeś mnie, kiedy - to znaczy, zakryłem usta, kiedy zacząłeś mówić o odłamkach. Oracle robiła to wcześniej. Oracle wprowadzono w pewnym momencie, denerwowali się relacją obiektowo-relacyjną, więc wprowadzili możliwość tworzenia pewnego rodzaju notacji obiektowej i przechowywania obiektów w Oracle, a ja rozmawiałem z jednym z ich inżynierów, coś w rodzaju kilku lata po wprowadzeniu go, a ja zapytałem, ile osób go używało, i powiedział, że myślę, że dwóch klientów wypróbowało go i to było to. I myślę, że to samo stanie się, jeśli zaczną próbować robić trendy w NoSQL. Wiesz, myślę, że to pomyłka, to znaczy, jestem trochę zainteresowany twoimi myślami. Z pewnością - piją Kool-Aid. Wydaje im się, że muszą być w stanie wysuwać roszczenia podobne do dużych baz danych NoSQL, takich jak Cassandra, ale wiesz, czy to ma dla ciebie jakiś sens?

Bert Scalzo: Nie, trafiłeś w sedno. Według mnie wybrałbym relacyjnego dostawcę, takiego jak Oracle, SQL Server, DB2 lub Postgres, ale jeśli mam zrobić coś, co nie jest relacyjne, w przestrzeni dużych zbiorów danych lub NoSQL wybiorę odpowiednie narzędzie do właściwej pracy. I nie sądzę, że naturalnie najpierw trafiłbym do mojego relacyjnego dostawcy bazy danych. A następnie dodajesz do tego inne zmarszczki, czyli, co jest dostępne w chmurze? Tak wiele osób chce pozbyć się swoich baz danych. Następnie musisz spojrzeć na dostawcę usług w chmurze i powiedzieć: „W porządku, co oferujesz, jakie bazy danych masz dla mnie dostępne, które odpowiadają moim potrzebom i jak są nadające się do sprzedaży, i szczerze mówiąc, jaka jest stawka lub opłata za korzystanie z tej bazy danych w chmurze na godzinę lub na dzień. A na gigabajt lub terabajt? ”. A może znajdziesz niektóre ze stosunkowo nowszych baz danych, takich jak Mongo lub Cassandra, może ich stawki są tańsze, więc jeśli zamierzasz robić duże zbiory danych typu petitabajt, możesz muszę - tylko z punktu widzenia kosztów - wziąć pod uwagę bazy danych NoSQL w chmurze, ponieważ mogą one być najbardziej opłacalnym sposobem na zrobienie tego.

Robin Bloor: Tak, racja. Mam na myśli, mój rodzaj - relacja z relacyjnych baz danych w moim doświadczeniu - która jest wystarczająco długa, aby mieć blizny, to na pewno - istnieje wiele zdrowych rozsądków, że jeśli zaczniesz ją stosować i - rozumiesz, czym jest relacja, że, To znaczy, pamiętam, że kiedyś zrobiłem konsultacje z jednym klientem. Zaprowadzili mnie do pokoju, zrobili coś w rodzaju schematu podmiotowego i stworzyli trzecią normalną formę, model tego, jak wyglądały podstawowe systemy firmy. Było tam około dwustu czterdziestu stołów i powiedzieli: „Co o tym sądzisz? Zbudujemy bazę danych na ten temat ”i powiedzieliśmy„ Co o tym sądzisz? ”Odpowiedziałem:„ Nie sądzę, żeby to zadziałało ”. I to jest w porządku, wiesz, ponieważ kończyły się w górę, aby utworzyć określoną strukturę w ramach połączeń jedenastokierunkowych. I to jest coś, co należy zrozumieć na temat relacji. Więc jestem trochę zainteresowany, jeśli chodzi o to, ile złego projektu napotkasz. Mam na myśli, że nie mam żadnych problemów z DBArtisan - robi bardzo rozsądne rzeczy, a fakt, że można wyświetlać na wielu platformach, myślę, że jest cudowny - ale ile można spotkać tam, gdzie jest problem z projektem gdzie ludzie mogliby rozwiązać wszelkiego rodzaju bóle serca, gdyby sprowadzili się do schematu gwiezdnego, a nie dostali śnieżynki, rozumiesz?

Bert Scalzo: Cóż, nie chcę brzmieć jak zarozumiały lub arogancki, ale powiedziałbym częściej. Oczywiście większość baz danych, z którymi się tam angażuję, ma problemy lub problemy. Co jest dobre, ponieważ nasze narzędzia, takie jak narzędzie optymalizujące bazę danych, mogą pomóc im rozwiązać te problemy, ale, co naprawdę jest dla mnie śmieszne, wiele problemów to te same proste problemy w kółko. Pewnego dnia współpracowałem z klientem, który miał zapytanie o przyłączenie w jedenastoprocentowy sposób, i mówię: „Okej, dlaczego nie użyłeś klauzuli z?”, A oni mówią: „No cóż, nie nie wiem, co to jest. ”A potem powiedziałem:„ I spójrz na swoje podselekcje tutaj na swoje skorelowane i nieskorelowane ”, powiedziałem:„ W niektórych przypadkach masz klauzulę where na najgłębszym poziomie, odniesienie do tabeli z zewnętrznej strony. ”Powiedziałem:„ Przenieś to na odpowiedni poziom, nie osadzaj go głębiej, niż to konieczne, pomylisz optymalizator ”. Kilka drobnych poprawek zajęło nam coś, co działało około dwóch godzin, i zmniejszyło to do dziesięciu minut, i było po prostu - w takim przypadku nie zrobiliśmy nic innego, jak poprawić SQL, który napisali. Myślę, że problem polega na tym, że wiele uniwersytetów i wielu ludzi, którzy uczą się programowania w środowisku pozaakademickim, uczą się tego jako procesów w czasie rejestrowanym lub procesów zorientowanych na rząd, a relacja jest zbiorem zorientowanym przez naturę, więc ty muszę myśleć w zestawach, aby napisać dobry SQL.

Robin Bloor: Tak, myślę, że dokładnie tak jest. I musicie zrozumieć, to jest tak, że ludzie powinni znać ABC takich rzeczy. To nie ma znaczenia Nie będziesz w stanie robić racjonalnych rzeczy, jeśli nie zdajesz sobie sprawy, że nawet dobrze zaprojektowana, dobrze wymodelowana baza danych, przyłączenia będą wymagały czasu, sortowanie będzie wymagać czasu. Robią to, ponieważ świat nigdy nie znalazł sposobu, aby je przyspieszyć. Znaleźli sposoby organizowania danych, aby działały szybciej niż w innym przypadku, a entuzjazm, który muszę powiedzieć o bazach danych NoSQL, polega na tym, że unikają łączenia. Po prostu zaczynają budować bazy danych z tym samym rozkładem danych, ponieważ jeśli przyłączycie się do którejkolwiek z baz danych NoSQL, będą one mocno ssać. Nie sądzisz?

Bert Scalzo: Och, absolutnie. I muszę się śmiać, ponieważ zacząłem wiele lat temu przed relacyjnymi bazami danych, a kiedy Ingres był RTI, Relational Technology Institute, i nie mieliśmy SQL, mieliśmy języki relacyjne sprzed SQL. Myślę, że w Ingres nazywało się to wtedy Quel. Więc czerpałeś ze starych paradygmatów baz danych, takich jak sieć i wyższy graficzny lub hierarchiczny, i przechodzisz przez paradygmaty relacyjne po kilku dekadach i teraz wydaje mi się, że wracamy do niemal hierarchicznej. To prawie tak, jakbyśmy cofnęli.

Robin Bloor: Tak, racja. Lepiej oddaję Ericowi, zużywam zbyt dużo czasu, ale czy mamy jakieś pytania od publiczności, Eric?

Eric Kavanagh: Mamy, mamy kilka. Jedziemy tu trochę za długo, ale rzucę ci parę. Mieliśmy kilka pytań dotyczących niewidzialnych indeksów. Jedno pytanie brzmiało: „Czy ktoś musi użyć twojego narzędzia, aby je zobaczyć?” Kolejne pytanie brzmiało: „A co, jeśli jesteś ślepy?”

Bert Scalzo: To dobrze.

Eric Kavanagh: Ciekawe pytanie, więc po prostu FYI.

Bert Scalzo: Nie, nie musisz mieć naszych narzędzi. To funkcja Oracle, indeks niewidzialnych. Zasadniczo w słowniku danych Oracle zachowuje fragment metadanych z napisem „Optymalizator, zignoruj ten indeks. Jest tutaj, ale jeśli nie zostaniesz fizycznie poinstruowany za pomocą podpowiedzi w podpowiedzi optymalizatora w poleceniu SQL, nie używaj tego. ”A więc nie, nie musisz mieć naszych narzędzi i pod każdym względem jest zwykłym starym indeksem, można go zobaczyć w dowolnym narzędziu, po prostu optymalizator powie: „Zignorujemy go podczas normalnego przetwarzania zapytań”. Musisz go ukierunkować, jeśli chcesz go wykorzystać. Jest to bardzo przydatne w przypadku opisanego przeze mnie scenariusza, który polega na tym, że jeśli chcesz zbudować indeks produkcyjny, ale nie ryzykujesz zerwaniem raportów lub rzeczy, które już działają, ale chcesz je przetestować, możesz to zrobić. To jest najbardziej przydatne.

Eric Kavanagh: To dobre rzeczy, a potem pojawiło się kolejne dobre pytanie. „A co z niektórymi z tych nowych baz danych w pamięci? Jak technologia baz danych w pamięci zmienia grę pod względem indeksowania? ”

Bert Scalzo: Cóż, my - teraz to dobrze, cieszę się, że ktoś zadał to pytanie, będziemy musieli iść jeszcze pół godziny. Nie, w pamięci zależy to od dostawcy bazy danych. Teraz normalnie mówię tylko o pochwałach wszystkiego, co robi Oracle, ponieważ jest to niesamowita technologia, którą zbudowali, ale kiedy odrywasz się pod kołdrę i patrzysz na to, co w pamięci jest w Oracle, w Oracle baza danych, w rzeczywistości jest to nadal przechowywana pamięć wierszy na dysku i zostanie załadowana pamięć kolumna w pamięci, a jeśli nie będzie wystarczającej pamięci do przechowywania całej tabeli, nastąpi powrót do części; nie zmieści się w pamięci, aby zrobić to zapisywanie wierszy, a więc mógłbyś faktycznie dokonać wyboru względem tabeli i dla połowy tabeli, używasz indeksowania uderzając tradycyjne wiersze przy stole, a dla drugiej połowy zaznaczone, że faktycznie wychodzi i po prostu chwyta wszystko z wyszukiwania w pamięci, a więc jest inny w sposobie, w jaki SQL Server, na przykład, zaimplementował go z technologią Hekaton, wiesz, i SQL 2014, i został ulepszony w SQL 2016, ale pod pewnymi względami, ich jest bardziej prawdziwą wersją w pamięci, i, ale każda implementacja ma zalety i wady, ale musisz spojrzeć pod przykrywką i zdać sobie sprawę. Ponieważ miałem klienta, który powiedział: „Och, ten stół jest w pamięci - po prostu sporządzę wszystkie indeksy”, a ja mówię: „Tabela jest większa niż pamięć, którą masz na serwerze, więc w pewnym momencie niektóre zapytania musiały trafić na dysk. ”

Eric Kavanagh: To dobry opis; that's good stuff. Well, folks, we're going to have a few more webcasts with these guys over the rest of this year, come back anytime you hear of Bert being on a presentation because we know he knows his stuff. It's always fun to talk to the experts. We do archive all these webcasts for later viewing. Here's Bert's contact information once again, and we'll try to dig up that link for the download and send it out as well by email, but you can always email yours truly:, we've got a bunch more webcasts lined up for this year and we're doing the ed cal right now, so, folks, if there's any topics you really want to hear about next year, don't be shy: Take care, folks, we'll talk to you next time. PA pa.