Gespeicherte Prozedur aus der Perspektive einer verteilten Datenbank

Die gespeicherte Prozedur ist sehr gut. Wer sie nicht gut nutzt, hat schlechte Fähigkeiten und akzeptiert keine Widerlegungen! Ich hatte diese Idee, aber für verteilte Datenbanken bevorzuge ich die Verwendung weniger oder gar keiner gespeicherten Prozeduren.

1 Ich komme aus der C/S-Ära

Die beliebtesten Entwicklungskits am Ende der Ära der C/S-Architektur sind PowerBuilder und Sybase-Datenbanken:

• Das visuelle Entwicklungstool PowerBuilder wie VB führt das entwickelte Programm auf dem PC-Terminal des Benutzers aus und stellt über den Treiber eine Verbindung zur Remote-Datenbank her
• Sybase konkurrierte zu dieser Zeit mit Oracle um den Datenbankkopf und hatte eine enge Beziehung zu SQL Server, und die beiden waren sich in Architektur und Sprache sehr ähnlich.

In dieser C/S-Architektur übernimmt die Datenbank nicht nur Datenspeicher- und Rechenfunktionen, sondern führt auch umfangreiche Geschäftslogik aus, was der Datenbank entspricht, die die meisten Funktionen des Anwendungsservers (Application Server) übernimmt. Der technische Träger dieser Geschäftslogiken ist die gespeicherte Prozedur. Daher sind ihre gespeicherten Prozeduren unabhängig davon, ob es sich um Sybase oder Oracle handelt, sehr leistungsfähig.

2 Auslöser werden verworfen

Mit dem Eintritt in B/S hat sich das Verständnis aller über die Datenbank geändert, und der Anwendungsserver trägt die Hauptgeschäftslogik des Servers. Verwenden Sie also immer noch gespeicherte Prozeduren? Gleiches Problem wie heute. Die damals vorherrschende Ansicht war, dass gespeicherte Prozeduren immer noch einen Wert hatten, ihre Geschwister-Trigger jedoch völlig aufgegeben wurden.

Trigger sind benutzerdefinierte Funktionen wie gespeicherte Prozeduren, aber:

• Es wird nicht explizit aufgerufen, sondern passiv ausgelöst, wenn die Datentabelle bedient wird, also wenn Einfügen, Aktualisieren und Löschen ausgeführt werden
• Sie können auch auswählen, ob der Triggerzeitpunkt vor oder nach der Operation liegt, also die Semantik von vorher und nachher

Klingt kraftvoll, ein bisschen ereignisorientierte Programmierung. Aber nachdem ich die Triggerlogik beibehalten hatte, stellte ich fest, dass dies eine große Grube war. Während sich das Unternehmen weiterentwickelt und verändert, wird die Logik des Auslösers immer komplexer. Jemand manipuliert eine andere Tabelle in der Logik des Auslösers, und es gibt andere Auslöser auf dieser Tabelle, die andere Tabellen implizieren und ein Skynet bilden. Ein kleiner falscher Schritt wird nach einer Reihe von Kettenreaktionen zur Katastrophe. Daher hat sich der Auslöser von der Bühne der Geschichte zurückgezogen. (Ich habe immer noch das Gefühl, dass es nicht zu viele Einschränkungen gibt, die zu Missbrauch führen)

3 Vorteile gespeicherter Prozeduren

Der Anruf ist klar und es gibt kein Auslöseproblem. Die Vorteile liegen auf der Hand: Die Logik läuft in der Datenbank und es gibt keinen Overhead für Netzwerkübertragungsdaten, sodass der Leistungsvorteil bei der Durchführung datenintensiver Vorgänge hervorragend ist.

Zu diesem Zeitpunkt war es notwendig, Funktionen zu entwickeln und die Einflussbeziehung zwischen Geschäftseinheiten zu verfolgen. Beispielsweise beeinflusst A B und B C. Diese Funktion besteht darin, A als Eingabe zu verwenden, um sowohl B als auch C herauszufinden. Natürlich ist die Einflussbeziehung nicht auf drei Ebenen beschränkt und muss auf alle betroffenen Entitäten zurückgeführt werden.

