Die Lastisolationsfunktion von Apache Doris basiert auf Workload Group｜Deep Dive

[Live-Übertragungsvorschau] Werden große Models Programmierer ersetzen? "

Autor: SelectDB- Technikteam

Heutzutage nimmt der Datenabfragebedarf von Unternehmen ständig zu. Wenn sie sich denselben Cluster teilen, müssen sie oft gleichzeitig mit Abfragen von mehreren Geschäftsbereichen oder mehreren Analyselasten konfrontiert werden. Unter begrenzten Ressourcenbedingungen führt die Bevorzugung von Ressourcen zwischen Abfrageaufgaben zu Leistungseinbußen und sogar zur Cluster-Instabilität. Daher liegt die Bedeutung des Lastmanagements auf der Hand.

Ausgehend von Geschäftsszenarien ergeben sich die Anforderungen an das Benutzerlastmanagement hauptsächlich aus folgenden Aspekten:

Wenn sich mehrere Geschäftsabteilungen oder Mandanten möglicherweise denselben Cluster teilen, ist es zur Vermeidung von Lastwechselwirkungen zwischen verschiedenen Mandanten erforderlich, die Unabhängigkeit der Ressourcennutzung und die Leistungsstabilität jedes Mandanten sicherzustellen.
Verschiedene Unternehmen haben unterschiedliche Anforderungen an die Reaktionsfähigkeit und Priorität von Abfrageaufgaben. Für wichtige Unternehmen oder Aufgaben mit hoher Priorität, wie z. B. Echtzeit-Datenanalyse, Online-Transaktionen usw., muss sichergestellt werden, dass diese Aufgaben über ausreichende Ressourcen verfügen mit Priorität ausgeführt werden, um Ressourcenkonkurrenz zu vermeiden. Haben Sie Auswirkungen auf die Abfrageleistung.
Benutzer kümmern sich nicht nur um die Ressourcenzuweisung und -verwaltung, sondern achten auch auf Kostenkontrolle und Ressourcennutzung. Die Lastmanagementlösung muss die Isolationsanforderungen erfüllen und gleichzeitig die Anforderungen des Benutzers nach niedrigen Nutzungskosten und hoher Ressourcenauslastung erfüllen.

In frühen Versionen führte Apache Doris eine Isolationslösung ein, die auf Ressourcen-Tags basiert, einschließlich der Aufteilung von Ressourcengruppen auf Knotenebene innerhalb des Clusters und Ressourcenlimits für einzelne Abfragen, wodurch eine physische Isolierung von Ressourcen zwischen verschiedenen Benutzern erreicht wird. Um Benutzern eine umfassendere Lastverwaltungslösung bereitzustellen, hat Apache Doris seit Version 2.0 eine auf Workload Group basierende Verwaltungslösung eingeführt, die die weiche Grenze der CPU-Ressourcen erkennt und Benutzern eine höhere Ressourcenauslastung bietet. Die neu veröffentlichte Version 2.1 basiert auf der vom Linux-Kernel bereitgestellten CGroup-Technologie, die weitere harte Beschränkungen für CPU-Ressourcen implementiert und Benutzern eine bessere Abfragestabilität bietet.

Physische Isolationslösung basierend auf Resource Tag

Es gibt zwei Arten von Knoten in Apache Doris: FE und BE. Der FE-Knoten ist für die Speicherung von Metadaten, die Clusterverwaltung, den Zugriff auf Benutzeranforderungen, die Analyse von Abfrageplänen usw. verantwortlich, während der BE-Knoten für die Datenspeicherung und -berechnung verantwortlich ist. Der Hauptressourcenverbrauch beim Abfrageausführungsprozess ist der BE-Knoten, daher ist die Lastisolationslösung von Apache Doris für den BE-Knoten konzipiert.

