Index-Wahnsinn: Wie vermeide ich Datenbank-Chaos?

Von Techopedia Staff, 5. Oktober 2016

Imbiss: Gastgeber Eric Kavanagh diskutiert mit Dr. Robin Bloor, Dez Blanchfield und Bert Scalzo von IDERA über die Datenbankindizierung.

Du bist derzeit nicht angemeldet. Bitte melde dich an oder registriere dich, um das Video zu sehen.

Techopedia Content Partner

Techopedia Staff ist mit der Bloor Group verbunden und kann über die Optionen auf der rechten Seite kontaktiert werden. Informationen zur Zusammenarbeit mit Industriepartnern finden Sie hier.

• Profil
• Webseite

Eric Kavanagh: Sehr geehrte Damen und Herren, hallo und herzlich willkommen zurück. Es ist Mittwoch, um vier Uhr Ost, und diejenigen unter Ihnen, die das Programm kennen, wissen, was das bedeutet, es ist Zeit für eine weitere Folge von Hot Technologies. Ja in der Tat. Mein Name ist Eric Kavanagh, ich werde Ihr Moderator für die heutige Sitzung sein: "Index-Wahnsinn: Wie man Datenbank-Chaos vermeidet." Oder, wie ich in der letzten E-Mail erwähnt habe, "Datenbank-Wrangling". Heutzutage heißer Begriff "Wrangling". Jeder tut es. Es gibt eine Folie über deine wirklich. Und genug von mir.

Die Hot Technology-Reihe wurde also wirklich entwickelt, um einen bestimmten Raum zu definieren, im Gegensatz zum Briefing Room, bei dem es sich nur um eine Live-Analystenbesprechung handelt. Für Hot Tech erhalten wir zwei Analysten. Heute werden es unser eigener Doktor Robin Bloor und unser Datenwissenschaftler Dez Blanchfield sein. Und wir sprechen über ein Thema, das meiner Meinung nach wirklich sehr bezeichnend für das ist, was heute auf dem Markt passiert.

Das Fazit ist, dass wir uns heutzutage in einer Welt der Komplexität befinden. Wirklich, wenn man an fünfzehn oder zwanzig Jahre zurückdenkt, war es damals eine völlig andere Welt, insbesondere in Bezug auf die Datenbanktechnologie. Früher waren Datenbanken ziemlich einfach. Es gab nur eine Handvoll von ihnen; Die meisten von ihnen waren relational. Jetzt haben wir diese ganze Palette von Datenbanktechnologien. Buchstäblich unzählige Optionen auf dem Tisch für alle, die eine Anwendung erstellen oder etwas mit Daten tun möchten. Alles ändert sich und das betrifft die Menschen, die versuchen, diese Systeme zu verwalten. Wir werden heute mit Bert Scalzo sprechen, der ein echter Experte auf diesem Gebiet ist. Er ist der leitende Produktmanager von IDERA und erläutert, was Sie tun können, um all diese Daten in den Griff zu bekommen. Damit übergebe ich es Doktor Robin Bloor, um es wegzunehmen. Robin, der Boden gehört dir.

Robin Bloor: Okay, danke für diese Einführung. Ich denke es - weil es eine Zweihandsache ist, denke ich, dass ich als Einführung in diese Hot Tech-Show nur über Datenbankoptimierung im Allgemeinen sprechen würde. Ich habe das Leben angefangen - in Technologie und Analyse - ich habe das Leben angefangen, weil ich Artikel über die Fähigkeiten von Datenbanken auf der DEC VAX-Plattform geschrieben habe. Aus diesem Grund informierten mich die Datenbankausgeber. Und das, was mir so einfällt, ist, warum sollten Sie eine Datenbank haben? Ich meine, in jenen Tagen haben sehr viele Leute Schlüsselwertdateien erstellt und diese verwendet, um eine Art von sequenziellem Indexfehler zu haben, wie wir sie nennen, aber um eine Art Datenbankfähigkeit zu schaffen, und Sie wissen, warum noch etwas?

Und die Antwort darauf, glaube ich, gab Michael Stonebraker die beste Antwort und sagte: "Eine Datenbank kann mehr darüber wissen, wo sich die Daten befinden und wie schnell sie verfügbar sind, als jedes Programm jemals wissen kann." Und ich finde das interessant; Es liegt in der Natur des Spiels. Aber in der Zeit um 1989, als ich mit der Technologieanalyse begann, waren Datenbanken zu diesem Zeitpunkt sehr einfach und relationale Datenbanken sehr einfach. Sie hatten so wenig Kapazität, ich meine, sie konnten offensichtlich Daten speichern, und Sie konnten sichern, und sie hatten, sie waren ACID-konform, aber sie hatten wirklich sehr schwache Optimierer. In der Tat wäre es schwer zu behaupten, dass sie überhaupt die Optimierungsfähigkeit hatten.

Und später wurden sie immer besser, aber wenn eine Datenbank nicht funktioniert - wie diese Kängurus auf die eine oder andere Weise zu sein scheinen -, kann es eine Menge Gründe geben, warum sie langsam ist. Und das bringt mich auf den Punkt: Datenbanken haben viele Funktionen, aber die wichtigste ist die Abfrageoptimierung. Wenn sie das nicht tun würden, würden Sie sie nicht benutzen. Es geht darum, Informationen schnell zu erhalten, es geht darum, in der Lage zu sein, dies zu tun, wenn viele Benutzer gleichzeitig angemeldet sind, und das ist ein schwieriges Problem. Und wenn Sie sich die tatsächlich ansehen, bezeichnen wir sie als ausgereifte Datenbanken, wenn Sie möchten - aber zweifellos Oracle, in etwas geringerem Maße Microsoft SQL Server, zweifellos Teradata und DB2 -, die Optimierer dieser Datenbanken sind seit Jahrzehnten im Einsatz Gebäude. Weißt du, sie haben nicht - jemand hat sich nicht hingesetzt - sechs Jungs in einem Zwei-Mann-Jahr-Projekt und nur einen zusammengeschlagen. So funktioniert das nicht. Die Optimierungsfähigkeit ist allmählich gewachsen, und es ist eine Menge Wachstum erforderlich. Wie auch immer, lassen Sie uns über den Hintergrund der Datenbank sprechen. Nun, es gibt eine Menge über NoSQL-Datenbanken, und es gibt sogar eine Menge Begeisterung für Graphendatenbanken. Und die Verwendung von SQL über Hadoop und ähnliches. In Wahrheit ist es jedoch eine relationale Datenbank oder gar nichts, wenn Sie gerade eine Datenbank benötigen, wenn Sie eine voll funktionsfähige, OLTP-fähige Datenbank mit hohem Abfrageaufkommen benötigen.

Unter den relationalen Datenbanken dominiert Oracle die Popularität. Microsoft SQL Server ist meiner Meinung nach an zweiter Stelle. Sie sind beide in der Lage, für OLTP- und Abfrage-Workloads verwendet zu werden, aber tatsächlich kommt man mit dem Mischen dieser Workloads nicht davon. Sie benötigen unterschiedliche Vorfälle für OLTP-Workloads und Abfrageworkloads. Es gibt Alternativen zu SQL und Graph. Die meisten Unternehmen standardisieren sich auf eine bestimmte Datenbank, weshalb - ich meine, nachdem sie jahrzehntelang mit allen anderen Spielern gekämpft hatten, wurde Oracle die dominanteste. Nur weil sie letztendlich Unternehmenslizenzen verkaufen konnten, verwendeten Unternehmen alternative Produkte nur in außergewöhnlichen Produkten, die Oracle einfach nicht herstellte. Und Datenbanken sind insofern strategisch, als sie sich auch weiterentwickeln. Und du weißt, ich habe ein bisschen nachgeforscht für diese Präsentation, und es ist irgendwie - ich werde gleich darauf zurückkommen, aber es ist irgendwie interessant, wie sie sich entwickeln, wenn man es von der Position eines DBAs aus betrachtet. Das nenne ich den unsichtbaren Trend. Es ist Moores Gesetz. Es ist ungefähr so: Die größte Datenbank ist, und neue Datenbanken, es gibt keine alte Datenbank, die viel mehr Daten zum Aufnehmen hat. Normalerweise handelt es sich um eine Datenbank, die auf ein neues Problem angewendet wird. Und sie wachsen tatsächlich in Bezug auf das Datenvolumen. Ungefähr am Kubus von Moores Gesetz. Das Gesetz von Moore ist also alle sechs Jahre zehnmal so hoch. VLDBs wachsen in der Regel alle sechs Jahre um den Faktor 1000. 1991, 1992, werden die großen Datenbanken in Megabyte gemessen. In '97 und '98, Gigabyte. 2003, 4 Terabyte. 2009, '10, haben Sie angefangen, Petabyte-Datenbanken zu sehen. Ich glaube, es gab momentan möglicherweise eine oder zwei Exabyte-Datenbanken, aber die größte, von der ich gehört habe, ist, dass 200 Petabyte pünktlich sind, und Sie wissen, dass keine Daten in eine Petabyte-Datenbank gelangen. Aber das meiste davon werden natürlich die neuen großen Web 2.0-Unternehmen sein, möglicherweise haben Sie Facebook in diese Richtung.

Aber wenn man sich das tatsächlich ansieht und davon ausgeht, dass eine Datenbank diese Art von Volumensteigerung durchläuft, ist das eine große Herausforderung. Und bemerkenswerterweise, sicherlich bis zum Petabyte-Level, scheinen sie sich einigermaßen gut geschlagen zu haben. Ich meine, ich spreche über die älteren Produkte und nicht über irgendetwas Neues. Sie scheinen sich außerordentlich gut geschlagen zu haben. Wenn wir uns die Datenbankleistung und die Engpässe ansehen, kehre ich zu der Zeit zurück, in der ich mich um sie gekümmert und Sorgen gemacht habe. Sie wissen, dass dies im Grunde der Zusammenbruch der Hardware ist. Es gibt CPU-Engpässe, möglicherweise gibt es Speicherengpässe, möglicherweise gibt es Festplattenengpässe. Es kann das Netzwerk sein, das Sie betrübt, und Sie können auch Probleme mit dem Sperren bekommen, je nachdem, was Sie tun. Normalerweise weiß das Programm jedoch nicht, wen Sie als Sperren angeben sollen. Wenn Sie also eine Datenbank optimieren möchten, versuchen Sie tatsächlich, sie so zu optimieren, dass sie zwischen diesen fünf möglichen Engpässen tanzt, so gut es geht. Und das ist keine leichte Aufgabe, da sich der Speicher, den Sie auf einem bestimmten Server konfigurieren können, dramatisch vergrößert. Dann sind aus CPUs Multicore-Festplatten geworden. Nun, ich glaube, wir können das auch auf Commodity-Servern tun. Ich glaube, Sie können Hunderte und Hunderte von Terabyte, Viertel Petabyte, vielleicht sogar auf einem Commodity-Server tun. Von all diesen Dingen, mit denen Sie spielen können, kann das Netzwerk natürlich mit unterschiedlichen Geschwindigkeiten betrieben werden, aber vor allem, wenn Sie mit Datenbanken zu tun haben, möchten Sie wirklich Glasfaserkabel zwischen den Servern und nichts anderes, das darauf läuft dieser Weg.