Typische relationale Abfragen eignen sich für Graphdatenbanken. Zu diesem Zeitpunkt war jedoch keine Diagrammdatenbank verfügbar und dieses Problem musste in Oracle gelöst werden. Ein Kollege, der jünger ist als ich, hat einen Java-Code geschrieben, um diese Funktion zu erreichen. Ich vermute, er hat die C/S-Ära noch nicht erlebt. Nachdem das Programm ausgeführt wurde, greift der Anwendungsserver kontinuierlich auf diese Tabelle zu, um die Zuordnungsbeziehung jedes Datensatzes zu verarbeiten. Die Leistung kann man sich vorstellen: In einer Testumgebung mit einer kleinen Datenmenge lief das Programm ganze 30 Minuten. Dies liegt weit außerhalb der Toleranz des Benutzers und muss optimiert werden.

Um die gleiche Logik zu erreichen, bin ich auf eine gespeicherte Prozedur umgestiegen, da keine Netzwerkübertragung erforderlich ist und die Leistung erheblich verbessert wird. Am Ende benötigte die gespeicherte Prozedur etwa zwanzig Sekunden, um das gleiche Ergebnis zu erzielen. Gut gemacht! .

4 Probleme mit gespeicherten Prozeduren

Später stellte sich heraus, dass dieses Programm schlecht transplantierbar war. Die entwickelten Produkte sollen vorbehaltlich der Einschränkungen der jeweiligen Basissoftware in der Kundenumgebung eingesetzt werden.

Einmal kam es vor, dass der Kunde kein Oracle nutzte, also übersetzten andere Kollegen die von mir geschriebene Logik in die vom Kunden verwendete Datenbank. Die gespeicherte Prozedur, die in die TDB übertragen werden kann, wird nicht ohne Ergebnisse beendet. Nachdem ich diesen Code verfolgt hatte, stellte ich schließlich fest, dass das Problem nicht in der Logik selbst, sondern in der Datenbank liegt. Ich habe in dieser Logik einen rekursiven Algorithmus verwendet, da Oracle eine tiefe rekursive Ebene unterstützt, sodass die Ausführung kein Problem darstellt. TDB unterstützt hingegen nur eine begrenzte rekursive Ebene und es gab zu diesem Zeitpunkt viele Datenzuordnungen, sodass das Programm einen Fehler meldete nach kurzer Zeit beendet. .

Diese Erfahrung hat mein Vertrauen in gespeicherte Prozeduren ein wenig erschüttert. Gespeicherte Prozeduren sind stark von der Umgebung abhängig, und diese Umgebung ist keine offene Umgebung, die einem einheitlichen Standard folgt und über eine große Menge technischer Informationen wie das Betriebssystem und die Java Virtual Machine verfügt, sondern eine Blackbox, die nicht so dem Standard entspricht als Datenbank.

Die Probleme mit gespeicherten Prozeduren hören hier jedoch nicht auf. Als ich unter der C/S-Architektur entwickelte, stieß ich auf das Problem, dass die gespeicherte Prozedur schwer zu debuggen war, aber damals dachten alle, dass dies der Preis sei, der gezahlt werden müsse. Mit dem Aufkommen der B/S-Architektur und der kontinuierlichen Weiterentwicklung der Java-Code-Entwicklungs- und Testtechnologie ist das Problem des schwierigen Debuggens gespeicherter Prozeduren jedoch stärker in den Vordergrund gerückt. Heutzutage wird die agile Entwicklung immer beliebter, die DevOps-Toolkette entwickelt sich rasant und die gespeicherte Prozedur ist immer noch „unabhängig“.

Nachdem ich so viel gesagt habe, hoffe ich, dass Sie verstehen, dass die heutigen gespeicherten Prozeduren und die Auslöser dieses Jahres im Wesentlichen mit demselben Problem konfrontiert sind: Eine Technologie muss dem technischen Niveau der Zeit entsprechen und sich in die gesamte Technologieökologie integrieren, andernfalls wird sie aufgegeben die meisten Anwendungsszenarien .