In der Ressourcen-Ressourcen-Isolationslösung können Sie Tags auf BE-Knoten im selben Cluster festlegen. BE-Knoten mit denselben Tags bilden eine Ressourcengruppe (Ressourcengruppe), und die Ressourcengruppe kann als Datenspeichereinheit betrachtet werden und Computer. Wenn Daten in die Datenbank eingegeben werden, werden Kopien der Daten entsprechend der Ressourcengruppenkonfiguration in verschiedene Ressourcengruppen geschrieben. Bei der Abfrage werden die Rechenressourcen der entsprechenden Ressourcengruppe entsprechend der Aufteilung der Ressourcengruppen für die Berechnung verwendet.

Referenzdokumentation: https://doris.apache.org/zh-CN/docs/2.0/admin-manual/resource-admin/multi-tenant

Nehmen wir als Beispiel ein allgemeines Lese-/Schreibanalyseszenario. Angenommen, es gibt 3 BEs im Cluster. Die spezifischen Verwendungsschritte sind wie folgt:

BE-Knotenbindungs-Ressourcen-Tag: Binden Sie zwei BEs an Tag Read, um die Leselast zu bedienen; binden Sie ein BE an Tag Write, um die Schreiblast zu bedienen. Lese-Workloads und Schreib-Workloads befinden sich auf unterschiedlichen Maschinen, um eine Lese- und Schreibisolation zu erreichen.
Datenkopien sind an das Ressourcen-Tag gebunden: Tabelle 1 hat drei Kopien, zwei Kopien sind an das Tag-Lesen gebunden und eine Kopie ist an das Tag-Schreiben gebunden. Die auf Replikat 3 geschriebenen Daten werden automatisch mit Replikat 1 und Replikat 2 synchronisiert. Der Synchronisierungsprozess beansprucht nicht zu viele Rechenressourcen von BE 1 und BE 2.
Die Arbeitslast ist an das Ressourcen-Tag gebunden: Wenn das von der Abfrage-SQL getragene Tag „Lesen“ ist, wird die Abfrage automatisch an die Maschine (BE 1, BE 2) mit dem Tag als „Lesen“ zur Ausführung weitergeleitet, wenn die Stream-Last importiert wird in die Last und das angegebene Tag ist Write , dann wird die Stream-Last an die Maschine weitergeleitet, deren Tag Write ist (BE 3). Bei diesem Prozess besteht zusätzlich zum Overhead, der bei der Replikatsynchronisierung entsteht, kein Wettbewerb mehr um Ressourcen zwischen Abfrage und Import.

Physische Isolationslösung basierend auf Resource Tag.png

Resource Tag kann auch mandantenfähige Funktionen implementieren. Beispielsweise gibt es zwei Benutzer, BenutzerA und BenutzerB, die unabhängige Mandanten erstellen möchten, um gegenseitige Beeinflussung zu vermeiden. Anschließend können Sie die Computer- und Speicherressourcen von BenutzerA an ein Tag namens BenutzerA und die Computer- und Speicherressourcen von BenutzerB an ein Tag namens BenutzerA binden . ist das Tag von BenutzerB, dann erreichen die beiden Benutzer eine Ressourcenisolation zwischen Mandanten auf der BE-Seite.

Physische Isolationslösung basierend auf Resource Tag-2.png

Der Kern von Resource Tag besteht darin, eine Ressourcenisolation durch Gruppieren von BE-Knoten zu erreichen. Die Vorteile dieser Lösung sind:

Gute Isolierung, mehrere Mandanten werden durch physische Maschinen isoliert und eine vollständige Isolierung von CPU, Speicher und E/A wird erreicht;
Fehlerisolierung: Wenn bei einem Mandanten ein Problem auftritt (z. B. ein Prozessabsturz), ist der andere Mandant überhaupt nicht betroffen;

Basierend auf dieser Technologie platzieren einige Benutzer unterschiedliche Ressourcengruppen in verschiedenen physischen Computerräumen, um einen Aktiv-Aktiv-Betrieb von zwei Computerräumen in derselben Stadt zu erreichen.

Es gibt aber auch gewisse Einschränkungen:

Wenn im Lese-Schreib-Isolationsszenario die Schreiblast stoppt, befindet sich die Maschine mit dem Tag Write im Ruhezustand, wodurch die Ressourcenauslastung des gesamten Clusters verringert wird, was offensichtlich nicht den Erwartungen des Benutzers an die vollständige Ressourcenauslastung entsprechen kann.
In einem Szenario mit mehreren Mietern wirken sich auch die Lasten mehrerer Geschäftsparteien innerhalb desselben Mieters gegenseitig aus. Selbst wenn eine Isolation durch die Konfiguration separater physischer Maschinen für jede Geschäftspartei erreicht werden kann, führt dies zu Problemen wie hohen Kosten und geringer Ressourcenauslastung.
Die Flexibilität ist schlecht. Die Anzahl der Mandanten ist tatsächlich an die Anzahl der Replikate gebunden. Wenn Sie 5 Mandanten einrichten möchten, benötigen Sie mindestens 5 Replikate, was in gewissem Maße zu einer Verschwendung von Speicherplatz führt.

Lastmanagementlösung basierend auf Workload Group

Um die oben genannten Probleme zu lösen, hat Apache Doris eine auf Workload Group basierende Verwaltungslösung auf den Markt gebracht, die einen detaillierteren Ressourcenisolationsmechanismus – prozessinterne Ressourcenisolation – unterstützt, was bedeutet, dass auch mehrere Abfrageräume in derselben BE eine erreichen können Durch die Isolierung wird eine Ressourcenkonkurrenz innerhalb des Prozesses effektiv vermieden und die Ressourcennutzung verbessert.

Workload Group verwaltet Arbeitslasten in Gruppen, um eine verfeinerte Verwaltung und Kontrolle von Speicher- und CPU-Ressourcen zu erreichen. Begrenzen Sie den Prozentsatz der CPU- und Speicherressourcen einer einzelnen Abfrage auf einem einzelnen BE-Knoten, indem Sie die vom Benutzer ausgeführte Abfrage der Arbeitslastgruppe zuordnen. Gleichzeitig können Sie Speicherressourcenlimits konfigurieren und aktivieren, wenn die Clusterressourcen knapp sind, werden Abfragen mit hoher Speichernutzung in der Gruppe automatisch beendet, um den Druck zu verringern. Wenn Ressourcen im Leerlauf sind, teilen sich mehrere Arbeitslastgruppen ungenutzte Ressourcen und durchbrechen automatisch Grenzwerte, um eine stabile Abfrageausführung sicherzustellen.

Die Grenzen der CPU-Ressourcen können in Soft-Limits und Hard-Limits unterteilt werden. CPU-Soft-Limits zeichnen sich durch eine höhere Ressourcenauslastung aus und ermöglichen eine flexible Zuweisung von Ressourcen, wenn Ressourcen inaktiv sind sich durch Lastwechsel nicht gegenseitig stören.

( Die beiden Isolationsmethoden CPU-Hardlimit und Softlimit können unterschiedlichen Nutzungsszenarien entsprechen, können jedoch nicht gleichzeitig angewendet werden. Benutzer können flexibel nach ihren eigenen Bedürfnissen wählen.)

Lastmanagementlösung basierend auf Workload Group.png

Die Hauptunterschiede zwischen Workload Group- und Resource Tag-Lösungen sind folgende:

Aus Sicht der Rechenressourcen unterteilt die Workload-Gruppe die CPU- und Speicherressourcen innerhalb des BE-Prozesses weiter. Mehrere Workload-Gruppen müssen um Ressourcen auf demselben BE konkurrieren. Ressourcen-Tags gruppieren BE-Knoten und die Lasten verschiedener Geschäftsparteien werden an BEs in verschiedenen Gruppen gesendet, um eine Ressourcenisolation zu erreichen. Es gibt keinen direkten Ressourcenwettbewerb zwischen Geschäftslasten in verschiedenen BE-Gruppen.
Aus Sicht der Speicherressourcen muss die Workload Group nicht auf Speicherressourcen achten, sondern konzentriert sich nur auf die Zuweisung von Rechenressourcen innerhalb eines einzelnen BE. Resource Tag erfordert das Gruppieren von Datenkopien, um sicherzustellen, dass geschäftsseitige Daten, die isoliert werden müssen, auf verschiedene BEs verteilt werden.