Datenbankleistungsfaktoren. Ich meine, ich lasse aus, worum es dabei geht, weil ich weiß, dass Dez darüber sprechen wird, aber schlechtes Datenbankdesign bedeutet, dass die Datenbank eine schlechte Leistung erbringt. Schlechtes Programmierdesign kann möglicherweise bedeuten, sehr dummes SQL auf eine Datenbank zu werfen, was sehr viel länger dauert. Parallelität und Workload-Mixing, zu viel Parallelität führt zu Engpassproblemen. Das Workload-Mischen, wenn Sie große Abfragen mit sehr kleinen, kurzen und scharfen Abfragen haben, verursacht Probleme. Es gibt ein Lastausgleichsproblem. Die meisten Datenbanken kümmern sich darum, aber wenn Sie kein ausgereiftes Produkt haben, ist das Hinzufügen einiger Server nicht alles, was Sie tun müssen, um die Größe eines Clusters zu erhöhen. Sie müssen die Last tatsächlich ausgleichen, bevor Sie die optimale Leistung erzielen. Sie müssen die Kapazitätsplanung durchführen. Absolut. Vor allem in diesen Tagen, als das Datenvolumen dramatischer anstieg als früher für Datenbanken. Und es gibt Probleme mit der gesamten Datenschicht, wie Sie die Daten aufnehmen und wie Sie Daten verschieben. Es kann später zu Leistungseinbußen kommen, wenn die Daten nicht rechtzeitig in eine Datenbank gelangen, da wir von Datenbanken, die unter Windows ausgeführt werden, auf einen Betrieb von 24 x 7 x 375 umgestellt haben und es keine Fenster gibt, in denen Sie die Leistung verlangsamen können Datenbank ausgefallen oder es ist unwahrscheinlich, dass dies heutzutage der Fall sein wird.

Das Oracle DBA-Problem. Daran habe ich gedacht. Ich war in Oracle DBA mit Oracle 7 und erinnere mich, wie ich das optimieren konnte. Und wenn Sie sich Oracle jetzt ansehen, ist es viel, viel - es hat viel, viel mehr Möglichkeiten. Es hat Bitmap-Indizierung und ähnliches, aber ich habe mir tatsächlich die Zeit genommen, um zu sehen, wie viele Optimierungsparameter sich derzeit in einer Oracle-Datenbank befinden. Darüber hinaus gibt es über 350 Optimierungsparameter und weitere hundert verborgene Parameter, über die möglicherweise spezialisierte DBAs Bescheid wissen, normale Oracle-DBAs jedoch nicht. Und das bedeutet, dass das Optimieren dieser Art von Datenbank eine schwierige Sache ist. Es ist überhaupt keine einfache Sache. Man muss ein Gespür dafür haben, man muss es schon lange tun, und man muss genau wissen, welches Problem man zu lösen glaubt, denn die Abstimmung beginnt, wenn die Leistung wird schlecht, aber es ist möglicherweise nicht die Leistung von allem. Dies hängt möglicherweise von der Leistung bestimmter wichtiger Abfragen ab, und Sie können dies möglicherweise beheben, indem Sie bestimmte Daten und Speicher anheften, oder Sie müssen das Problem durch Indizieren beheben, oder Sie müssen die Partitionierung auf eine andere Weise starten. Es gibt eine Menge Dinge, die Sie tun können, ist der Punkt. Folglich werden sie es nicht in ihren Köpfen tun - Datenbankadministratoren benötigen Tools. Ich werde jetzt an Dez weiterleiten, der Ihnen über die Indizierung berichten wird, denke ich.

Eric Kavanagh: Alles klar Dez, nimm es weg.

Dez Blanchfield: Danke, Robin, und ich liebe das Deckblatt. Ich glaube, Sie haben den Handschuh da runtergeworfen, damit ich auch nur annähernd an etwas Aufregendes herankomme. Aber ich habe ein Bild unserer kleinen Galaxie als meine Sicht auf die heutige Herausforderung für Datenbankadministratoren verwendet, da dies das mentale Bild ist, das ich heraufbeschwöre, wenn ich in eine Umgebung komme und nicht mehr bin in der Welt der Verwaltung von Datenbanken oder der Gestaltung von Datenbanken auf dieser Ebene mehr. Aber wie Sie haben Robin und ich viele Jahre in der Welt der Datenbanken gearbeitet, entweder als Administrator, Entwickler oder schließlich als Architekt, und dann begriffen wir, dass ich bessere Dinge tun könnte, um eine Kruste zu verdienen. Aber es scheint eher so, als würden Sie auf diese Galaxie von Daten starren, und heute haben wir, wie Sie dargelegt haben, innerhalb kürzester Zeit von Megabyte zu Petabyte und exoskaliert im großen Schema der Dinge. Aber der Ausdruck, den ich in meinem Kopf habe, ist, dass Datenbankindizes jetzt eine schwarze Kunst sind und nicht wirklich die Art von Dingen, in die sich bloße Sterbliche hineinversetzen sollten, für Unternehmensanwendungen und die Art, Sie zu formulieren redeten nur darüber. Aber ich wollte einen kurzen Überblick über die Art von Geschichte geben, die ich mit Datenbankwelten hatte, und einen Kontext herstellen, zu dem wir eine Schlussfolgerung ziehen werden, und dann heute mit unseren Freunden bei ein paar Materialien durchgehen IDERA, weil ich denke, es gibt viele unterschiedliche Überlegungen, wie die Datenbankleistung optimiert werden kann, und einer von ihnen wirft Zinn auf die Sache. Bei vielen Geschäften, auf die ich stoße, ist die Leistungsoptimierung auf der Datenbankebene und insbesondere auf der Indexebene immer erst dann abgeschlossen, wenn sie sich sicher sind, dass sie einen Tuner darauf werfen können .

Ich denke, viele Leute gehen nur ironisch vor und ich habe hier ein Bild von The Flash, denn wenn Sie jemals einen alten Film oder die neueste Fernsehsendung mit The Flash gesehen haben, wie in Flash Gordon, der alte Charakter, und jetzt, da er "The Flash" genannt wird, geht er in der Regel sehr, sehr schnell und ausnahmslos geht ihm die Energie aus. Und das ist es, was passiert, wenn Sie die Datenbankleistung stark einschränken. Meiner Erfahrung nach können Sie immer hohe Leistung und harte Arbeit in das Spiel stecken, Ihre Betriebssysteme optimieren und auf einen bestimmten Punkt einstellen. Sie können sicherstellen, dass Sie über schnelle Multicore-Multithreading-CPUs verfügen, um die Ausführung der Anwendung zu beschleunigen. Sie können viel RAM auf sie werfen. Sie können Backplanes mit hohem Durchsatz verwenden. Sie können von Festplatten zu Caching-Festplatten zu Solid-State wechseln und Hochleistungsspeicherarray. Und selbst jetzt werfen die Leute Dinge wie Flash und NVMe in ihre Datenbank-Engines und denken, dass sie dieses Login mal zwei Leistungsgewinne bekommen werden. Und ausnahmslos gewinnen sie etwas. Es kommt jedoch alles auf die gleichen grundlegenden Probleme bei der Leistungsoptimierung zurück. Viele Netzwerkverbindungen mit geringer Latenz, sodass die Cluster schnell funktionieren. Wenn Sie die Datenbankinfrastruktur in Clustern zusammenfassen, haben Sie also mehr als nur einen Rechner, der die ganze Arbeit erledigt. Sie kommen jedoch in der Regel auf dasselbe grundlegende Leistungsproblem zurück, und das ist das Lesen von Daten. Das Schreiben von Daten ist größtenteils eine ziemlich lineare Herausforderung und es sei denn, es wird ordnungsgemäß durchgeführt.

Und dann haben wir die Herausforderung in der heutigen Welt: Nicht alle Datenbanken sind gleich aufgebaut. Es gibt Datenbanken und "Datenbank" von Zitat zu Zitat. Und wenn wir an Datenbank-Engines denken, denken die Leute oft an die traditionellen, üblichen Verdächtigen wie in der SQL-Welt. Sie wissen, wir haben Oracle und Microsoft SQL Server, und es gibt ein paar in der Open Source-Welt mit MySQL, das jetzt Oracle gehört, aber immer noch Open Source ist. Und dann haben wir die ungewöhnlichen Verdächtigen, die NoSQL-Engines, die immer noch ein Problem mit der Indizierung und dem Performance-Management haben, und ich werde nicht näher darauf eingehen, aber es gibt immer mehr davon Dinge tauchen jeden Tag auf und sie sehen aus und fühlen sich aus der Sicht der Entwickler und aus der Sicht der Leistung wie Datenbank-Engines an, aber sie sind sehr, sehr verschiedene Biester und sie haben ihre eigene kleine Nische in der Welt, die sie herausarbeiten können In-Memory-Leistung oder lineare Skalierung auf der Festplatte. Aber so sieht die Welt in der Datenbankwelt aus. Dies ist das Jahr 2016, dies ist die dritte Version der Karte von, von einer Reihe von Leuten, die diese fortlaufende Landschaftskarte erstellen, wie Datenbanken aussehen, und hier ist es - nicht einmal ein übermenschlicher Datenbankarchitekt oder Datenbankadministrator könnte einen Sinn ergeben davon. Buchstäblich Hunderte, Hunderte und Hunderte verschiedener Marken, Modelle und Hersteller von Datenbanken, die stets SQL-konform sind. Und das Interessante ist, dass sie alle die gleiche Herausforderung annehmen. Leistung und Leistungsoptimierung rund um das Datenbankmodul und insbesondere durch die Indizierung von Daten.

Lassen Sie uns kurz auf die Datenbankindizierung eingehen, denn es ist ein interessantes Thema, und ich glaube, Sie müssen mit der Demo näher darauf eingehen. Ich bin jedoch der Meinung, dass die Leistungsoptimierung von Datenbankindizes allgemein anerkannt und branchenüblich ist, um sicherzustellen, dass Ihre Daten in einem schnellen und schnellen Format verfügbar sind. Aber was ist die Datenbankindizierung? Wenn wir über eine Indexierung in der Form nachdenken, wie wir es von normalen Menschen gewohnt sind, dann denken Sie an eine Indexseite in einem Buch. Wenn Sie in einem Buch etwas finden möchten - insbesondere in Form einer Enzyklopädie oder eines Referenzmaterials -, wenn Sie nach etwas wie dieser Seite suchen, auf der ich nach Dingen wie dem Thema Dämme suche in einer Enzyklopädie. Ich möchte jeden Hinweis auf Staudämme, das Einzugsgebiet von Wasser und eine große Ansammlungsfläche finden, die allgemein von Menschenhand geschaffen wurde. Ich gehe nach hinten, finde es in einer alphabetisch sortierten Liste von A bis Z von links nach rechts und finde D. Ich finde das Wort „Damm“ und ich sehe es an Auf den Seiten 16, 38, 41 ist ein Verweis darauf, und dann kann ich zu diesen Seiten gehen, meine Augen scannen und den Verweis auf das Wort „dam“ finden. Es ist im Wesentlichen dasselbe Konzept in einer Datenbank. aber es ist jetzt in vielerlei Hinsicht eine Raketenwissenschaft. So sehr, dass jeder Datenbankadministrator, den ich jemals gut kennengelernt habe, Indizes als das wichtigste Tool für die Leistungsoptimierung in jeder Datenbankwelt ansieht, unabhängig von der Erfahrung, die er damit gemacht hat, oder Wie auch immer der Fall sein mag.

