Performance verschiedener Ansätze zu zeitbasierten Daten

Einerseits ist es gut, dass Sie eine neue Frage eröffnet haben. Aber auf der anderen Seite geht durch das Extrahieren einer Abfrage und die Frage, ob sie schneller funktioniert, der Kontext der vorherigen Frage verloren, die neue Frage ist zu isoliert. Wie Sie sicher wissen, gehören das Verwalten einer Datenbank, das Verwalten von Ressourcen (Speicher/Cache, Festplatte, CPU-Zyklen) und das Verwalten von Code (gut oder schlecht), der diese Ressourcen verwendet, zum Gesamtbild. Leistung ist ein Handelsspiel, nichts ist umsonst.

Das wichtigste Problem, das ich hatte, war die Duplizierung der EndDate-Spalte, die leicht abgeleitet werden kann. Doppelte Spalten entsprechen Aktualisierungsanomalien. Smirkingman hat das klassische Beispiel geliefert:Einige Abfragen erhalten ein Ergebnis und andere Abfragen das andere. Das ist für große Organisationen einfach nicht akzeptabel; oder in Banken (zumindest in entwickelten Ländern), wo die Daten geprüft und geschützt werden. Sie haben gegen eine grundlegende Normalisierungsregel verstoßen, und es müssen Strafen gezahlt werden.
- Anomalien aktualisieren; zwei Versionen (bereits detailliert). Auditoren dürfen das System nicht bestehen.
- Tabellengröße
  In jeder großen Tabelle ist dies ein Problem, insbesondere bei Zeitreihen oder zeitlichen Daten, bei denen die Anzahl der Spalten klein und die Anzahl der Zeilen riesig ist. Also, einige werden sagen, Speicherplatz ist billig. Ja, das sind sexuell übertragbare Krankheiten. Entscheidend ist, wofür es verwendet wird und wie gut man es pflegt.
  - Speicherplatz
    Kann auf einem PC günstig sein, auf einem Produktionsserver ist er es nicht. Im Grunde haben Sie 62 % zur Zeilengröße (13 plus 8 gleich 21) und damit zur Tabellengröße hinzugefügt. Bei der Bank, der ich derzeit zugeteilt bin, wird jede Abteilung, die Eigentümer der Daten ist, wie folgt abgerechnet, SAN-basierter Speicher ist alles, was es gibt. Die Zahlen beziehen sich auf pro GB und Monat (dies ist keine australische High-End-Bank):
    
    1,05 $ für RAID5 Unmirrored
    (Wir wissen, dass es langsam ist, aber es ist billig, schreiben Sie einfach keine wichtigen Informationen darauf, denn wenn es kaputt geht, nachdem die neue Festplatte heiß oder kalt ausgetauscht wurde, dauert es Tage, bis es fertig ist um sich selbst neu zu synchronisieren.)
    
    2,10 $ für RAID5 Mirrored
    Das heißt, im SAN.
    
    4,40 $ für RAID1+0
    Minimum für Produktionsdaten, gesicherte Transaktionsprotokolle und nächtliche Datenbank-Dumps.
    
    9,80 $ für RAID1+0-Replikation
    auf ein identisches SAN-Layout an einem anderen, bombensicheren Standort. Produktionsumschaltung in Minuten; fast null Transaktionsverlust.
  - Speicher/Cache
    Ok, Oracle hat es nicht, aber die seriösen Bankdatenbanken haben Caches, und sie werden verwaltet. Bei einer bestimmten Cache-Größe passen nur 62 % der Zeilen in dieselbe Cache-Größe.
  - Logische und physische I/O
    Das bedeutet 50 % mehr I/O zum Lesen der Tabelle; sowohl Streaming in den Cache als auch Lesevorgänge auf der Festplatte.
Ob die Abfrage isoliert besser oder schlechter abschneidet, ist daher eine akademische Frage. Im Zusammenhang mit dem oben Gesagten die Tabelle ist langsam und arbeitet bei jedem Zugriff ständig um 62 % schlechter. Und es betrifft jeden anderen Benutzer auf dem Server. Den meisten DBAs wird es egal sein (ich würde es sicherlich nicht), wenn das Unterabfrageformular nur halb so schnell arbeitet, weil ihr Bonus an die Prüfungsakzeptanz gebunden ist, nicht nur an die Codeleistung.
- Außerdem gibt es den zusätzlichen Vorteil, dass Code nie erneut aufgerufen und Transaktionen aufgrund von Aktualisierungsanomalien korrigiert werden müssen.
- Und die Transaktionen müssen weniger Punkte aktualisieren, also sind sie kleiner; weniger blockierende Sperren usw.
Einverstanden, dass die Diskussion in den Kommentaren schwierig ist. In meiner Antwort habe ich zwei Unterabfragen detailliert und erläutert. Es gab ein Missverständnis:Sie sprachen von dieser Unterabfrage (in der WHERE-Klausel eine Tabellen-Unterabfrage ) und ich sprach über die andere Unterabfrage (in der Spaltenliste eine skalare Unterabfrage). ), wenn ich sagte, dass es so schnell oder schneller durchführt. Nun, da das geklärt ist, kann ich nicht sagen, dass die erste Abfrage oben (Unterabfrage in der WHERE-Klausel, eine Tabelle) genauso schnell ausgeführt wird wie die zweite Abfrage (mit der duplizierten Spalte); der erste muss 3 Scans durchführen, während der zweite nur 2 Scans durchführt. (Ich wage jedoch zu sagen, dass der zweite Tabellenscan durchführt.)