01 CPU-Softlimit

Die CPU-Priorität wird hauptsächlich cpu_sharedurch Parameter widergespiegelt, die mit dem Konzept der Gewichtung verglichen werden können. Im gleichen Zeitraum kann eine Gruppe mit einer höheren Gewichtung mehr CPU-Zeit erhalten.

Nehmen Sie als Beispiel Gruppe A und Gruppe B. Wenn Gruppe A cpu_shareals 1 und Gruppe B cpu_shareals 9 konfiguriert ist, wird ein Zeitraum von 10 Sekunden angegeben. Wenn beide Lasten gesättigt sind, kann Gruppe B mit einer höheren Gewichtung CPU-Zeit für 9 Sekunden (90 % aller Ressourcen) erhalten, und Gruppe A kann CPU-Zeit für 1 Sekunde (10 % aller Ressourcen) erhalten. Bei der tatsächlichen Nutzung laufen nicht alle Dienste unter Volllast. Wenn die Auslastung von Gruppe B gering oder gar nicht ist, kann Gruppe A die CPU-Zeit für 10 Sekunden monopolisieren. Diese Methode kann eine höhere Flexibilität bei der Ressourcenzuteilung bieten und dadurch die Gesamtauslastung der Cluster-CPU-Ressourcen verbessern.

CPU

02 CPU-Hard-Limit

Die Verwendung des CPU-Soft-Zeitlimits kann zu Schwankungen in der Abfrageleistung führen, wenn die Systemlast hoch ist oder die CPU-Ressourcen knapp sind. Um den hohen Anforderungen der Benutzer an eine stabile Abfrageleistung gerecht zu werden, hat Apache Doris in der neuesten Version 2.1 das CPU-Hardlimit der Workload Group implementiert – unabhängig davon, ob die Gesamt-CPU der aktuellen physischen Maschine im Leerlauf ist, beträgt die maximale CPU-Auslastung Die mit dem harten Grenzwert konfigurierte Gruppe kann den vorkonfigurierten Grenzwert nicht überschreiten.

Nehmen Sie Gruppe A und Gruppe B als Beispiel . Wenn Sie Gruppe A konfigurieren cpu_hard_limit=10%, ist Gruppe B. cpu_hard_limit=90%Wenn die CPU-Ressourcen beider Einzelmaschinen ihre Sättigung erreichen, beträgt die CPU-Auslastung von Gruppe A 10 % und die CPU-Auslastung von Gruppe B 90 %, was dem CPU-Softlimit entspricht. Wenn jedoch die Last von Gruppe B abnimmt oder keine Last vorhanden ist, ist die maximale CPU-Auslastung von Gruppe A immer noch streng auf 10 % begrenzt, selbst wenn Gruppe A die Abfragelast erhöht, und es können keine weiteren Ressourcen abgerufen werden. Obwohl dieser Ansatz die Flexibilität der Ressourcenzuweisung beeinträchtigt, gewährleistet er auch die Stabilität der Abfrageleistung.

harte Grenze

03 Einschränkungen der Speicherressourcen

Gebrauchsanweisung: Der BE-Knotenspeicher ist hauptsächlich in die folgenden Teile unterteilt:

Das Betriebssystem reserviert Speicher

Der Nicht-Abfrageteil des Speichers im BE-Prozess kann von der Workload Group vorerst nicht gezählt werden.

Der Speicher des Abfrageteils innerhalb des BE-Prozesses (einschließlich Importvorgängen) kann von der Workload Group gezählt und verwaltet werden.

Speicherressourcengrenzen werden hauptsächlich memory_limitdurch Parameter begrenzt (Festlegen des Prozentsatzes des BE-Speichers, der verwendet werden kann). Sie können nicht nur die vorkonfigurierte Speichernutzung festlegen, sondern auch die Priorität der Speicherrückgabe nach einer Überbelegung beeinflussen.