Wenn wir über die Datenbankindizierung sprechen, gibt es im Allgemeinen eine Reihe gängiger Ansätze. Und je komplexer Datenbankindizes werden, desto komplexer wird der Ansatz zur Indizierung von Daten. Wenn Sie jedoch über die Indizierung von Daten nachdenken, stellen Sie sich vor, wir haben eine Datei mit einer Liste von Namen. Sie können möglicherweise nicht in alphabetischer Reihenfolge sortiert werden. Stellen wir uns vor, es gibt zwanzig von ihnen. Wenn wir sortieren - wenn wir nach Daten in dieser Liste suchen, von oben nach unten, und sagen wir, es ist eine Liste von Namen. Wenn ich einen zufälligen Namen wähle und damit beginne, in einem linearen Format von oben nach unten durch die Liste zu scrollen, und es ist eine ungeordnete Liste, gibt es zwei Kriterien, die ich als meine durchschnittliche Suchzeit und meine maximale Suchzeit betrachte - und Ich habe einen Tippfehler in der zweiten Zeile, sollte "maximale Suchzeit" sein, sorry - aber meine durchschnittliche Suchzeit ist im Wesentlichen N plus eins, geteilt durch zwei, und das ist im Durchschnitt, es dauert mir fünfzig Prozent der Zeit um vom oberen Rand der Liste bis zum unteren Rand der Liste zu scannen und nach Zufälligkeiten in dieser Liste zu suchen. Und die zweite Zeile dort unter "linear" sollte "maximale Suchzeit" sein. Die maximale Suchzeit ist jedoch im Wesentlichen die Anzahl der Elemente. Wenn ich eine Liste mit zwanzig Dingen habe, kann ich die meiste Zeit in Anspruch nehmen Nach etwas in dieser Datenbank zu suchen bedeutet, von oben nach unten zu gehen, was in diesem vereinfachten Beispiel 20 Elementen entspricht. Und es ist ein sehr langsamer Prozess und es gibt wirklich keine Möglichkeit, dies zu optimieren. Und dann gibt es noch andere Möglichkeiten, diese Daten zu erfassen und einen Index zu erstellen. Dabei handelt es sich praktisch um eine kurze Liste von Zeigern, auf die die tatsächlichen Daten verweisen, z. B. binär, B-Tree, Bitmap, Hashing, Clustered und Non-Clustered. und dann gibt es verschiedene Arten von Daten wie räumliche, gefilterte, XML- und Volltextdaten.

Binär ist eine sehr gebräuchliche Variante für Dinge, für die sich die Daten eignen. B-Tree ist historisch gesehen wahrscheinlich die am weitesten verbreitete Art, einen Index für jede Art von Daten zu strukturieren. Logger, Auswahlen sowie das Einfügen und Löschen von Daten sind relativ einfach, wenn Sie Zeiger in der Liste bewegen Verweis auf die Zeiger, die Punkte. Es gibt andere Typen, wie z. B. Bitmap, bei denen es um Datentypen geht, wenn wir einen zugeordneten Bereich in irgendeiner Form haben. Hashing funktioniert sehr gut für große Objekte, insbesondere für Blogs und Bilder. Und Sie können sehen, dass es bei der Indexierung von Daten verschiedene Arten von wissenschaftlichen und mathematischen Ansätzen gibt. Für die Sterblichen sind sie auf dieser Ebene eine interessante Herausforderung. Wenn Sie als Datenbankadministrator auf Leistungsebene darüber sprechen, werden sie tatsächlich zu Raketenwissenschaftlern, und die Leute machen Abschlüsse, und ich weiß, dass Doktor Robin Bloor das auf jeden Fall getan hat und Bücher darüber für IBM und andere geschrieben hat andere große Marken in den letzten Jahrzehnten. Meiner Ansicht nach haben wir tatsächlich eine Zeit hinter uns, in der ich persönlich einmal vor einem System sitzen und es auseinander ziehen und Ihnen zeigen könnte Genau dort, wo sich die Leistungsprobleme in einer Befehlszeile oder in einem Starttool für eine grafische Benutzeroberfläche befanden, und beginnen Sie, sich mit den Daten zu befassen und Ihnen zu sagen, wo sich die Probleme befanden, und Indizes oder Unterindizes oder primäre und sekundäre Indizes zu erstellen Daten und beginnen, es zu verwenden, um Dinge zu finden. Aber wenn Sie über diese Landschaft nachdenken, habe ich Ihnen gezeigt, wo wir Hunderte und Hunderte von Marken, Marken und Modellen sowie Hersteller und Arten von Datenbanken haben. Wir sind längst über die Zeit hinausgegangen, in der ein Mensch produzieren kann Sinn für die Arten von Datenbank-Engines, die wir haben. Insbesondere, auch wenn wir nur auf Oracle zurückkommen, das heutzutage in relationalen Datenbankplattformen die vorherrschenden Marken ist.

Die Anzahl der Datenbanken, mit denen sie zu tun haben, entweder von einer proprietären Plattform wie einem ERP- oder HR- oder Finanzsystem, oder ob sie aus verschiedenen Gründen eine selbst gebackene Plattform sind, die Anzahl der Datenbanken und Datenbanktabellen und -aufzeichnungen, die wir erhalten Umgang mit sind nur astronomisch und Sie können es physisch nicht von Hand tun. Und wir hatten jetzt eine zusätzliche Komplikation: Es war einmal ein Datenbankserver, der einfach unter Ihrem Schreibtisch saß. Sie wissen, dass ich als kleines Kind nach der Schule an Datenbanksoftware für Apple IIes und DOS PC-basierte Systeme wie dBase II und dBase III gearbeitet habe, die eine Ära mit Mainframes und Mid-Frames durchliefen. Bereich und sogar VAXs und PDPs und Protokolldatei darauf. Und so ähnlich wie bei Sabre, und schließlich, als einige der SQL-Datenbanken hinzukamen. Wenn wir heutzutage über Datenbank-Engines nachdenken, sehen sie wie in der linken unteren Ecke aus. Ein Datenbankserver ist nicht mehr nur eine Maschine, die unter einem Schreibtisch auf dem Boden steht. Es sind Hunderte von Computern, auf denen Kopien von Datenbank-Engines und Clustern ausgeführt werden, und diese skalieren auf Hunderte und Hunderte von Terabytes an Daten, wenn nicht Petabytes an Daten, das sind Tausende von Terabytes. Und bis zum Äußersten, wie Doktor Robin Bloor erwähnte, dass einige spezifische Anwendungsfälle - Fluggesellschaften, insbesondere Regierungsbehörden - Exabytes erreichen können. Sie sind immer noch eine Nische, aber Hunderte von Terabyte und sogar Dutzende von Petabyte sind keine Seltenheit mehr, besonders vom Dotcom-Boom bis heute. Das ist so etwas wie das, was wir Web 2.0-Unternehmen nennen, wie Facebook, Google, Yahoo und so weiter.

Wir haben jetzt auch die Komplikation, dass die Dinge auf externen Service verlagert werden. Wir haben Infrastrukturplattform und Software als Service-Ansatz, der Infrastruktur bereitstellt. Und insbesondere Plattformdienste, bei denen wir nicht nur für Oracle und seine Cloud-Plattform, Datenbanken und Server einkaufen können. Auf diese Weise können wir sehr schnell Anwendungen entwickeln und einfach eine Datenbank wieder in die Server einbinden. Wir müssen nicht darüber nachdenken, was unter der Haube ist. Der Nachteil ist, dass wir oft nicht darüber nachdenken, wie wir die Datenbank neu entwerfen und implementieren, bis sie Schaden nimmt und die Leistung ein Problem darstellt. Dann müssen wir nach dem richtigen Tool suchen, um zu diagnostizieren, warum unsere Datenbank Schaden nimmt und wo die Leistungsprobleme sind. Und dies führt uns ausnahmslos zu dem allgemeinen Problem zurück, wie wir diese Daten und die für diese Daten verwendeten Indextypen indiziert haben, und führt uns dann zu den übermenschlichen Leistungsanforderungen zurück. Und jemand, der Zugriff auf die richtigen Systeme und die richtigen Tools hat, um diese Engines zu optimieren, einen Hotspot zu finden und sich anzusehen, wo sich die Abfragen befinden, wo sich die Daten bewegen, welche Abfragetypen und wie die Abfragen strukturiert sind. Wer führt die Abfragen durch und ob die Abfragen in die Warteschlange gestellt werden und zwischengespeichert werden müssen? Nach welcher Replikation suchen Sie?

Meiner Ansicht nach sind wir an einem Punkt angelangt, an dem selbst die weltbesten Datenbank-Gurus, im Wesentlichen unsere Datenbankarchitekten und unsere Datenbankadministratoren und Leistungsdatenbanken, nach meiner Ansicht dringend die richtigen Tools einsetzen müssen Optimale Leistungsindexoptimierung für jedes Datenbankmodul. Aufgrund der Größe, mit der wir es zu tun haben, und der Geschwindigkeit, mit der sich die Dinge bewegen, können wir dies einfach nicht von Hand tun, und der Versuch, dies zu tun, kann ausnahmslos andere Leistungsprobleme mit sich bringen, da wir in diesem Bereich möglicherweise keine Erfahrung haben Wir versuchen, ein Problem zu lösen. Und ich glaube, hier werden wir Bert übergeben, und wir werden darüber sprechen, wie sie dieses abwechslungsreiche Problem gelöst haben und welche Art von Dingen ihr Werkzeug kann tun, insbesondere für die Oracle-Welt. Und damit, Bert, werde ich zu dir übergehen.