Sie sehen, im „Alibaba Java Development Manual“ steht auch eindrucksvoll geschrieben, dass „die Verwendung gespeicherter Prozeduren verboten ist. Gespeicherte Prozeduren sind schwer zu debuggen und zu erweitern, und sie sind nicht portierbar.“ Ich denke, sie haben wahrscheinlich etwas Ähnliches Mentalität für mich.

5 Unterstützung verteilter Datenbanken

Die meisten verteilten NewSQL-Datenbanken unterstützen gespeicherte Prozeduren immer noch nicht. Die Ausnahme ist OceanBase, das in Version 2.2 Unterstützung für gespeicherte Oracle-Prozeduren hinzugefügt hat. Ich denke, das liegt an der allgemeinen Kompatibilität mit den Oracle-Richtlinien. Die offizielle Aussage von OceanBase macht jedoch deutlich, dass die Funktion der gespeicherten Prozedur derzeit nicht den Produktionsanforderungen entspricht.

Die Kompatibilität mit Legacy-Systemen ist heute möglicherweise die größte Bedeutung gespeicherter Prozeduren. Für Systeme, die von MySQL auf verteilte Datenbanken migrieren, ist dieser Reiz möglicherweise nicht so groß, da diese Systeme nicht so sehr auf gespeicherte Prozeduren angewiesen sind. Da MySQL in einer späteren Version nur gespeicherte Prozeduren bereitstellt und die Funktionen nicht so leistungsstark sind wie Oracle, ist die Benutzerabhängigkeit viel geringer. Gespeicherte Prozeduren werden von NewSQL nicht umfassend unterstützt, was aber auch auf architektonische Schwierigkeiten zurückzuführen ist.

Sehen Sie, was die Branche versucht.

Google veröffentlichte 2018 ein neues F1-Papier „ F1 Query: Declarative Querying at Scale “ zu VLDB . Es wird vorgeschlagen, benutzerdefinierte Funktionen, nämlich gespeicherte Prozeduren, über einen unabhängigen UDF-Server zu unterstützen. Da F1 in dieser Architektur völlig unabhängig von der Datenspeicherung ist, wird der UDF-Server auf natürliche Weise extrahiert. Den im Papier bereitgestellten Testdaten nach zu urteilen, behält dieses Design eine hohe Leistung bei, aber ich denke, dass dies viel mit den leistungsstarken Netzwerkfunktionen von Google zu tun hat. Es ist schwer zu sagen, ob es unter normalen Unternehmensnetzwerkbedingungen angewendet werden kann.

Design des UDF-Servers

• UDF unterstützt die allgemeine Sprache und unterstützt neben SQL auch C++, Java, Go und andere Sprachimplementierungen. Auf diese Weise ist es nicht vom SQL-Dialekt der Datenbank abhängig und die Vielseitigkeit des logischen Ausdrucks ist besser.
• UDFs sind nicht an die Speicherschicht gekoppelt. Dies bedeutet, dass der Kontext offener sein kann.

Dies bedeutet, dass das Debuggen gespeicherter Prozeduren erheblich verbessert werden kann, wodurch eine Schnittstelle zum DevOps-System möglich wird.

Frühere VoltDB hat auch gespeicherte Prozeduren reformiert. VoltDB ist eine speicherbasierte verteilte Datenbank, die vom legendären Michael Stonebraker im Datenbankbereich entwickelt wurde. VoltDB verwendet gespeicherte Prozeduren als Hauptbetriebsmodus und unterstützt das Schreiben in der Java-Sprache. Entwickler können die vom System bereitgestellte übergeordnete Klasse (VoltProcedure) erben, um ihre eigenen gespeicherten Prozeduren zu entwickeln:

import org.voltdb.*;
public class LeastPopulated extends VoltProcedure {
    
    
  //待执行的SQL语句
  public final SQLStmt getLeast = new SQLStmt(
      " SELECT TOP 1 county, abbreviation, population "
    + " FROM people, states WHERE people.state_num=?" 
    + " AND people.state_num=states.state_num" 
    + " ORDER BY population ASC;" );
  