Im Ausgangszustand wird Ressourcengruppen mit hoher Priorität mehr Speicher zugewiesen, Ressourcengruppen mit niedriger Priorität wird weniger Speicher zugewiesen. Um die Speichernutzung zu verbessern, können Sie enable_memory_overcommitdas Speicher-Softlimit der Ressourcengruppe aktivieren. Wenn das System über freie Speicherressourcen verfügt, können diese über das Limit hinaus genutzt werden.

Um den stabilen Betrieb des Systems sicherzustellen, räumt das System bei unzureichenden Gesamtspeicherressourcen dem Abbrechen von Aufgaben, die viel Speicher belegen, Priorität ein, um überbelegte Speicherressourcen zurückzugewinnen. Während dieses Vorgangs versucht das System, die Speicherressourcen von Ressourcengruppen mit hoher Priorität zu reservieren, und der überschüssige Speicher von Ressourcengruppen mit niedriger Priorität wird schneller zurückgewonnen.

Grenzen der Speicherressourcen

04 Abfragewarteschlange

Wenn die Geschäftslast die Obergrenze des Systems überschreitet, wird die weitere Übermittlung neuer Abfragen nicht nur nicht effektiv ausgeführt, sondern wirkt sich auch auf laufende Abfragen aus. Um dieses Problem zu vermeiden, unterstützt Workload Group die Abfragewarteschlange. Wenn die Abfrage die voreingestellte maximale Parallelität erreicht, tritt der neue Übermittlungsplan in die Warteschlangenlogik ein. Wenn die Warteschlange voll ist oder die Wartezeit abgelaufen ist, wird die Abfrage abgelehnt, um das System bei hoher Auslastung zu entlasten.

Abfrage queue.png

Die Abfragewarteschlangenfunktion verfügt hauptsächlich über drei Attribute:

max_concurrency: Die maximale Anzahl von SQL-Anweisungen, die gleichzeitig in der aktuellen Gruppe ausgeführt werden dürfen. Wenn die maximale Anzahl überschritten wird, wird eine Warteschlangenlogik eingegeben.
max_queue_size: Die maximal zulässige Anzahl von Abfragen in der Warteschlange. Wenn die Warteschlange voll ist, wird die Abfrage abgelehnt und die Ausführung schlägt fehl.
queue_timeout: Das Zeitlimit für die Warteschlange in der Warteschlange, wenn eine Zeitüberschreitung auftritt, schlägt die Einheit direkt fehl.

Referenzdokumentation: https://doris.apache.org/zh-CN/docs/admin-manual/workload-group

Nutzungstest der Arbeitslastgruppe

Als nächstes führen wir detaillierte Tests zum CPU-Soft-Limit und zum Hard-Limit der Workload-Gruppe durch, um den Benutzern den Lastmanagement-Effekt und die Leistung dieser beiden Limits unter denselben Hardwarebedingungen klar zu demonstrieren.

Testumgebung: Einzelne physische Maschine mit 16 Kernen und 64 GB Speicher
Bereitstellungsmethode: 1 FE, 1 BE
Testdatensatz: Clickbench, TPCH
Spannungsmesstool: JMeter

01 CPU-Soft-Limit-Test

Starten Sie zwei Clients (1, 2), um die Auswirkung des CPU-Softlimits auf die Lastverwaltung zu testen, ohne bzw. ohne Verwendung des CPU-Softlimits. Es ist zu beachten, dass bei diesem Test der Seiten-Cache die Testergebnisse beeinflusst und der Seiten-Cache deaktiviert werden muss, um die idealen Testergebnisse zu erzielen.

Durch den Vergleich und die Analyse der Client-Durchsatzdaten in den beiden Tests können wir folgende Schlussfolgerungen ziehen:

Ohne Workload Group beträgt das Durchsatzverhältnis der beiden Clients 1:1, was bedeutet, dass sie zur gleichen Laufzeit die gleichen CPU-Ressourcen erhalten.
Nach Verwendung der Arbeitslastgruppe undcpu_share deren Einstellung auf 2048 bzw. 1024 zeigen die Ergebnisse, dass das Durchsatzverhältnis 2:1 beträgt. Dies zeigt, dass Client 1 mit größeren Parametern in der gleichen Laufzeit cpu_shareeinen höheren Anteil an CPU-Ressourcen erhält .

02 CPU-Hard-Limit-Test

Wie aus der obigen Einführung hervorgeht, kann die harte CPU-Begrenzung eine gute Isolation bei hoher Auslastung gewährleisten. Daher verwenden wir eine feste Grenze, um die CPU-Auslastung auf 50 % zu begrenzen ( cpu_hard_limit=50%), und verwenden denselben Client, um den q23-Abfragetest auszuführen, wenn die Anzahl der Parallelitäten 1, 2 und 4 beträgt (wodurch bei jedem Test unterschiedliche Lasten simuliert werden). für 5 Minuten. .

CPU-Hardlimit test.jpeg

Aus den obigen Testergebnissen können wir ersehen, dass die CPU-Auslastung mit zunehmender Anzahl gleichzeitiger Abfragen immer stabil bei etwa 800 % liegt (auf einem 16-Kern-Computer bedeutet 800 %, dass 8 Kerne verwendet werden, und die tatsächliche CPU-Auslastung beträgt 50). % ). Da die CPU-Ressourcen stark begrenzt sind, wird erwartet, dass die tp99-Latenz mit zunehmender Parallelität zunimmt.

03 Simulieren Sie Tests der Produktionsumgebung

In tatsächlichen Produktionsumgebungen legen Benutzer häufig mehr Wert auf die Leistung der Abfragelatenz als auf den reinen Durchsatz. Um den tatsächlichen Anwendungsszenarien näher zu kommen und die Leistung genau zu bewerten, haben wir eine Reihe von Abfrage-SQLs mit einer Latenz von etwa 1 Sekunde ausgewählt (einschließlich q15, q17, q23 von CKBench und q3, q7, q19 von TPCH), um einen SQL-Satz zu bilden. Diese Abfragen decken verschiedene Funktionen wie die Aggregation einzelner Tabellen und die Join-Berechnung ab. Die verwendete TPCH-Datensatzgröße beträgt 100 GB.

Wir haben zwei Testreihen entwickelt, um Szenarien ohne Workload-Gruppe bzw. mit Workload-Gruppe zu simulieren. Auf Client 1 und Client 2 wurden vier Tests durchgeführt, wobei der Schwerpunkt auf der Latenz von tp90 und tp99 lag.

Testen der Produktionsumgebung simulieren.png

Durch Beobachtung der Abfrageverzögerungen in den vier Tests in der obigen Tabelle können wir die folgenden Schlussfolgerungen ziehen:

Arbeitslastgruppe wird nicht verwendet (Tests 1 und 2) : Wenn die Parallelität von Client 2 von 1 auf 4 steigt, erhöhen sich die Abfrageverzögerungen von Client 1 und 2 erheblich. Beim Vergleich der Leistung von Client 1 haben sich die mittleren Antwortzeiten für tp90- und tp95-Anfragen um das Zwei- bis Dreifache erhöht.
Verwendung der Arbeitslastgruppe (Test 3, 4): In diesen beiden Tests wurden harte CPU-Grenzwerte angewendet: Client 1 cpu_hard_limit=90%und Client 2 festlegen cpu_hard_limit=90%. Aus den Testergebnissen ist ersichtlich, dass selbst wenn die Parallelität von Client 2 zunimmt, die Abfrageverzögerung von Client 1 nur geringfügig zunimmt, was deutlich besser ist als die Leistung in Test 2. Dieses Ergebnis zeigt voll und ganz die Wirksamkeit der Workload Group bei der Lastisolierung und Leistungsstabilitätsgarantie.

