Indexierte Ansichten in OLTPs?

Question

Ich kenne SQL Server Indexed Views (oder Oracle Materialized Views), wir verwenden sie in unseren OLAP-Anwendungen. Sie haben das wirklich coole Feature, einen Ausführungsplan an sich zu reißen und ihn in die indizierte Sicht umzuordnen, ohne den bestehenden Code ändern zu müssen.

IE. Angenommen, ich hatte einen SPROC, der eine wirklich teure Verbindung war.

SELECT [Einige Spalten]
FROM Tabelle1 INNER JOIN Tabelle2 [Details]
INNER JOIN Table3 [STRAUSS MEHR JOINS] ...

Wenn ich eine indizierte Sicht verfasst, die ein gehaltener ähnliche Ergebnismenge dann wird der Query Optimizer sehr wahrscheinlich die SPROC an meine indizierte Sicht im Gegensatz zu den Basistabellen senden und ich bekomme eine große Leistungssteigerung.

Jetzt sagen, ich wollte indizierte Sichten in einem OLTP verwenden !? Ich meine die meisten OLTPs (wie diese Seite) sind relativ lese schwer, wenn sie teure Joins haben, dann könnten wir sie um eine Tonne beschleunigen und möglicherweise die Sperrkonkurrenz reduzieren (http://www.codinghorror.com/blog/archives/001166.html). Noch besser ist es, wenn Sie keinen Code ändern müssen, sondern nur die indizierte Sicht erstellen.

Das bedeutet aber auch die Datenbank größer wird, da wir eine Kopie dieser Daten in der indizierten Sicht halten müssen ...

Hat jemand jemals indizierte Sichten verwendet, um Streit oder Fehler in einem OLTP zu lösen? Wieso habe ich das noch nie gesehen?

Answer 1

Materialisierte Ansichten können für das Reporting mit OLTP nützlich sein, insbesondere wenn eine große Anzahl von Zeilen aggregiert ist, um die Ergebnisse zu erhalten. Der Speicherplatzbedarf hängt vollständig davon ab, wie viele Daten Sie speichern. Stellen Sie es sich als Cache vor.

Das knifflige Verhältnis besteht darin, wie aktuell die Daten für die Berichte sein müssen und wie viel von einem Treffer bei der OLTP-Leistung zu erwarten ist. Wenn etwas veraltete Daten in Ordnung sind, können Sie möglicherweise die Aktualisierungen für die Ansichten zu einem Zeitpunkt planen, wenn die Systemaktivität niedrig ist.

Die eine Zeit konnte ich nicht, und brauche sehr aktuelle Daten, ich endete mit einigen benutzerdefinierten Entwicklung. Bei jeder Aktualisierung der Basistabelle wurde ein Trigger ausgelöst, der einen Datensatz in eine Transaktionstabelle geschrieben hat. Die Ansicht betrachtete ein zwischengespeichertes Aggregat sowie das in der Transaktionstabelle gespeicherte Delta. Bei zulässigen Systemressourcen wurden die Transaktionen als Delta-Transaktionen auf die Gesamttabelle angewendet. Dies erlaubte mir bis zu den zweiten Daten, eine gute Performance beim Reporting (die einzige Aggregation geschah bei kürzlichen Transaktionen) und eine relativ geringe Belastung der Datenbank (nur Verdopplung der Größe jedes Schreibens, nicht jedes Mal ein riesiges Aggregat neu zu berechnen).

Leider war es komplex zu pflegen und verwendete keine einfachen eingebauten Tools. Wenn Sie auf Ihre Berichtsdaten warten können, empfiehlt es sich häufig, die integrierten materialisierten Ansichten zu verwenden und die Aktualisierung zu verschieben.

Answer 2

Wir verwenden materialisierte Ansichten, um Dinge zu beschleunigen, wo ich arbeite. Meistens für Berichte gegen das OLTP-System. Viele unserer Berichte laufen von einem Data Warehouse, aber da wir das Lagerhaus über Nacht auffrischen, müssen die Daten aus den OLTP-Tabellen stammen.