  //执行入口
  public VoltTable[] run(int state_num) 
      throws VoltAbortException {
    
    
         //赋输入参数
         voltQueueSQL( getLeast, state_num ); 
         //SQL执行函数
         return voltExecuteSQL();
      }
}

Definieren Sie zuerst SQL, wobei „state_num=?“ eine reservierte Parameterposition ist, und weisen Sie dann Parameter in der Eingabefunktion run() zu und führen Sie sie aus.

Das Designkonzept von VoltDB ist anders und legt großen Wert auf die Effizienz der CPU-Nutzung. Sie analysierten traditionelle Datenbanken und kamen zu dem Schluss, dass nur 12 % der CPU-Zeit gewöhnlicher Datenbanken für sinnvolle Datenoperationen verwendet werden, sodass sich viele ihrer Designs darauf konzentrieren, die CPU-Ressourcen voll auszunutzen.

Die gespeicherte Prozedur ist im Wesentlichen eine vordefinierte Transaktion und es gibt keinen manuellen Interaktionsprozess, wodurch CPU-Wartezeiten vermieden werden. Da der Inhalt der gespeicherten Prozedur vorhersehbar ist, können die Daten gleichzeitig so schnell wie möglich in den Speicher geladen werden, wodurch die durch Netzwerk- und Festplatten-E/A verursachte CPU-Wartezeit weiter reduziert wird.

Aufgrund der Verwendung von gespeicherten Prozeduren und Speicher erreicht VoltDB auch im Single-Thread-Modell eine gute Leistung. Umgekehrt vereinfacht der einzelne Thread selbst die Transaktionssteuerung, vermeidet den Overhead der herkömmlichen Sperrverwaltung und CPU-Wartezeit und verbessert die Leistung von VoltDB.

Im Vergleich zu anderen Datenbanken haben gespeicherte Prozeduren eine völlig andere Bedeutung als VoltDB.

6 Zusammenfassung

1. Die Portierung gespeicherter Prozeduren ist schlecht. Hängt stark von der Datenbankumgebung ab und die Datenbankumgebung folgt keinem einheitlichen Standard wie das Betriebssystem oder die virtuelle Maschine. Aus dem gleichen Grund ist auch das Debuggen gespeicherter Prozeduren sehr kompliziert, hat nicht mit dem Tempo der agilen Entwicklung Schritt gehalten und entspricht nicht den heutigen technischen Anforderungen. Genau aus diesen beiden technischen Gründen werden gespeicherte Prozeduren nicht oder weniger verwendet
2. Aus Sicht verteilter Datenbanken unterstützen die meisten NewSQLs noch keine gespeicherten Prozeduren. OceanBase unterstützt als einzige Ausnahme bereits gespeicherte Oracle-Prozeduren, hat aber noch nicht die Produktionsstufe erreicht.
3. In der Arbeit von F1 wurde die Idee eines unabhängigen UDF-Servers vorgeschlagen, bei dem es sich um ein Implementierungsschema für gespeicherte Prozeduren in einer verteilten Architektur handelt. Ob es jedoch für normale Unternehmensnetzwerkumgebungen geeignet ist, bleibt abzuwarten. Bei dieser Lösung ist die Implementierungssprache der gespeicherten Prozedur jedoch nicht auf den SQL-Dialekt beschränkt, sondern wird auf eine Vielzahl gängiger Sprachen erweitert, ist mit Standards kompatibel und weist eine bessere Offenheit auf. Dies eröffnet die Möglichkeit der Integration der Stored-Procedure-Technologie in DevOps.
4. Als verteilte In-Memory-Datenbank verwendet VoltDB gespeicherte Prozeduren als Hauptmethode zur Definition von Operationen und unterstützt die Entwicklung der Java-Sprache. Man kann sogar sagen, dass die Grundlage von VoltDB die vordefinierte Transaktionsmethode gespeicherter Prozeduren ist. Gespeicherte Prozeduren, Speicher und Single-Thread interagieren miteinander, wodurch VoltDB eine hervorragende Leistung bietet.