Bert Scalzo: Danke. Herzlich willkommen, mein Name ist Bert Scalzo, ich arbeite für IDERA. Ich bin der leitende Produktmanager für einige unserer Datenbankprodukte. Ich werde heute einige davon demonstrieren. Aber ich möchte über Indizes sprechen, da ich mit allem einverstanden bin, was alle hier gesagt haben, insbesondere mit der letzten Folie, dass Indizes jetzt so komplex sind, dass Sie ein Tool benötigen, und ich hoffe, Sie davon zu überzeugen. Oracle Index Design ist also nicht mehr so ​​einfach wie früher. Viele Leute werden sich unsicher sein, wenn sie sich die Optionen ansehen, und ich mag dieses Sprichwort, das ich aus der Geschichte gezogen habe: "In diesen Angelegenheiten ist die einzige Gewissheit, dass nichts sicher ist." Und so bin ich auch Heutzutage beschäftigen Sie sich mit Indizes, denn selbst wenn Sie der Meinung sind, dass Sie wissen, welche Antwort Sie mit X, Y oder Z indizieren sollten, können Sie erst dann sicher sein, wenn Sie es versuchen, da sich diese Optimierer manchmal anders verhalten, als Sie es erwarten. Und so gibt es eine Menge Versuch und Irrtum beim Indexdesign. Wenn Sie in guten alten Zeiten einen Index brauchten, gab es im Allgemeinen nur zwei Fragen oder eine Frage. War es einzigartig oder war es nicht einzigartig? Vielleicht haben Sie auch an andere Dinge gedacht: „Wie viele Indizes kann ich maximal für eine einzelne Tabelle verwenden?“, Da zu viele Indizes Ihre Einfügungen, Aktualisierungen und Löschvorgänge verlangsamen. Möglicherweise befanden Sie sich auch in Ihrem Datenbanksystem und hatten Einschränkungen hinsichtlich der Anzahl der Spalten in einem mehrspaltigen Index, da es manchmal Beschränkungen gab, die auf der Seiten- oder Blockgröße Ihres Datenbankmoduls basierten. In Wirklichkeit war dies jedoch recht einfach in den guten alten Zeiten. Sie haben es entweder indiziert oder nicht. Und wirklich, alles war in einem B-Baum. Wir konnten die Duplikate zulassen oder nicht, und das war es auch schon. Das Leben war gut, das Leben war einfach.

Nun, heute ist das Leben nicht so gut oder so einfach. Ich habe das rote Ghostbuster-Zeichen so gesetzt, wie wir es früher gemacht haben, weil wir jetzt B-Tree versus Bitmap versus Bitmap-Join haben. Und ich werde gleich erklären, was einige davon sind. Clustered und Non-Clustered, Unique oder Duplicates, Forward- oder Reverse-Order, funktionsbasiert, partitioniert oder nicht partitioniert. Handelt es sich bei der Partitionierung um eine globale oder lokale Partitionierung? Ich werde das auch erklären. Und dann gibt es noch so etwas wie eine indizierte organisierte Tabelle. Und es gibt tatsächlich ein halbes Dutzend anderer, die ich hier aufgehört habe, weil ich denke, ich habe jetzt genug, um Sie davon zu überzeugen, dass die Indizes viel härter sind, als Sie vielleicht gedacht haben. In dieser speziellen Folie beginne ich oben links im Diagramm und habe eine Tabelle. Und das Erste, worüber ich mich entscheiden muss, ist, dass sie abhängig von Ihrer Datenbankversion und Ihrem Datenbankanbieter Objekttabellen zulassen oder nur relational sind. Ich gehe die rechte Seite runter und sage, dass wir einen relationalen Tisch bauen. Die nächste Frage, die ich mir stellen muss, ist, ob es sich um einen Cluster handelt. Und viele von Ihnen, die sich schon länger mit Oracle befasst haben, werden sich daran erinnern, dass die Cluster seit 6 Tagen wieder in Oracle sind. Sie werden heute wahrscheinlich nicht mehr sehr häufig verwendet, aber lassen Sie mich zuerst diesen Zweig hinuntergehen.

Wenn ich meine Tabelle in einen Cluster einfügen würde, müsste ich einen Clustered-Index für diese Tabelle haben. In Oracle haben Sie beim Clustering einer Tabelle im Grunde genommen die Zeilen gespeichert, oder die Zeilen befanden sich nahe beieinander, wo die Werte ähnlich waren. Sie müssen also einen Clustered-Index haben, und dieser Clustered-Index kann nicht partitioniert sein. Mit anderen Worten, es gab eigentlich keine Partitionierungsmethoden für die Erstellung einer gruppierten Tabelle. Es war streng nicht unterteilt. Und weil es nicht partitioniert war, war es global. Ich werde in einer Minute erklären, was global ist. Und es war immer B-Tree. Mit anderen Worten, als ich diesen Zweig runterging, war es ziemlich einfach, ich hatte nicht viele Möglichkeiten. Wenn ich nun einen nicht gruppierten Index für eine gruppierte Tabelle erstellt habe, der in einigen Versionen zulässig war, wurde er erneut nicht partitioniert. Wenn es nicht partitioniert ist, ist Ihre einzige Wahl global. Und so haben Sie die Wahl zwischen B-Baum oder Bitmap. Auch dies hing von Ihrer Version der Datenbank ab. Aber jetzt gehen wir zurück zum relationalen Tisch und gehen wieder die rechte Seite hinunter, und jetzt haben wir nur einen einfachen, alten, regulären, gehäuften Tisch: relational. Es wird in einem Tabellenbereich sein. Ich gehe hier zuerst die rechte Seite runter. Also ist es Organisation, Haufen. Die nächste Frage, die ich mir stellen muss, lautet: "Möchte ich diese Tabelle partitionieren oder nicht?" Manchmal würden Sie partitionieren, weil Sie dachten: "Hey, das Optimierungsprogramm wird intelligenter darüber sein, wie es Abfragen optimieren kann. „Aber viele Datenbankadministratoren werden Ihnen sagen, dass der Grund, warum Sie dies tun, Verwaltungszwecken dient. Wenn Sie eine 100-Milliarden-Zeilen-Tabelle haben, diese in Partitionen oder Buckets aufteilen und dem letzten Bucket Daten hinzufügen möchten, können Sie nur wenige Millionen Zeilen löschen und indizieren. Sie können diese Daten einfügen und dann diesen Index nur für diesen Bucket neu erstellen.

Während es für einige eine gute Technik war, Optimierungstechniken wie die Eliminierung von Partitionen, bestand der wahre Wert darin, administrative Aufgaben an kleineren Teilen verwalten oder ausführen zu können. Wenn ich zum Organisationshaufen gehe, war die erste Frage: "Habe ich es partitioniert oder nicht?" Gehen wir nach links, ich werde die Tabelle nicht partitionieren. Nun, es mag seltsam erscheinen, wenn ich Ihnen das sage, aber Sie könnten eine nicht partitionierte Tabelle haben und dann können Sie den Index nicht so partitionieren, wie Sie es gewohnt sind, oder Sie können den Index partitionieren. Halte inne und denke nach. Ihr Tisch hat im Grunde einen Bucket, wie Sie immer dachten, und dennoch wird Ihr Index mehrere Buckets haben. Wenn das passiert, wenn zwischen der Anzahl der Buckets und der Tabelle und der Anzahl der Buckets im Index ein Missverhältnis besteht, ist das mit global gemeint. Wenn die Tabelle also nicht partitioniert ist und der Index partitioniert ist, wird er als global betrachtet, da eine Nichtübereinstimmung vorliegt. Lassen Sie mich jetzt wieder auf meinen Organisationshaufen zurückgreifen und stattdessen auf die Partitionsseite zurückgreifen. Wenn ich nun eine Partitionstabelle habe und die Tabelle vier Buckets und vier Partitionen hat, könnte mein Index vier Buckets haben, sodass mein Index mit meinem Tabellenentwurf übereinstimmt. Und so ist es vorbei, weit vorbei, auf der rechten Seite. Das wäre als lokal zu bezeichnen. Ein lokaler Index bedeutet im Grunde, dass die Partitionierung der Tabelle und des Index auf die gleiche Weise erfolgt und die gleiche Anzahl von Buckets aufweist. Wenn ich dann den lokalen Index habe, kann es sich um einen B-Baum oder eine Bitmap handeln, und der grüne Pfeil, der nach oben zeigt, dass auch bei einem B-Baum noch Entscheidungen getroffen werden können. Es könnte funktionsbasiert sein. Wenn es sich um eine Bitmap handelt, gibt es auch verschiedene Arten von Bitmaps. Es gibt so etwas wie einen Bitmap-Join-Index. Wenn Sie Data Warehousing betreiben, ist dies eine sehr beliebte Art von Index für Sternschema oder -design. Was passiert, ist, dass der Index die Zeilen-IDs für das enthält, auf das er in der Tabelle verweist, aber auch Zeilen-IDs für die übergeordneten Tabellen, damit Sie, wenn Sie möchten, das Schema entwerfen und suchen müssen In einer Faktentabelle verweist dieser Index in der Faktentabelle auf die Daten, an denen Sie interessiert sind, und verweist auf jede Zeile in Ihren Dimensionen, sodass Sie nur einen Index benötigen.

Und tatsächlich entstand dies aufgrund des Roten Backsteins, der vor vielen Jahren eine Datenbank war - viele Leute mögen sich daran erinnern. Wenn Sie sich also dieses Bild ansehen - und bedenken Sie, dass ich nicht alles in dieses Bild eingefügt habe, weil das Bild viel größer wäre -, gibt es noch weitere Probleme, die ich hier oben rechts im Text habe . Ist es ein Index in umgekehrter Reihenfolge? Und Sie könnten sagen: „Warum sollte ich einen Index in umgekehrter Reihenfolge wollen? Das macht überhaupt keinen Sinn. “Nun, wenn Sie sich in einer Cluster-Umgebung in Oracle befinden, wenn Sie echte Anwendungs-Cluster ausführen, wenn Sie Ihre Indizes in Ordnung halten, also nicht umgekehrt, wenn Sie eine Menge Verarbeitung haben, die auf Sie zutrifft Gleiche Werte oder gleiche Indexwerte, was passieren würde, wären heiße Bereiche Ihres B-Baums. Dies bedeutet, dass Sie Konflikte und möglicherweise Sperren haben würden, um zu versuchen, auf das Zeug zuzugreifen, und Sie würden dies über Knoten in einem Netzwerk hinweg tun. Wenn Sie einen Index in umgekehrter Reihenfolge eingeben, können Sie dies jetzt rückgängig machen. Sie können sagen: „Nun, die ähnlichen Werte befinden sich in verschiedenen Teilen der Bäume, sodass meine separaten Knoten nicht um heiße Bereiche im Baum konkurrieren.“ Und beachten Sie auch, dass unique bei einigen Optionen nicht funktioniert . Wenn Sie schauen, ich habe drei, fünf, acht und elf nummeriert, so gibt es einige Fälle, in denen ich keinen eindeutigen Index haben kann. Ebenso gibt es einige Fälle, in denen ich keinen Reverse-Index haben kann, und dann gibt es zusätzliche Probleme wie Protokollierung oder keine Protokollierung sowie parallele und nicht parallele. Ich kann Dinge einem bestimmten Bereich im Gedächtnis zuordnen.

