💻 computer science

Query Cost Model Calibration in Confidential Virtual Machines

Diese Arbeit befasst sich mit der Leistungsdegradation analytischer Abfragen in Confidential Virtual Machines, indem sie eine Hardware-Software-Diskrepanz in Abfrageoptimierern identifiziert und eine leichtgewichtige, CVM-bewusste Kostenkalibrierung vorschlägt, die die Leistungslücke zu nicht verschlüsselten Umgebungen signifikant verringert und bis zu 48 % der verlorenen Leistung wiederherstellt.

Ursprüngliche Autoren: Qihan Zhang, Mengyuan Li, Ibrahim Sabek

Veröffentlicht 2026-06-26

📖 4 Min. Lesezeit☕ Kaffeepausen-Lektüre

CC BY 4.0

Ursprüngliche Autoren: Qihan Zhang, Mengyuan Li, Ibrahim Sabek

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich vor, Sie besitzen einen sehr sicheren, hochtechnologischen Tresor (eine Confidential Virtual Machine, oder CVM), in dem Sie Ihre sensibelsten Daten aufbewahren. Dieser Tresor ist so konzipiert, dass selbst der Gebäudemanager (der Cloud-Anbieter) nicht hineinspähen kann. Es gibt jedoch einen Haken: Dinge in diesen Tresor hinein- und herauszubekommen, ist langsamer und komplizierter, als sie aus einem normalen, unverschlossenen Raum (einer Standard-KVM) zu bewegen.

Das Problem ist nicht nur, dass der Tresor langsam ist; das Problem ist, dass der Manager (der Query Optimizer der Datenbank) dies nicht weiß.

Das Problem: Eine Karte für das falsche Gelände

Stellen Sie sich den Datenbank-Manager wie ein GPS-Navigationssystem vor.

Die alte Karte (KVM): Seit Jahren nutzt das GPS eine Karte, die für offene Autobahnen entworfen wurde. Es geht davon aus, dass das Fahren eines Autos (das Bewegen von Daten) schnell ist und das Überprüfen Ihres Standorts (Speicherzugriff) augenblicklich geschieht.
Das neue Gelände (CVM): Jetzt fährt das Auto durch ein bergiges, verschlüsseltes Tunnelsystem. Jedes Mal, wenn es abbiegt, muss es einen speziellen Ausweis vorzeigen (RMP-Check), und jedes Mal, wenn es Fracht bewegt, muss es diese auspacken, durch eine Sicherheits-Schleuse transportieren und wieder neu verpacken (Datentransport/Bounce-Buffer).

Da das GPS immer noch die „offene Autobahn“-Karte verwendet, schlägt es weiterhin die am schnellsten aussehenden Routen vor. Aber im Bergentunnel sind diese „schnellen“ Routen in Wirklichkeit die langsamsten, weil sie viele Ausweisprüfungen oder zu viel Handhabung der Fracht erfordern. Die Datenbank wählt am Ende den falschen Plan, was das gesamte System träge macht.

Die Lösung: Das GPS neu kalibrieren

Die Autoren dieser Arbeit haben nicht versucht, den Bergentunnel neu zu bauen oder ein schnelleres Auto zu erfinden. Stattdessen haben sie das GPS neu kalibriert.

Sie entwickelten ein neues, leichtgewichtiges „Kostenmodell“, das dem Datenbank-Manager sagt: „Hey, in diesem sicheren Tresor ist es teuer, große Mengen an Daten auf einmal zu bewegen, und das wahllose Herumspringen (wie das Suchen nach bestimmten Elementen in einer Liste) ist sogar noch teurer, weil es viele Ausweisprüfungen erfordert.“

Sie fügten dem Manager zwei einfache „Strafen“ (Penalties) in seine Berechnungen ein:

Die „Kisten-Bewegungs“-Strafe: Wenn ein Plan erfordert, einen riesigen Stapel an Daten zu bewegen (wie bei einem Hash Join), weiß der Manager nun, dass dies zusätzliche „Schleusen“-Schritte auslösen wird, und fügt einen Zeitaufwand für diesen Plan hinzu.
Die „Ausweis-Check“-Strafe: Wenn ein Plan erfordert, wahllos nach Daten zu suchen (wie bei einem Index Scan oder einem Nested Loop), weiß der Manager, dass dies viele „Ausweis“-Prüfungen (RMP-Checks) auslösen wird, und fügt einen Zeitaufwand für diesen Plan hinzu.

Die Ergebnisse: Die echte schnelle Spur finden

Durch die Aktualisierung des GPS mit diesen neuen Regeln begann der Datenbank-Manager, andere Routen zu wählen. Anstatt die „schnelle Autobahn“-Route zu wählen, die sich im Tunnel als Stau entpuppte, wählte er etwas längere Routen, die im sicheren Umfeld jedoch tatsächlich reibungsloser verliefen.

Was ist passiert?

Schnellere Abfragen: In ihren Tests machte diese einfache Anpassung die Abfragen in dem sicheren Tresor um bis zu 48 % schneller.
Den unverschlossenen Raum schlagen: In einigen Fällen war der optimierte sichere Tresor tatsächlich schneller als der standardmäßige, unverschlossene Raum! Das klingt kontraintuitiv, passierte aber, weil der Standardraum einen „schlechten Plan“ (basierend auf der alten Karte) verwendete, während der sichere Tresor einen „smarten Plan“ (basierend auf der neuen, genauen Karte) verwendete.

Zusammenfassend

Die Arbeit zeigt, dass man keine sicheren Computersysteme komplett neu entwerfen muss, um sie schnell zu machen. Man muss lediglich dem Entscheidungsträger der Datenbank (dem Optimizer) beibringen, dass sich die Verkehrsregeln geändert haben. Indem man ihm ein paar einfache, realistische „Kosten“ für das Bewegen von Daten und das Überprüfen von Ausweisen in einer sicheren Umgebung gibt, findet das System automatisch bessere Arbeitsweisen, wodurch die Leistungsdifferenz zwischen sicherer und Standard-Computing geschlossen wird.

Technisches Resümee: Kalibrierung von Abfragekostenmodellen in vertraulichen virtuellen Maschinen

Problemstellung

Die Einführung von Confidential Computing, insbesondere von Confidential Virtual Machines (CVMs) wie AMD SEV-SNP, bietet einen praktischen Weg zur Ausführung herkömmlicher Datenbankmanagementsysteme (DBMS) ohne Quellcode-Modifikationen, während gleichzeitig die Daten während der Verarbeitung geschützt werden. Dennoch leiden analytische Abfragen in CVMs unter erheblichen Performance-Overheads im Vergleich zu konventionellen, unverschlüsselten virtuellen Maschinen (KVMs).

Bisherige Forschung konzentrierte sich weitgehend auf das Benchmarking dieser Verlangsamungen statt auf deren Optimierung. Dieses Paper identifiziert die Ursache als einen Hardware–Software-Mismatch: Traditionelle Abfrageoptimierer verlassen sich auf Kostenmodelle, die für KVMs kalibriert wurden, welche in CVM-Umgebungen jedoch nicht mehr gelten. Infolgedessen bewerten Optimierer Ausführungspläne falsch und wählen Strategien, die in KVMs effizient, in CVMs jedoch suboptimal sind.

Die Autoren führen diesen Mismatch auf zwei spezifische architektonische Eigenschaften von SEV-SNP zurück:

Datentransfer-Overhead (Data Movement Overhead): In CVMs beinhalten Datentransfers zwischen Speicher und RAM Verschlüsselungsprozesse und „Bounce-Buffer“-Kopieroperationen (Staging von Daten in gemeinsam genutztem Speicher). Dieser Overhead ist nicht uniform; unterschiedliche Abfragepläne (z. B. Hash Join vs. Nested Loop) induzieren unterschiedliche Muster des Datentransfers, was zu variablen Strafen führt.
RMP-bezogener Translations-Overhead: SEV-SNP nutzt eine Reverse Map Table (RMP), um die Seiteneigentümerschaft und Berechtigungen während der Adressübersetzung zu validieren. Dies führt zu Latenzen in den Speicherzugriffspfaden, insbesondere bei Random-Access-Operationen wie Index-Scans und indexgetriebenen Nested-Loop-Joins. Experimentelle Belege zeigen, dass sich dies als signifikanter Anstieg der Zyklen pro Instruktion (Cycles Per Instruction, CPI) äußert, bedingt durch Translation und geschützte Speicherprüfungen, anstatt durch eine Erhöhung der Gesamtzahl der ausgeführten Instruktionen.

Methodik

Die Autoren schlagen eine leichtgewichtige, CVM-bewusste Kostenkalibrierung vor, die direkt in das Kostenmodell des Abfrageoptimierers integriert wird. Anstatt die Ausführungsengine neu zu entwerfen, passt dieser Ansatz die geschätzten Kosten der Operatoren an, um die wahren relativen Preise der Ausführungspfade in SEV-SNP widerzuspiegeln.

Kernmechanismus

Die Kalibrierung ergänzt Standard-Kostenformeln (die Kosten typischerweise in CPU, Speicher und I/O zerlegen) um zwei zusätzliche Overhead-Terme, die aus physischen Proxys abgeleitet werden, die dem Optimierer bereits zur Verfügung stehen:

Datentransfer-Kosten (datamovecost): Dieser Term bestraft Operatoren basierend auf ihrer Working-Set-Größe ($ws$) und einem Overflow-Faktor ( $x$ ). Der Overflow-Faktor wird berechnet, wenn das Working Set das effektive Cache-Budget überschreitet. Die Kosten werden als $ws \cdot \eta_{dm} \cdot \sigma(x)$ modelliert, wobei $\eta_{dm}$ ein kalibrierter Penalty ist und $\sigma(x)$ den Term aktiviert, sobald der aktive Footprint aus dem Cache auslagert, was verschlüsselten Speicherverkehr und Bounce-Buffer-Interaktionen auslöst.
RMP-Overhead-Kosten (rmptcost): Dieser Term bestraft Operatoren basierend auf der Seitenzugriffsintensität ( $a$ ) und Lokalität. Er wird als $a \cdot \eta_{rmp} \cdot (1 + \alpha_{rmp} \cdot \sigma(x))$ modelliert. Dies erfasst die erhöhte Latenz der Adressübersetzung und RMP-Validierung, was Random-Access-Operatoren (z. B. Index Scans, Probe-intensive Nested Loop Joins) überproportional betrifft.

Operatorenspezifische Kalibrierung

Die Autoren wenden diese Terme auf spezifische Operatoren in PostgreSQL an:

Scans (Sequential, Bitmap, Index): Sequential- und Bitmap-Scans werden primär für den Datentransfer berechnet, wenn das Working Set überläuft. Index-Scans werden sowohl für den Datentransfer als auch für den RMP-Overhead berechnet, da die Index-Traversierung Pointer-Chasing und nicht-sequenzielle Seitenzugriffe beinhaltet, die Translation-Checks auslösen.
Joins:
- Nested Loop: Wird mit Datentransfer und bedingtem RMP-Overhead berechnet, falls die innere Seite indexgesteuert ist.
- Hash Join: Das Kostenmodell berücksichtigt explizit die Größe der Hash-Tabelle relativ zum Last-Level-Cache (LLC). Wenn die Hash-Tabelle den LLC überschreitet, erleidet der Operator signifikante Datentransfer- und Translation-Kosten.
- Merge Join: Wird primär für den Datentransfer berechnet, mit bedingten RMP-Kosten, falls die Inputs mangelnde Lokalität aufweisen.
Materialize/Memoize: Werden basierend auf der Größe des gepufferten Zwischenzustands berechnet.