Für jeden Programmierer muss es eine schwierige Entscheidung sein, eine Technologie aufzugeben, die er beherrscht und effizient umgesetzt hat. Aber heute sind für große Softwaresysteme die technischen Anforderungen weitaus wichtiger als eine bestimmte Technologie selbst. Technologien, die nicht mit dem gesamten Technologieökosystem kooperieren können, werden letztendlich nicht in der Lage sein, dem Schicksal der Marginalisierung zu entgehen. Bevor Sie eine neue Technologie erlernen, sei es eine verteilte Datenbank oder ein Microservice, empfehle ich Ihnen, darauf zu achten, ob sie sich an die umgebende Ökologie anpassen kann, denn die Technologie, die zum Trend passt, hat die Möglichkeit, besser zu werden, ist es aber auch Nische Die Technologie birgt eine größere Unsicherheit.

Referenz

• Bart Samwel: F1-Abfrage: Deklarative Abfrage im großen Maßstab

7 FAQ

Die Designidee von VoltDB ist etwas ganz Besonderes. Neben Single-Threading, großem Speicherbedarf und Speicherprozeduren zur Unterstützung der Java-Sprache ist auch das Design bei der Datenreplikation genial. Es handelt sich nicht um das Paxos-Protokoll von NewSQL noch die Master-Slave-Replikation von PGXC. Sie können sich vorstellen, wie es konzipiert ist? Es besteht eine bestimmte Beziehung zwischen dem Replikationsmechanismus und der gespeicherten Prozedur.

1. Geschäftscode und technischer Code sollten getrennt werden. Wir müssen sicherstellen, dass die Übersetzung von Geschäftslogik in Geschäftscode einfach und rein ist. Dadurch soll nicht nur die Kopplung an bestimmte Technologien in der Implementierungsphase reduziert werden, sondern auch die Testbarkeit des Geschäftscodes sowie die Einfachheit und Kohärenz des Geschäftscodes sichergestellt werden.
2. Die Eigenschaften bestimmter Technologien (z. B. gespeicherte Prozeduren) können häufig eine hervorragende Leistung erzielen. Dies erhöht aber auch die Komplexität der Implementierungsphase, und Komplexität bedeutet eine schwierige Wartung, was Kosten und Risiko bedeutet. Während der Verhaltenswert der Software realisiert wird, wird die Qualität der Architektur beeinträchtigt. Daher ist es in Szenarien mit strengen Leistungsanforderungen verständlich, einige Funktionen bestimmter Technologien zu verwenden, wir müssen jedoch wachsam bleiben und erkennen, dass dies ein zweischneidiges Schwert ist. Handeln Sie nicht leichtsinnig auf der Grundlage Ihrer eigenen „profunden Fähigkeiten“.
3. Ich habe die C/S-Ära noch nicht erlebt. Aus den einschlägigen Büchern zum datenmodellgesteuerten Design können wir jedoch ersehen, dass die gespeicherte Prozedur zu Beginn so beliebt war. Aber jetzt, wo eine Reihe von Methoden wie gespeicherte Prozeduren der Vergangenheit angehören, beginnt das datenmodellgesteuerte Design sehr „anämisch“ zu werden. Im Wesentlichen bleiben nur noch das Entity-Relationship-Modell und die Datenelemente übrig, was eine schwache Informationsübertragungskapazität darstellt und nicht mehr geeignet ist, den Entwurf komplexer Unternehmenssoftware voranzutreiben.
4. Stellen Sie Ihre eigene Implementierung des Datenmodelltreibers für die Kommunikation bereit: https://github.com/Jxin-Cai/mdd/tree/master/data-model/mini-faas

Die Shard-Replikation von VoltDB ähnelt dem Nameserver von RocketMq. Durch die parallele Ausführung von Vorgängen an allen Replikaten wird die Komplexität der Konsensfindung zwischen Replikaten vermieden.