Und dies lässt noch einige Features in Oracle aus. Ich würde sagen, wenn Sie sich Oracle 12 ansehen, gibt es wahrscheinlich wieder ein halbes Dutzend Dinge, die ich zu diesem Bild hinzufügen könnte. Die Indizierung ist sehr komplex und ich stimme dem Vorredner wirklich zu. Um darin zu navigieren und eine gute Wahl zu treffen, benötigen Sie ein Tool. Vielleicht brauchen Sie ein Bild wie dieses und eine Methode, wie Sie Dinge auswählen und hoffentlich hilft Ihnen das Tool dabei, dorthin zu gelangen. Und dann wird es Versuch und Irrtum sein. Ich sage den Leuten beim Indexieren immer: „Schau, bevor du springst.“ Und dann siehst du den kleinen Hund hier, der springt, ohne hinzusehen, er wird mit dem Hai im Wasser landen oder der Typ macht sich bereit, ins Wasser zu springen und er wird sich aufspießen. Sie müssen über Ihre Indizierung nachdenken, denn das Erstellen eines Index bedeutet nicht immer, dass die Dinge besser werden. Tatsächlich kann das Erstellen eines Index die Arbeit verlangsamen. Und die Abfrageleistung kann bei einer Auswahl eine Größenordnung besser sein als bei einer anderen. Und ich gebe Ihnen ein gutes Beispiel. Wenn Sie ein Stern-Entwurfsschema erstellen und in Ihren Dimensionstabellen Bitmap-Indizes in einem Fall verwenden und in einem anderen Fall sagen Sie: "Ich verwende B-Tree-Indizes", dann erhalten Sie Bitmap versus B- Baum. Ich kann Ihnen sagen, dass eine Lösung eine Größenordnung oder möglicherweise mehrere Größenordnungen schneller sein wird als die andere. Beachten Sie jedoch, dass das, was in einer Umgebung wie in einer Data Warehousing-Umgebung funktioniert, in einer OLTP-Umgebung wahrscheinlich keine gute Wahl ist.

Wenn Sie beispielsweise eine Transaktionstabelle nehmen und Bitmap-Indizes in eine Transaktionstabelle einfügen, ist das Berechnen und Zurücksetzen von Bitmaps, diesen langen Zeichenfolgen, teuer. In einer OLTP-Tabelle können Sie die Tabelle möglicherweise so stark treffen, dass die Bitmap beschädigt wird index kann beschädigt werden und Ihr System verlangsamen, da sie nur nicht für Aktualisierungen gedacht sind. Sie eignen sich hervorragend für den schnellen Zugriff, sind jedoch nicht für Updates geeignet. Ich denke, Index braucht Versuch und Irrtum. Es gibt wirklich keine goldene Regel mehr - es gibt zu viele verschiedene Variablen in dieser Gleichung, um sie zu kennen - und letztendlich müssen Sie sich die Ausführung ansehen oder Pläne in Ihrer Datenbank erklären, um zu sehen, ob Sie eine gute Auswahl treffen oder nicht. Und manchmal kann die Plananalyse fast eine Wissenschaft für sich sein. Ich werde das heute nicht behandeln - das ist ein anderes Thema -, aber das Indexdesign ist nicht selbstverständlich. Es gibt berechtigte Gründe, warum es all diese verrückten Indextypen gibt, die ich Ihnen im vorherigen Bild gezeigt habe und von denen der vorherige Redner gesprochen hat. Diese wurden nicht nur erstellt, weil es eine nette Funktion war, irgendwo eine Checkliste für einen Datenbankanbieter zu erstellen. Es gibt Anwendungsfälle oder Szenarien, in denen diese Indizes wichtig sind und einen signifikanten Unterschied machen. Damit zeige ich Ihnen einige Beispiele für verschiedene Indextypen in einem unserer Tools. Lassen Sie mich einfach meinen Bildschirm hochklappen, damit Sie ihn sehen können. Okay, also sitze ich hier drinnen - lass mich diese Anwendung minimieren. Ich sitze in der VMware und verwende eine Windows Server 2012-VM.

Und Sie sehen, ich habe so ziemlich jedes Werkzeug, das dem Menschen bekannt ist. Als Produktmanager muss ich mich der Konkurrenz bewusst sein. Es geht also nicht nur darum, welche Tools ich habe, sondern auch darum, was meine Konkurrenten tun. Und wir haben hier ein Tool namens DBArtisan, das ich bereits ausgeführt habe, aber ich gehe - also werde ich es einfach ansprechen. Und was Sie sehen, ist, dass dies ein wirklich nettes Tool ist, denn anstatt eines Unternehmensmanagers für Oracle und eines SQL Management Studios für SQL Server, der MySQL Workbench für MySQL und zwölf weiterer von uns unterstützter Datenbanken, Nun, ich habe alle meine Datenbanken in dieses eine Tool eingebaut. Es gibt DB2, MySQL, Oracle, Postgres, SQL Server und Sybase, und das ist - ich habe nur sechs Datenbanken in dieser speziellen Sache, weil ich nicht kann - das Tool unterstützt zwölf Datenbanken, aber meine schlechte VM, führt sechs Datenbanken gleichzeitig aus und versucht es Eine Demo zu machen, ist ungefähr so ​​viel, wie meine Hardware erleichtern wird. Lassen Sie mich jetzt zurück zu Oracle gehen, und wenn Sie bemerken, sind all diese Dinge gleich. Wenn ich meine Leistung in DB2 messen möchte, stehen mir dieselben Optionen wie in Oracle zur Verfügung. Jetzt machen wir viele verschiedene Dinge, damit Sie nicht wissen müssen, was los ist, aber wir bieten Ihnen eine konsistente Oberfläche, damit Sie ein Experte mit mehreren Datenbankplattformen sein können. Dazu gehört auch das Arbeiten mit Indizes, das Thema dieser Diskussion.

Lass mich hier rein kommen und mich zuerst einige Tabellen ansehen, und ich habe eine Filmdatenbank, die nur ein paar Tabellen enthält. Und wenn ich eine bestimmte Tabelle wie die Kundentabelle betrachte, wenn ich sie hier aufrufe, kann ich mein Tabellendesign sehen, hier sind meine Spalten in meiner Tabelle und hier sind Informationen zu jeder Spalte. Ich habe Eigenschaften für die Tabelle, aber beachte, dass ich hier eine Registerkarte für Indizes habe und hier die Indizes für die Tabelle sehen kann. Beachten Sie, dass einer dieser Indizes mein PK-Index ist, mein Primärschlüssel. Diese anderen scheinen nur Indizes zu sein, um den Zugriff auf Abfragen zu verbessern. Vielleicht fragen wir nach Vor- oder Nachnamen ab, oder wir untersuchen Telefone und Postleitzahlen. Und wenn ich einen bestimmten Index wie diese Postleitzahl hier auswähle und darauf doppelklicke, kann ich jetzt sehen, dass es sich um einen nicht eindeutigen Index handelt, und hier sind einige der anderen Typen: Bitmap, nicht eindeutig, einzigartig, ob es sortiert ist oder nicht, ob es sich um eine Protokollierung handelt, ob es sich um eine umgekehrte Reihenfolge handelt oder nicht, ob es sich um eine Funktionsbasis handelt. Oh, hier ist ein Spaß, den ich nicht behandelt habe. Sie können tatsächlich unsichtbare Indizes haben. Und Sie würden sagen: „Warum zum Teufel sollte ich einen unsichtbaren Index erstellen?“ Nun, ich gebe Ihnen ein gutes Beispiel. Sie befinden sich in Ihrem Produktionssystem und haben ein Leistungsproblem. Sie sind sich nicht sicher, ob das Problem durch das Erstellen des Index behoben werden kann. Sie möchten also nicht den Index erstellen und die Produktion verlangsamen, sondern auf die eine oder andere Weise in der Lage sein, es zu testen. Sie können den Index in der Produktion als unsichtbar erstellen. Das bedeutet, dass nicht viele Anwendungscodes, die das Optimierungsprogramm aufrufen, diesen Index verwenden. Es wurde erstellt, ist gültig, wird aber nicht verwendet. Dann können Sie eine Abfrage durchführen, bei der dieser Index Ihrer Meinung nach hilfreich ist, oder eine Reihe von Abfragen, und Sie können einen Hinweis einfügen und sagen: „Hey, Optimierer, da draußen gibt es einen unsichtbaren Index, den Sie verwenden und zulassen sollen Ich weiß, ob ich es besser gemacht habe. “Und jetzt habe ich etwas in der Produktion getestet, aber ich habe die laufenden Anwendungen in der Produktion nicht beschädigt. Das ist die Verwendung für einen unsichtbaren Index. Es klingt dumm, wenn Sie zum ersten Mal davon hören, aber es hat eine Verwendung.

Wir können auch auf Indizes definieren, ob sie parallel sind und wie viele Instanzen sie parallel sind. In einer nicht geclusterten oder einer nicht realen Anwendungscluster-Umgebung, also nicht im Rack, würde Parallel bedeuten, wie viele Unterprozesse meine Abfrage ausführen kann, um zu versuchen, und Arbeitsprozesse, um zu versuchen, Dinge schneller oder schneller durchzubringen . Parallele Instanzen wären: Wenn ich in einem realen Anwendungscluster bin, würde ich sagen, ich habe zehn Knoten, auf wie viele Knoten darf ich die Arbeit aufteilen? Vielleicht sind es vier von zehn und bei jedem von ihnen vier Unterprozesse. Das ist ein Beispiel. Und dann haben wir Schlüsselkomprimierung. Kann man eigentlich Indizes komprimieren? Ja oder Nein. Und dann haben Sie natürlich Ihre Speicherparameter, die Sie für Indizes angeben können. Nun, ich habe dies nicht behandelt, da es sich eher um einen Speicherparameter als um ein Indexproblem handelt. Und schließlich müssen wir entscheiden, ob diese partitioniert oder nicht partitioniert werden sollen. Lassen Sie mich das hier für eine Sekunde fallen lassen. Ich gehe zu einem anderen Schema. Dies ist ein Sternschema, und diese Periodentabelle ist beispielsweise eine Dimensionstabelle. Wenn Sie jemals ein Sternschema entworfen haben, haben Sie normalerweise eine Zeitdimension. In dieser Datenbank und diesem Sternschema ist Punkt eine Zeitdimension. Jetzt, da ich weiß, dass es lustig aussehen wird, werden Sie sagen: "Gee, sehen Sie sich all diese Spalten an - hat der Typ jemals von Normalisierung gehört?" Normalerweise haben Sie keine - Sie haben Tabellen, die eine typische Person sich ansieht und sagt: „Gee, diese sind nicht sehr gut gestaltet.“ Aber so machen Sie das in einer Data Warehousing-Umgebung.