Abschluss

Derzeit wurden die Funktionen „Resource Tag“ und „Workload Group“ in den Produktionsdiensten mehrerer Community-Benutzer eingeführt und in großem Umfang überprüft. Sie werden für Benutzer mit Anforderungen an die Ressourcenisolierung empfohlen.

Unabhängig davon, ob es sich um ein Ressourcen-Tag oder eine Workload-Gruppe handelt, besteht das Ziel darin, die Unabhängigkeit von Ressourcenisolation und Ressourcennutzung auszugleichen . Ersteres verwendet eine gründlichere Isolationslösung, während letzteres eine Isolation erreicht und gleichzeitig die vollständige Nutzung der Ressourcen gewährleistet und die Systemstabilität weiter gewährleistet Szenarien mit hoher Arbeitslast durch Abfragewarteschlangen- und Aufgabenwarteschlangenmechanismen.

Bei der tatsächlichen Verwendung der Ressourcenisolation empfehlen wir, die beiden Lösungen zu kombinieren und entsprechend den Geschäftsszenarien anzuwenden:

Wenn derselbe Cluster von mehreren Systemen/geschäftsübergreifenden Abteilungen gemeinsam genutzt wird und Sie eine physische Isolierung von Ressourcen und Daten erreichen möchten, können Sie die Resource Tag-Lösung übernehmen;
Wenn Sie im selben Cluster mit mehreren Arten von Abfragelasten gleichzeitig konfrontiert sind, können Sie mithilfe der Arbeitslastgruppe unterschiedliche Lasten unterscheiden und sicherstellen, dass verschiedene Abfragelasten durch flexible Ressourcenzuweisung geeignete Ressourcen erhalten können.

Wir haben noch viele Pläne für spätere funktionale Verbesserungen:

Das aktuelle Speicherlimit wird verwendet, um Speicher durch Abfrage abbrechen freizugeben. In Zukunft kann die Platzierung des Operators die Stabilität großer Abfragen weiter verbessern und Fehler bei Abfrageaufgaben vermeiden, wenn die Ressourcen knapp sind.
Derzeit wird im Speichermodell des BE-Prozesses ein Teil des Nicht-Abfragespeichers nicht gezählt, was zu Unterschieden zwischen dem Speicher des BE-Prozesses und dem von der Arbeitslastgruppe verwendeten Speicher führen kann. Wir werden versuchen, dieses Problem zu lösen Problem in zukünftigen Versionen.
Die Abfragewarteschlangenfunktion unterstützt nur die Warteschlangenbildung basierend auf der maximalen Anzahl gleichzeitiger Abfragen. In Zukunft wird die maximale Anzahl gleichzeitiger Abfragen durch die Ressourcennutzung von BE begrenzt, wodurch ein automatischer Gegendruck auf den Client entsteht und die Verfügbarkeit von Doris verbessert wird wenn der Client weiterhin hohe Lasten sendet.
Die Ressourcen-Tag-Funktion dient der Aufteilung der BE-Maschinenressourcen und die Arbeitslastgruppe dient der Aufteilung der Ressourcen innerhalb eines einzelnen Maschinenprozesses. Beide Methoden zur Ressourcenaufteilung machen den Benutzern das Konzept der BE-Knoten zugänglich. Wenn Benutzer die Ressourcenverwaltungsfunktion nutzen, müssen sie im Wesentlichen nur auf die Menge der verfügbaren Ressourcen und die Priorität der Ressourcenzuweisung für ihre eigenen Arbeitslasten im gesamten Satz achten. In Zukunft werden neue Wege zur Aufteilung von Ressourcen erforscht, um das Verständnis der Benutzer und die Nutzungskosten zu senken.

Danksagungen

Die Workload Group-Funktion ist ein von der Open-Source-Community gemeinsam entwickeltes Projekt. Vielen Dank an die folgenden Studenten für ihre Beiträge: Luo Zenglin (luozenglin), Liu Lijia (liutang123), Zhao Liwei (levy5307).