OceanBase hat keine andere Wahl, als die gespeicherten Prozeduren von Oracle zu unterstützen, da es bestimmt, ob es in das traditionelle Kundenlager von Oracle „eindringen“ kann – große Unternehmen und den rein kommerziellen Finanzsektor. Die ERP-Produkte von Oracle verwenden eine große Anzahl gespeicherter Prozeduren, um Geschäftslogik zu implementieren. Der Quellcode der komplexesten Geschäftslogik wird Dutzende von Seiten ausgedruckt. Ich glaube, dass die Tools von OceanBase eine so komplizierte gespeicherte Prozedur nicht perfekt verarbeiten können (in OB verpflanzt). Aber zum Bieten und dergleichen. Wenn Sie viele Funktionen von Oracle nicht unterstützen, haben Sie überhaupt keine Möglichkeit zur Teilnahme.

VoltDB verwendet den K-Sicherheitsmechanismus, um das Problem der Datenreplikation zu lösen. Tatsächlich handelt es sich um einen N+1-Kopiermechanismus. Wenn VoltDB Daten schreibt, führt es die Anweisung in jeder Kopie aus, um sicherzustellen, dass die Daten korrekt sind in jedes Exemplar eingefügt. . Alle N+1 Kopien können gleichzeitig Zugriff gewähren, und gleichzeitig dürfen bis zu N Kopien verloren gehen (Partitionsfehler). Wenn N+1 Kopien nicht verfügbar sind, stoppt VoltDB den Dienst zur Reparatur.