Beobachten Sie, was passieren wird, denn es gibt all diese Spalten. Sehen Sie sich das an. Ich habe einen Index für jede einzelne Spalte. In einer OLTP-Umgebung wäre das ein Nein-Nein. Es würde alle meine Operationen verlangsamen. In einer Data Warehousing-Umgebung würde ich sie während meiner Batch-Ladezyklen löschen. Laden Sie ohne den Overhead oder die Indizes, und ich würde die Indizes neu erstellen. Und wenn ich meine Tabelle partitioniert hätte, könnte ich, anstatt den Index für jeden Bucket in der Tabelle löschen zu müssen, einfach den Index für den Bucket oder die Buckets löschen, in die die Daten während dieses Batch-Ladezyklus verschoben werden sollten. Erstellen Sie dann nur den Indexabschnitt für diese Buckets neu. Und das macht es sehr überschaubar. Und wenn ich mir das ansehe - hier ist eine Spalte mit dem Namen "Holiday Flag" und im Grunde ist das ein Ja oder Nein. Beachten Sie, dass dies ein Bitmap-Index ist und Sie für die meisten von Ihnen sagen werden: „Nun, das macht Sinn.“ Ja oder Nein, J oder N, es gibt nur zwei sinnvolle Werte. Und wenn Sie die Dokumentation für Bitmap-Indizes lesen, erfahren Sie immer, dass Sie etwas mit geringer Kardinalität auswählen.

Lassen Sie mich jetzt in eine meiner Faktentabellen gehen, also haben wir hier meine Bestellungen. Und das sind meine Aufträge pro Tag. Und Sie werden jetzt sehen, dass ich wieder einige Spalten und wieder mehr als ein paar Indizes haben werde. Und genau hier haben wir den sogenannten universellen Preiscode. Dies war für ein Einzelhandelsgeschäft, so dass Sie diese kleinen Strichcodes kennen, wenn Sie etwas im Geschäft kaufen. Dies ist der universelle Preiscode. Jetzt gibt es Millionen von universellen Preiscodes. Nun, für dieses spezielle Unternehmen, das Sachen verkaufte, hatten sie wahrscheinlich 1, 7 bis 2 Millionen universelle Preiscodes. Sie werden also erwarten, dass dies kein Bitmap-Index sein wird, da 1, 7 Millionen unterschiedliche Werte nach hoher Kardinalität klingen. In einer Data Warehousing-Umgebung möchten Sie jedoch in Wirklichkeit, dass dies eine Bitmap ist. Lassen Sie mich nun erklären, warum. Nun, es kann 1, 7 Millionen verschiedene Werte für diesen universellen Preiscode geben. Die Anzahl der Zeilen in dieser Auftragstabelle beträgt Hunderte von Millionen bis Milliarden von Zeilen. Mein Index ist eine niedrige Kardinalität im Vergleich zur Größe oder Kardinalität der Tabelle. Das macht es zu einer geringen Kardinalität. Das macht den Bitmap-Index nützlich, auch wenn es mit 1, 7 Millionen unterschiedlichen Werten nicht intuitiv ist, dass Sie hier Bitmap wählen würden. Wenn ich wüsste, dass ich einen Bitmap-Join-Index verwenden möchte, wird dies vom Produkt derzeit nicht unterstützt. Ich werde dies für die nächste Version hinzufügen, aber das wäre hier eine andere Alternative. Denken Sie in einem Sternschema daran, dass sich der Bitmap-Index in der Faktentabelle befindet und dass ein Index in der B-Struktur auf die Zeile in der Faktentabelle und dann auf jede Zeile verweist, die in der Dimensionstabelle für diese Tatsache ersichtlich ist . Und so haben Sie dort eine andere Option. Mal sehen, ich möchte jetzt von den Tabellen verschwinden und Ihnen nur schnell zeigen, dass ich unter den Indizes die gleichen Informationen habe und dass ich das Gleiche tun werde.

Der Grund, warum ich das angesprochen habe, ist, dass Sie vielleicht bemerken, dass es hier keine Primärschlüssel gibt. Primärschlüssel werden mit einer Schlüsseleinschränkung erstellt, sodass sie tatsächlich von den Einschränkungsdefinitionen abgedeckt werden. Dies wären Indizes, die nicht Teil der Einschränkung sind. Nun könnten Sie sagen: "Warten Sie eine Minute, das könnte wie ein Fremdschlüssel aussehen, und ein Fremdschlüssel ist eine Einschränkung." Fremdschlüssel und die meisten Datenbanken erstellen jedoch nicht automatisch einen Index für die Fremdschlüsselspalte, obwohl dies der Fall ist ratsam, und los geht's - ich habe wieder die gleichen Möglichkeiten. Und wenn ich mich ändern will, nur um komprimiert zu werden, kann ich das tun.

Jetzt funktioniert die Komprimierung nur für einen B-Tree-Index. Wenn Sie sich die verschiedenen Knoten in der B-Struktur ansehen, können Sie einige der Werte komprimieren. Es ist wirklich keine Komprimierung wie eine Tabellenkomprimierung, sondern eine Komprimierung dessen, was in der B-Struktur in den Nicht-Blatt-Knoten gespeichert ist. Es spart nicht viel Platz, kann aber einen Unterschied machen. Und damit ist mir aufgefallen, dass ich der Zeit ziemlich nahe komme. Ich möchte also zurückgehen und mein Teilen beenden. Wir haben unser Produkt für eine vierzehntägige Testversion auf idera.com verfügbar. Es ist ein ziemlich gutes Produkt, besonders wenn Sie mit mehreren Datenbankplattformen arbeiten. Wenn Sie mit zwei oder drei verschiedenen Datenbanken arbeiten, erleichtert Ihnen dieses Tool das Leben erheblich. Wir haben Tools, die Ihnen bei der Indexerstellung und -auswahl helfen. Wir haben ein Tool namens DB Optimizer. Ich konnte das heute einfach nicht behandeln, das wäre zu viel. Und wenn Sie mich kontaktieren möchten, gibt es meine E-Mail-Adresse, oder Sie können mich unter meiner privaten E-Mail-Adresse abrufen, und ich habe Blogs, eine Website und Blogs sowie ein LinkedIn-Profil. Wenden Sie sich an mich, auch wenn es sich nicht um ein produktbezogenes Thema handelt. Wenn Sie nur über Datenbanken sprechen möchten, bin ich ein absoluter Hingucker und liebe es, über Technobabble zu sprechen.

Eric Kavanagh: Okay, Dez, Robin, ich bin mir sicher, dass jeder ein paar Fragen hat, wir haben noch ein paar Minuten hier. Dez, was denkst du?

Dez Blanchfield: Ich habe eine großartige Frage, die ich dir stellen muss. Sie sitzt im Hinterkopf. Was ist das verrückteste Szenario, das Sie gesehen haben? Ich habe Ihren Blog gelesen, ich verfolge Sie genau. Sie sind wahrscheinlich einer der wenigen Menschen, die in fast jedem Unwahrscheinlichen gelebt haben, und ich denke, Dr. Robin Bloor ist der zweite, in dem ich mich getroffen habe mein ganzes Leben. Aber Sie wissen, Sie haben wahrscheinlich jedes verrückte Szenario gesehen, was sind einige der verrücktesten Szenarien, die Sie gesehen haben, denen Sie begegnet sind, und wie Menschen, die es einfach nicht bewältigen konnten, haben Sie es geschafft, zu gehen und Jedi-Mind-Tricks mit diesem ganzen DBArtisan ausführen?

Bert Scalzo: Wir hatten einmal einen Kunden, der in seinem Datenbankdesign genau das dachte, was er in einem Datei-Layout-Design denken würde. Wenn Sie also eine Datenbank normalisieren, ist das erste, was Sie versuchen, loszuwerden von sich wiederholenden Gruppen. Nun, sie hatten eine Spalte und sie machten eine lange, oder ein BLOB oder CLOB, und darin setzten sie Wert, Nummer eins, Semikolon, Wert Nummer zwei, Semikolon, Wertnummer, Semikolon, und sie hatten Tausende von Werten Dort drinnen mussten sie aber nach dieser Spalte suchen und fragten: „Warum läuft das Ding so langsam?“ Und ich frage: „Nun, Sie können keinen Index für das erstellen, was Sie getan haben, es ist nur so nicht erlaubt. “Wir haben ihnen also anhand der Pläne gezeigt, dass sie diese Tabelle normalisieren mussten. Nicht weil Normalisierung eine akademische Übung ist, die die Dinge verbessert, sondern weil sie eine Abfrage in diesem Feld haben wollten, was bedeutete, dass sie es indizieren wollten und man es nicht in einer sich wiederholenden Gruppe indizieren konnte, oder zumindest nicht so einfach . Und das ist wahrscheinlich das Schlimmste, was ich je gesehen habe.

Dez Blanchfield: Ja, es ist interessant, wie oft man auf Datenbanken stößt. Ich denke, die Leute vergessen, dass es eine Wissenschaft ist. Und es gibt Leute, die in diesem ganzen Raum graduieren und promovieren, Papiere darauf schreiben, und Sie haben eine ganze Menge geschrieben, einschließlich Ihrer TOAD-Handbücher und anderer Dinge aus dem Gedächtnis. Der Trend zu einer Art von "Big Data" im Zitat - ich sehe eine Menge Leute, die die Grundlagen der Datenbankarchitektur und Datenbanktechnologie vergessen, wenn Sie so wollen, die Datenbankwissenschaft. Was sehen Sie auf diesem Gebiet, was die Abkehr von traditionellen Datenbankplattformen und dem traditionellen Datenbankdenken angeht, das wir effektiv auf den Boden gebracht haben, und es war nur ein Fall der Leistungsoptimierung und -skalierung. Sehen Sie eine Menge Leute, die neu lernen und eine Erfahrung haben, in der sie einfach nur da sitzen und einen „A-ha“ -Moment haben, wie in einem Eureka-Moment, in dem sie feststellen, dass dieses Big-Data-Zeug eigentlich nur eine Art wirklich großer Datenbanken ist? Ist das eine Sache da draußen und die Leute antworten dir und sagen: "Wir haben vergessen, was wir wussten und kannst du uns von der dunklen Seite zurückbringen?"

Bert Scalzo: Nun, nein, und das ist schrecklich zuzugeben, aber die Anbieter relationaler Datenbanken haben auch Kool-Aid getrunken. Wenn Sie sich erinnern, ich weiß nicht, haben wir vor etwa einem Jahrzehnt damit begonnen, unstrukturierte Daten in relationale Datenbanken zu packen, was seltsam war, und dann fügen die Daten, die relationalen Datenbanken, den NoSQL-Typ hinzu Zeug. Tatsächlich unterstützt CR2 in Oracle 12 - ich weiß, dass es noch nicht erschienen ist - das Sharding, wenn Sie sich die Beta ansehen, wenn Sie sich im Beta-Programm befinden. Jetzt haben Sie eine relationale Datenbank, die nicht das Konzept von NoSQL-Sharding enthält. Und so scheint der "a-ha" -Moment mehr für die Menschen auf der relationalen Seite zu sein, die "a-ha" werden. Niemand wird es jemals wieder richtig machen, nicht einmal die Datenbankmanager, also haben wir Ich muss rübergehen und mich der dunklen Seite anschließen.