Der Punkt ist, zusätzlich zum Isolationsproblem, dass es kein fairer Vergleich ist, ich habe den Kommentar zu skalaren Unterabfragen gemacht. Ich würde nicht vorschlagen, dass eine 3-Scan-Abfrage genauso schnell oder schneller ist als eine 2-Scan-Abfrage.

Die Aussage, die ich über die 3-Scan-Tabellen-Unterabfrage gemacht habe (die ich hier zitiere), muss im vollständigen Kontext betrachtet werden (entweder dieser Beitrag insgesamt oder der obige). Ich weiche nicht davor zurück.

Ich verbringe mein halbes Leben damit, illegale Alternativen wie doppelte Spalten zu entfernen, die auf der Frage der Leistung basieren, wobei die Schöpfer das Mantra singen, dass der Tisch langsam ist, also haben sie "für Leistung denormalisiert". Das Ergebnis, vorhersehbar, bevor ich anfange, ist ein halb so großer Tisch, der insgesamt doppelt so schnell arbeitet . Die Times Series ist hier die häufigste Frage (der Link verlinkt auf eine andere Frage; die verlinkt auf eine andere), aber stellen Sie sich das Problem in einer Bankendatenbank vor:täglich OpeningExposure und ClosingExposure pro Security pro Holding proUnitTrust proPortfolio .
Aber lassen Sie mich eine Frage beantworten, die nicht gestellt wurde. Diese Art der Interaktion ist normal, nicht ungewöhnlich bei der Arbeit mit internen Entwicklungsteams; es kommt mindestens einmal im Monat. Ein Crash-heißer Entwickler hat seinen Code bereits geschrieben und getestet, indem er eine Tabelle mit einer duplizierten Spalte verwendet hat, er fliegt, und jetzt ist er ins Stocken geraten, weil ich ihn nicht in die Datenbank einfügen werde.

Nein, ich werde es im Kontext des Gesamtsystems testen und:
- In der Hälfte der Zeit wird die Tabelle ohne die EndDate-Spalte eingefügt, da es keine große Sache ist, wenn eine Abfrage von einer halben Sekunde jetzt in einer Sekunde ausgeführt wird.
- In der anderen Hälfte der Zeit ist die Leistung der [Tabellen-Unterabfrage] nicht akzeptabel, daher implementiere ich einen booleschen (Bit-)Indikator, um IsCurrent zu identifizieren . Das ist viel besser als eine duplizierte Spalte und bietet 2-Scan-Geschwindigkeiten.
- Nicht in einer Million Jahren wirst du mich dazu bringen, eine Spalte zu duplizieren; Hinzufügen von 62 % zur Tabellengröße; Verlangsamung der Tabelle im vollständigen Mehrbenutzerkontext um 62 %; und riskieren, ein Audit nicht zu bestehen. Und ich bin kein Angestellter, ich bekomme keinen Bonus.
Nun, das wäre einen Test wert:Abfrage mit einer duplizierten Spalte vs. Abfrage mit IsCurrent Indikator im vollen Kontext der gesamten Ressourcennutzung.
Smirkingman hat einen guten Punkt angesprochen. Und ich werde es deutlich wiederholen, damit es nicht fragmentiert wird und dann das eine oder andere Fragment angegriffen wird. Bitte brechen Sie dies nicht auf:

Eine relationale Datenbank,
normalisiert von einem erfahrenen relationalen Modellierer, auf wahre fünfte Normalform
(keine Aktualisierungsanomalien; keine doppelten Spalten),
mit voller relationaler Compliance
(IDEF1X, insbesondere in Bezug auf die Minimierung von Id Primärschlüssel; und somit die Leistung der relationalen Engine nicht lähmen)
führt zu mehr, kleineren Tabellen, einer kleineren Datenbank,
mit weniger Indizes,
erfordert weniger Joins
(das stimmt, mehr Tabellen, aber weniger Joins),
und es wird alles übertreffen, was gegen eine dieser Regeln verstößt
auf derselben Hardware und Unternehmen db-Plattform
(ausgenommen Freeware, MS, Oracle; aber lassen Sie sich davon nicht aufhalten),
im vollen Kontext der produktiven OLTP-Nutzung
um mindestens eine Größenordnung,
und es wird viel einfacher zu verwenden
und zu ändern
(braucht nie "Refaktorisierung").

Ich habe das mindestens 80 Mal gemacht. Zwei Größenordnungen sind keine Seltenheit, wenn ich es selbst mache, anstatt jemand anderem den Rahmen dafür zu geben.

Weder ich noch die Leute, mit denen ich arbeite oder die mich bezahlen, interessieren sich dafür, was eine einzelne Abfrage bewirkt.