„Alibaba Java Development Manual“ verbietet die Verwendung gespeicherter Prozeduren, die schwer zu debuggen und zu erweitern sind und keine Portabilität aufweisen. „Es steht im Verdacht, irreführend zu sein. Die gespeicherte Prozedur hier zielt auf MySQL ab und ist wirklich schwer zu debuggen und schwer zu replizieren. In Produkten der gleichen Zeit wurden gespeicherte Prozeduren in PL/SQL von Oracle und T-SQL des SQL-Servers geschrieben.“ sind immer noch sehr vorteilhaft. Sowohl DB2 als auch Oracle unterstützen PL/SQL, wobei PL/SQL portierbar ist und diese gespeicherte Prozedur im SQL-Standard aufgerufen wird (SQL/PSM (SQL/Persistent Stored Modules) https://en.wikipedia. org/wiki/SQL/PSM).

Dieser Vorschlag im Ali-Entwicklungshandbuch bezieht sich nicht speziell auf MySQL. Er kann im MySQL-Kapitel enthalten sein, da MySQL in Ali weit verbreitet ist und eine repräsentative Datenbank darstellt. Könnte es sein, dass sie gespeicherte MySQL-Prozeduren deaktivieren, während sie insgeheim gerne gespeicherte Oracle-Prozeduren verwenden? Scheint unwahrscheinlich.

Während der Entwicklung von SQL-Standards und der Entwicklung von Oracle stellt die Unterstützung gespeicherter Prozeduren auch einen Entwicklungsprozess dar. Die Leistung und Entwicklungseffizienz gespeicherter Prozeduren ist immer noch recht hoch. Im Zeitalter von Big Data spricht man von der Trennung von Speicher, Speicher gehört zum Speicher und Berechnung gehört zur Berechnung. Basierend auf der Hardware- und Kostenbilanz wird die Rechenleistung durch horizontale Erweiterung erhöht und die Speicherprozessfunktion erhöht vorübergehend nicht entwickelt oder ist schwer zu entwickeln. Aber Apache Hive ist Die unterstützte gespeicherte Prozedur heißt hpsql.

Darüber hinaus stellt der SQL-Standard nur eine Referenz für alle Datenbanken dar. Verschiedene Datenbanken haben unterschiedliche Längen bei Datentypen, globalen Variablen, Funktionen und sogar Namen gespeicherter Prozeduren. Keine Datenbank ist identisch, es sei denn, sie wird speziell angepasst. Aus diesem Grund wird gesagt, dass die Systemwechseldatenbank eine große Sache ist.

Typische Vertreter verteilter Datenbanken sind TiDB und CockroachDB. Sie unterscheiden sich etwas in der Syntaxkompatibilität und der Unterstützung für gespeicherte Prozeduren. Unterstützt CockroachDB gespeicherte Prozeduren in der pg-Syntax (pg ähnelt PL/SQL)?

Nachdem sie diese Unterschiede verstanden haben, haben einige Schüler möglicherweise immer noch das Gefühl, dass dies kein Problem darstellt und so einfach ist. Ob es schwierig oder einfach ist, ist für den Einzelnen eine sehr subjektive Beurteilung. Entscheidend ist, ob Ihr Team diese Technologie langfristig und kostengünstig nutzen kann.

Da alle gespeicherten Prozeduren JAVA unterstützen, sollte die Datenreplikation von TCC lernen können, das direkt in der Codeschicht implementiert ist, was der „Serviceschicht“ entspricht. Darüber hinaus basiert es auf Speicher und den Kosten für Wiederholungsversuche ist niedrig. Schreiben Sie Code direkt in den Knoten. Verstanden?

Sie basieren alle auf Speicher, sollten aber im Gegensatz zu Redis keine so hohe Leistung erfordern und den Thread-Pool direkt verwenden, um gleichzeitig Daten auf die Datenknoten zu schreiben.

Gespeicherte Prozeduren sind ein unersetzliches Produkt der Ära der eigenständigen Datenbanken. Als ich Programmierer war, waren gespeicherte Prozeduren das beste Werkzeug, um die Trennung von Front-End- und Back-End-Codes zu lösen. Ein Vorgang zur Stapelüberprüfung von 100.000 Bestellungen kann durch Aufrufen der gespeicherten Prozedur in wenigen Minuten abgeschlossen werden, und der Front-End-VB-Code wird ausgeführt, und das Ergebnis kann eine Stunde lang nicht abgerufen werden?

Ja, gespeicherte Prozeduren sind definitiv ein leistungsstarkes Werkzeug für datenintensives Computing.

Die materialisierte Sichtweise von Clickhouse ist tatsächlich ein Auslöser. Aus welchem ​​Blickwinkel sollte sie analysiert werden?

Aus mechanischer Sicht kann die materialisierte Ansicht (MaterializedView) in ClickHouse tatsächlich als Auslöser angesehen werden.

1. Funktionswinkel

Die Funktion der materialisierten Ansicht besteht darin, eine Basistabelle vorab zu berechnen und die Ergebnisse der SELECT-Abfrage in Echtzeit zu verwalten, was funktional der Erstellung einer zwischengespeicherten Ansicht entspricht, die in Echtzeit aktualisiert wird. Dies ähnelt der Art und Weise, wie Trigger automatisch voreingestellte Aktionen ausführen können, wenn sich Daten ändern.

2. Perspektive des Implementierungsmechanismus

ClickHouse erstellt über die Engine eine materialisierte Ansicht. Wenn sich Daten in der zugrunde liegenden Tabelle ändern, wird automatisch die Aktualisierung der materialisierten Ansicht ausgelöst. Dabei wird der Auslösemechanismus der Engine genutzt, um materialisierte Ansichten in Echtzeit zu erzielen.

3. Verwenden Sie den Szenenwinkel

Materialisierte Ansichten können in Datenanalysen, Dashboards und anderen Szenarien verwendet werden, die einen schnellen Zugriff auf aggregierte Ergebnisse erfordern und wiederholte Abfragen ersetzen, was der Verwendung von Triggern ähnelt.

4. Leistungsperspektive

Materialisierte Ansichten verbessern die Leseleistung durch Caching, erhöhen jedoch die Schreiblast. Sie müssen das Verhältnis von Lesen und Schreiben abwägen, um zu entscheiden, ob Sie es verwenden möchten. Dies spiegelt auch die Leistungskompromisseigenschaften von Triggern wider.

5. Grenzwinkel

Für materialisierte Ansichten gelten verschiedene Einschränkungen für Abfragen, und diese Einschränkungen sind auch Faktoren, die Trigger normalerweise berücksichtigen müssen.

Zusammenfassend lässt sich sagen, dass die materialisierte Ansicht von ClickHouse aus mehreren Perspektiven tatsächlich als besonderer Auslöser angesehen werden kann, der für das Verständnis und die Verwendung materialisierter Ansichten hilfreich ist. Dies gab mir einen neuen Blickwinkel für die Analyse verschiedener Automatisierungsmechanismen in der Datenbank.