Dez Blanchfield: Richtig, wenn ich richtig verstanden habe, sagen Sie eine Verschiebung zu vielen der unordentlichen Daten, die in die so genannten Big-Data-Plattformen eingespeist werden. Das ist irgendwie lustig, weil sie so sind nicht so alt, aber heißt das nicht, dass sie sich wieder auf das konzentrieren, was sie mit ihrer relationalen Datenbank tun, um mehr für ihr Geld zu bekommen?

Bert Scalzo: Nein, normalerweise, wenn sie ein Bedürfnis in der - das wäre ein "Big-Data-Type-Bedürfnis" gewesen, stellen sie fest, dass sie nicht auf die andere Datenbankplattform gehen und etwas in einer Non tun müssen Auf relationale Weise geben die Datenbankanbieter ihnen jetzt die gleichen nicht relationalen Techniken in ihrer relationalen Datenbank, um diese Dinge zu tun. Ich meine, ein gutes Beispiel wäre, wenn Sie unstrukturierte Daten haben, wie z. B. einen JSON-Datentyp oder einen anderen komplexen Datentyp, dessen Bedeutung in den Daten selbst enthalten ist. Die Datenbankanbieter unterstützen dies nicht nur, sondern geben Ihnen auch die ACID Compliance auf unstrukturierten Daten. Die relationalen Datenbanken haben die neueren Techniken und Technologien übernommen und so scheint das „a-ha“ eher nicht das zu sein: „Hey, wir, die Anwendungsentwickler, haben etwas verlernt und wir müssen es wieder lernen.“ Es ist „Hey, wir machen es jetzt so, wie kann ich es in Ihrer traditionell relationalen Datenbank so machen und wie in dieser Datenbank hier? ”und das wird immer häufiger, und wie gesagt, die Datenbankanbieter selbst ermöglichen es Das.

Dez Blanchfield: Richtig, wer sind die traditionellen Verdächtigen in diesem Bereich für das Tool DBArtisan und das? Ich habe einige Hausaufgaben über das gemacht, was Sie kürzlich geschrieben haben, und aus dem Gedächtnis heraus haben Sie etwas geschrieben, ich glaube, es war eines Ihrer Blogs über extreme Datenbankleistung in der Oracle-Welt. Ich kann mich nicht erinnern, wann es war, ich glaube, es war irgendwann in diesem Jahr aus der Erinnerung, oder seit Ende letzten Jahres, Sie hatten dieses Ding geschrieben. Und es schien mir, dass es der traditionelle, übliche Verdächtige für die Art von Thema war, von dem wir heute sprechen, bei dem die Leute in eine sehr umfangreiche Datenbankumgebung gehen und nach dem Ausschau halten, was Sie als extreme Gewinne bezeichnen. Wer sind die üblichen Verdächtigen, die Sie da draußen sehen, die DBArtisan aufgreifen und es sinnvoll einsetzen?

Bert Scalzo: Nun, wir haben eine Menge Kunden. Heute war ich bei einer sehr großen Regierungsbehörde, die buchstäblich fast 1.000 Kopien unserer Software hat, weil die Leute sich auf das konzentrieren können, was sie haben. tun, und nicht, wie es geht. Und es ist okay, ich meine, jeder sollte wissen, wie man etwas macht, aber Produktivität bringt das "Was" zustande. Wenn das Unternehmen mich auffordert, eine Aufgabe zu erledigen, ist das alles, woran sie interessiert sind. Wann habe ich ein Häkchen bekommen, das angibt, wann die Aufgabe erledigt wurde? Nicht mit welcher Technik oder mit welchem ​​Technobabble bin ich dorthin gekommen. Unser Tool ermöglicht es ihnen, sich auf das Wesentliche zu konzentrieren und produktiver zu werden. Dies ist der große Vorteil. Wie ich bereits sagte, bieten einige Datenbanken ein Tool nur für ihre Datenbankplattform an. Wir bieten es für zwölf Datenbankplattformen an. Ich habe den gleichen Workflow, die gleiche grafische Benutzeroberfläche, die gleiche Navigation. Wenn Sie wissen, wie Sie einem Benutzer Berechtigungen erteilen oder wie Sie eine Tabelle oder einen Index in einer Datenbank erstellen, können Sie dies in allen zwölf Fällen tun, da das Erscheinungsbild und der Workflow identisch sind. Das hat einen enormen Wert für unsere Kunden.

Dez Blanchfield: Ja, ich denke, die Leute wollen viel mehr für ihr Geld aus ihren Humanressourcen herausholen . Und die Zeiten, in denen ein einzelner Spezialist für Oracle, Ingres und DB2 tätig war, sind vorbei. Von den Menschen wird erwartet, dass sie der Alleskönner sind. Ich denke, diese Sache hat ihnen das Leben gerettet.

Nur eine letzte kurze Sache, bevor ich sie Doktor Robin Bloor übergebe. Sie haben erwähnt, dass es für vierzehn Tage einen kostenlosen Download gibt. Wenn ich weitermache und das mache, werde ich ihn übrigens im Bloor-Tech-Labor ablegen und das Ding drehen Mach es selbst - ich hatte bis heute keine Gelegenheit dazu gehabt. Sie haben eine 14-tägige Testversion erwähnt. Sie sagten, Sie führen sie auf einer VM auf Ihrem Computer aus. Ich gehe davon aus, dass es sich um einen Laptop handelt. Wie sieht es aus, wie sieht die Einstiegs-Konfiguration für jemanden aus, der die 14-Tage-Testversion nutzen kann, bevor ich Robin seine Fragen zurückgebe?

Bert Scalzo: Jede Windows-Umgebung, also Windows 7, virtuelle Maschine mit einer CPU und vier GB Arbeitsspeicher. Wir sind kein wirklich dickes oder teures Werkzeug. Wenn Sie nun Ihren Datenbankserver auf derselben VM unter demselben Windows ausführen möchten, müssen Sie zwar weitere hinzufügen, aber wenn Sie Ihre Datenbank auf einem Datenbankserver oder einer separaten VM ausführen, muss die VM geladen und installiert werden Unser Produkt ist sehr leicht: eine CPU, vier Gigabyte Speicher, so ziemlich jede Windows-Version - und wir unterstützen sowohl 32- als auch 64-Bit-Installationen. Sie müssen jedoch den Client Ihres Datenbankanbieters installieren. Wenn Sie eine Verbindung zu Oracle herstellen möchten, müssen Sie den SQL Net-Client installieren, da Oracle dies benötigt, damit Sie mit einer Datenbank kommunizieren können.

Dez Blanchfield: Das klingt ziemlich einfach. Ich denke, dass eine Sache davon mehr ist als alles andere, von dem ich hoffe, dass die Leute es mitnehmen werden, als die Erkenntnis, dass dieses Tool ihr Leben retten wird, dass sie es herunterladen und damit spielen sollten. vorausgesetzt, Sie bieten eine 14-tägige kostenlose Testversion an. Und es kann auf ihrem aktuellen Laptop ohne zusätzliche Installation ausgeführt werden, da sie, wenn sie bereits Datenbankadministration durchführen, bereits mit Datenbanken arbeiten, über all diese Tools verfügen und ob diese auf einer lokalen VM oder auf ihrer ausgeführt werden Es hört sich so an, als wäre es schmerzlos, einen lokalen Desktop zu installieren und damit zu spielen. Daher empfehle ich den Leuten, das zu tun.

Robin, ich bin sicher, Sie haben Fragen und Eric, wahrscheinlich haben Sie einige aus dem Publikum, also Robin, wie wäre es, wenn ich an Sie und dann zurück an Eric übergebe?

Robin Bloor: Ja, okay, ich habe einiges zu sagen, ich meine, ich fand diesen Bereich immer faszinierend, weil er war - ich habe meine Zähne geschnitten. Aber die Wahrheit ist, dass ich wahrscheinlich seit 1998, 1999, nicht mehr weiß, wozu Oracle tatsächlich in der Lage ist. Und ich kannte Sybase und Microsoft SQL Server. Beide sind ziemlich einfach im Vergleich zu den Möglichkeiten von Oracle. Du hast mich zum Lachen gebracht, als du - ich meine, ich habe meinen Mund zugedeckt, als du angefangen hast, über Scherben zu reden. Oracle hat das schon einmal gemacht. Oracle wurde irgendwann eingeführt, und sie wurden nervös wegen der objektrelationalen Idee. Sie führten die Möglichkeit ein, eine Art Objektnotation und Objektspeicher in Oracle zu erstellen, und ich sprach mit einem ihrer Ingenieure, so etwas wie ein paar Jahre nachdem sie es eingeführt hatten und ich fragte, wie viele Leute es benutzten, und er sagte, ich glaube, zwei Kunden hätten es ausprobiert und das war es. Und ich denke, dasselbe wird passieren, wenn sie anfangen, NoSQL-Trends zu entwickeln. Weißt du, ich denke, es ist ein Fehler. Ich meine, ich bin irgendwie daran interessiert, was deine Gedanken sind. Sicher, die - sie trinken die Kool-Aid. Sie haben das Gefühl, dass sie in der Lage sein müssen, Ansprüche zu erheben, die den großen NoSQL-Datenbanken wie Cassandra ähneln, aber wissen Sie, macht es für Sie Sinn?

Bert Scalzo: Nein, Sie haben den Nagel direkt auf den Kopf getroffen. Für mich würde ich, wenn ich relational arbeiten möchte, einen relationalen Anbieter wie Oracle, SQL Server, DB2 oder Postgres auswählen, aber wenn ich etwas tun möchte, das nicht relational ist, Im Big-Data-Bereich oder im NoSQL-Bereich werde ich das richtige Tool für den richtigen Job auswählen. Und ich denke nicht, dass das natürlich zuerst meinem relationalen Datenbankanbieter überlassen würde. Und dann fügen Sie die andere Falte hinzu: Was ist in der Cloud verfügbar? So viele Leute, die ihre Datenbanken von der Prämisse bekommen wollen. Dann müssen Sie sich Ihren Cloud-Anbieter ansehen und sagen: „Okay, was bieten Sie an, welche Datenbanken stehen für mich zur Verfügung, die meinen Anforderungen entsprechen und wie gut sie sind, und ehrlich gesagt, wie hoch ist der Preis oder die Gebühr für die Nutzung dieser Datenbank? in der Wolke pro Stunde oder pro Tag. Und pro Gigabyte oder Terabyte? “Und Sie werden vielleicht einige der relativ neueren Datenbanken wie Mongo oder Cassandra vorfinden. Vielleicht sind ihre Raten günstiger. Wenn Sie also große Datenmengen mit mehreren Petabyte erstellen, könnten Sie das auch tun müssen - nur aus Kostengründen - die NoSQL-Datenbanken in der Cloud berücksichtigen, da sie möglicherweise die kostengünstigste Möglichkeit sind, dies zu tun.