Die Parameter für diese Kostenterme werden unter Verwendung einer repräsentativen Teilmenge von Abfragen aus jedem Workload abgestimmt, mit dem Ziel einer robusten Kalibrierung über verschiedene Szenarien hinweg, ohne einen exzessiven Optimierungsaufwand zu betreiben.

Wichtigste Beiträge

Identifikation von Performance-Verzerrungen: Das Paper zeigt, dass RMP-Checks und Datentransfer-Overheads die primären Treiber der dem Optimierer gegenüberliegenden Performance-Verzerrungen in CVMs sind. Es liefert empirische Belege (via CPI-Inflation und Analyse der Bounce-Buffer-Aktivität), dass diese Overheads operatord Abhängig und pfadsensitiv sind.
CVM-kalibriertes Kostenmodell: Die Autoren schlagen eine praktische Erweiterung des Kostenmodells vor, die gezielte Strafen für RMP-sensitive Random-Access-Zugriffe und Datentransfers injiziert. Dies bewahrt die Architektur des Optimierers, macht aber die Entscheidungen über die Ausführungspläne treuer gegenüber der CVM-Realität.
Implementierung und Evaluierung: Die Kalibrierung wurde in PostgreSQL 16.9 implementiert. Die Evaluierung umfasst Standard-OLAP-Benchmarks (JOB, CEB, Stack und TPC-DS) auf AMD SEV-SNP-Hardware.

Ergebnisse

Die Evaluierung zeigt, dass die Kalibrierung die Performance-Lücke zwischen KVM und SEV-SNP signifikant verringert:

Zeitersparnis: Die Kalibrierung reduziert die Gesamtausführungszeit über die Workloads hinweg um 3,54 % bis 48,35 %.
- JOB: 6,90 % Verbesserung.
- CEB: 17,14 % Verbesserung.
- Stack: 48,35 % Verbesserung.
- TPC-DS: 3,54 % Verbesserung.
Cross-Environment Performance: Bei den CEB- und Stack-Workloads übertrifft die kalibrierte SEV-SNP-Ausführung die unkalibrierte KVM-Baseline, was darauf hindeutet, dass die Korrektur des Kostenmodells genügend Effizienz zurückgewinnen kann, um in spezifischen Szenarien die nicht-verschlüsselte Baseline zu übertreffen.
Abfrageabdeckung: Ein erheblicher Teil der Abfragen profitierte von der Kalibrierung (zwischen 38,8 % und 62,5 % über alle Workloads).
Latenzverteilung: Die Kalibrierung verschiebt die Abfrage-Latenzverteilung nach unten, reduziert die mediane Latenz und komprimiert die Streuung (Standardabweichung). Beispielsweise sank bei dem Stack-Workload die maximale Latenz von 50,80 s auf 13,84 s, und die Standardabweichung verringerte sich von 7,00 s auf 2,24 s.

Bedeutung und Behauptungen

Das Paper behauptet, dass die primäre Barriere für Hochleistung-Datenbank-Workloads in CVMs nicht nur der rohe Hardware-Overhead ist, sondern die Fehlausrichtung des Software-Kostenmodells. Durch die Rekalibrierung des Optimierers, um die spezifischen Kosten von Datentransfers und RMP-Checks zu verstehen, kann das System automatisch Ausführungspläne auswählen, die diese Strafen minimieren.

Die Autoren betonen, dass ihr Ansatz leichtgewichtig ist: Er führt kaum Overhead ein, da er lediglich die Logik der Kostenabschätzung des Optimierers modifiziert, ohne neue Mechanismen zur Laufzeit der Ausführung hinzuzufügen. Sie positionieren diese Arbeit als notwendigen Schritt über das reine Benchmarking hinaus, hin zur Optimierung durch Adressierung des „Hardware–Software-Mismatches“, der dazu führt, dass herkömmliche DBMS in vertraulichen Umgebungen unterperformen. Das Paper schließt damit, dass eine angemessene Kalibrierung des Kostenmodells ausreicht, um die Performance-Lücke zwischen KVMs und CVMs signifikant zu verringern, unabhängig von den spezifischen Workload-Charakteristika.