Robin Bloor: Ja, richtig. Ich meine, meine Art von - die Sache mit relationalen Datenbanken nach meiner Erfahrung - die lange genug ist, um Narben zu hinterlassen, das ist sicher - es gibt einen gesunden Menschenverstand, dass, wenn Sie anfangen, sie anzuwenden, und - Sie verstehen, was relational tatsächlich ist, das Ich meine, ich erinnere mich, dass ich einmal mit einem Kunden eine Beratung durchgeführt habe, und sie führten mich in einen Raum, und sie hatten eine Art Entitätsdiagramm erstellt und eine dritte Normalform erstellt, ein Modell dessen, wie die Primärsysteme des Unternehmens aussahen. Es gab ungefähr zweihundertvierzig Tische und sie sagten: „Nun, was denkst du darüber? Wir werden dafür eine Datenbank aufbauen “und sagten:„ Was halten Sie davon? “Ich sagte:„ Ich glaube nicht, dass es funktionieren wird. “Und es ist genau richtig, weißt du, weil sie enden up, um innerhalb von 11-Wege-Joins eine bestimmte Struktur zu schaffen. Und das ist das, was man über relationale Beziehungen verstehen muss. Es interessiert mich also, auf wie viel schlechtes Design Sie stoßen. Ich meine, ich habe kein Problem mit DBArtisan - es macht sehr vernünftige Dinge und die Tatsache, dass Sie tatsächlich auf mehreren Plattformen anzeigen können, finde ich wunderbar - aber wie viel stößt man da draußen an, wo das Design eine Rolle spielt wo die Leute sich allerlei Herzschmerz hätten lösen können, wenn sie auf ein Sternschema gekommen wären, anstatt Schneeflocken darüber zu bekommen, weißt du?

Bert Scalzo: Nun, ich möchte nicht anmaßend oder arrogant klingen, aber ich würde es öfter sagen als nicht. Es ist klar, dass die meisten Datenbanken, mit denen ich mich beschäftige, Probleme oder Probleme haben. Das ist gut so, denn unsere Tools, wie unser Tool zur Datenbankoptimierung, können ihnen helfen, diese Probleme zu lösen. Was mir aber wirklich komisch ist, ist, dass viele der Probleme immer wieder dieselben einfachen Probleme sind. Ich habe neulich nur mit einem Kunden gearbeitet, der eine 11-Wege-Join-Abfrage hatte, und ich frage: "Okay, warum haben Sie keine with-Klausel verwendet?" Ich weiß nicht, was das ist. “Und dann sagte ich:„ Und sehen Sie sich Ihre Unterauswahlen hier auf Ihrer korrelierten und Ihrer nicht korrelierten an. “Ich sagte:„ In einigen Fällen haben Sie in Ihrer where-Klausel die tiefste Ebene. Eine Tabellenreferenz aus der äußeren. “Ich sagte:„ Das heißt, bewegen Sie sie auf die richtige Ebene, betten Sie sie nicht tiefer ein, als es sein muss, Sie werden den Optimierer verwirren. “Und mit ein paar Änderungen werden wir nahm etwas, das ungefähr zwei Stunden lief und es auf zehn Minuten reduzierte, und es war nur so - in diesem Fall haben wir nichts anderes getan, als die SQL zu verbessern, die sie geschrieben hatten. Ich denke, das Problem ist, dass viele Universitäten und viele Leute, die Programmieren in einem nicht akademischen Umfeld lernen, es als zeitaufgezeichnete Prozesse oder zeilenorientierte Prozesse und relationale Prozesse lernen, eine Menge, die von Natur aus orientiert ist, und Sie müssen in Mengen denken, um gutes SQL zu schreiben.

Robin Bloor: Ja, ich denke das ist genau richtig. Und man muss verstehen, es sind Dinge wie, die Leute sollten das ABC von solchen Dingen kennen. Es spielt keine Rolle. Sie können keine rationalen Dinge tun, wenn Sie nicht erkennen, dass selbst eine gut gestaltete, gut modellierte Datenbank, Verknüpfungen und Sortierungen Zeit benötigen. Sie tun es, weil die Welt noch nie einen Weg gefunden hat, diese zu beschleunigen. Sie haben Möglichkeiten gefunden, die Daten so zu organisieren, dass sie schneller als die anderen sind, und ein großer Teil der Begeisterung, die ich für die NoSQL-Datenbanken zu sagen habe, besteht darin, dass sie Joins vermeiden. Sie fangen einfach an, die Datenbanken mit der gleichen Datenverbreitung zu erstellen, denn wenn Sie sich einer der NoSQL-Datenbanken anschließen, sind sie ziemlich nervig. Denkst du nicht?

Bert Scalzo: Oh, absolut. Und ich muss lachen, weil ich vor relationalen Datenbanken angefangen habe und als Ingres RTI, Relational Technology Institute, war und wir kein SQL hatten, hatten wir relationale Sprachen vor SQL. Ich glaube, in Ingres hieß es damals Quel. Sie haben sich also von diesen alten Datenbankparadigmen wie dem Netzwerk und einer höheren Grafik oder Hierarchie gelöst und gehen nach ein paar Jahrzehnten die relationalen Paradigmen durch. Für mich fühlt es sich an, als würden wir wieder fast zu einer Hierarchie zurückkehren. Es ist fast so, als wären wir zurückgekehrt.

Robin Bloor: Ja, richtig. Gib dich lieber an Eric weiter, ich brauche zu viel Zeit, aber haben wir irgendwelche Fragen vom Publikum, Eric?

Eric Kavanagh: Wir haben ein paar. Wir machen hier eine Weile, aber ich werfe ein paar auf dich. Wir hatten ein paar Fragen zu den unsichtbaren Indizes. Eine Frage war: "Muss jemand Ihr Werkzeug verwenden, um diese zu sehen?" Eine andere Frage war: "Nun, was ist, wenn Sie blind sind?"

Bert Scalzo: Das ist gut.

Eric Kavanagh: Neugierige Frage, also nur zu Ihrer Information.

Bert Scalzo: Nein, Sie müssen nicht über unsere Werkzeuge verfügen. Das ist eine Oracle-Funktion, der Unsichtbare-Index. Grundsätzlich behält Oracle im Datenwörterbuch nur einen Teil der Metadaten bei, der besagt: „Optimierer, ignorieren Sie diesen Index. Verwenden Sie diese Option nicht, es sei denn, Sie werden physisch über einen Hinweis in, einen Optimierungshinweis im SQL-Befehl, angewiesen. “Nein, Sie müssen nicht über unsere Tools verfügen, und dies in jeder Hinsicht Ist ein einfacher alter Index, den Sie in jedem Tool sehen können, sagt der Optimierer lediglich: "Wir werden ihn bei der normalen Abfrageverarbeitung ignorieren." Sie müssen ihn anweisen, wenn Sie ihn verwenden möchten. Es ist sehr praktisch für das von mir beschriebene Szenario: Wenn Sie einen Index in der Produktion erstellen möchten, aber nicht riskieren, die Berichte zu beschädigen, oder die Dinge, die bereits ausgeführt werden, aber Sie möchten sie testen, können Sie dies tun. Dafür ist es am nützlichsten.

Eric Kavanagh: Das ist gutes Zeug und dann gab es hier noch eine gute Frage. „Was ist mit einigen dieser neuen In-Memory-Datenbanken? Wie verändert die In-Memory-Datenbanktechnologie das Spiel in Bezug auf die Indizierung? “

Bert Scalzo: Junge, na ja, das ist gut. Ich bin froh, dass jemand diese Frage gestellt hat. Wir müssen noch eine halbe Stunde gehen. Nein, der In-Memory-Speicher hängt vom Datenbankanbieter ab. Normalerweise spreche ich nichts anderes als Lob für alles, was Oracle tut, denn es ist erstaunlich, welche Technologie sie entwickelt haben. Wenn Sie sich jedoch zurückziehen und sich ansehen, was sich in Oracle im Arbeitsspeicher befindet, in Oracle Datenbank, was es in Wirklichkeit ist, ist, dass der Zeilenspeicher immer noch auf der Festplatte gespeichert ist und der Spaltenspeicher im Arbeitsspeicher geladen wird. Wenn nicht genügend Arbeitsspeicher vorhanden ist, um die gesamte Tabelle zu speichern, wird für die Teile auf zurückgesetzt. es passt nicht in den Speicher, um es zu tun Zeilenspeicherung, und so können Sie tatsächlich eine Auswahl gegen die Tabelle und für die Hälfte der Tabelle, verwenden Sie eine Indexierung, die traditionelle Zeilen an der Tabelle trifft, und für die andere Hälfte von Die Auswahl, die es tatsächlich gibt, greift nur auf eine Suche im Arbeitsspeicher zurück und unterscheidet sich daher in der Art und Weise, in der SQL Server sie beispielsweise mit der Hekaton-Technologie, die Sie kennen, und SQL 2014 implementiert hat, und sie wurde verbessert In SQL 2016 ist ihre Version jedoch in mancher Hinsicht eine zutreffendere Version von In-Memory, und zwar hat jede Implementierung Vor- und Nachteile, aber Sie müssen ein bisschen hinter die Kulissen schauen und erkennen. Denn ich hatte einen Kunden, der sagte: "Oh, diese Tabelle ist im Speicher - ich werde nur alle Indizes erstellen." Und ich dachte: "Die Tabelle ist größer als der Speicher, den Sie auf dem Server haben." Irgendwann muss also ein Teil der Abfrage auf die Festplatte. “

Eric Kavanagh: Das ist eine gute Beschreibung. Das ist gutes Zeug. Nun, Leute, wir werden im Laufe dieses Jahres ein paar weitere Webcasts mit diesen Jungs machen. Komme immer wieder, wenn du hörst, dass Bert auf einer Präsentation ist, weil wir wissen, dass er sich auskennt. Es macht immer Spaß, mit den Experten zu sprechen. Wir archivieren alle diese Webcasts zur späteren Ansicht. Hier sind noch einmal Berts Kontaktinformationen, und wir werden versuchen, diesen Link für den Download zu finden und ihn auch per E-Mail zu versenden. Sie können jedoch jederzeit Ihre E-Mail-Adresse an uns senden: Wir haben eine Reihe weiterer Webcasts für diesen Zweck auf Lager Jahr und wir machen gerade den Anfang. Also, Leute, wenn es Themen gibt, über die ihr nächstes Jahr wirklich etwas hören wollt, seid nicht schüchtern: Pass auf, Leute, wir werden uns beim nächsten Mal mit euch unterhalten. Tschüss.

Techopedia Content Partner

Techopedia Staff ist mit der Bloor Group verbunden und kann über die Optionen auf der rechten Seite kontaktiert werden. Informationen zur Zusammenarbeit mit Industriepartnern finden Sie hier.

• Profil
• Webseite