Auswahl der richtigen DB-Instance-Klasse

Die richtige Instance-Klasse hängt davon ab, wie Ihre Fremdtabellenabfragen Arbeitsspeicher, Speicher und CPU nutzen. Einzelheiten zu jeder dieser Ressourcen finden Sie unterRessourcenmanagement.

• Speicher: Eine Fremdtabellenabfrage speichert ihre Arbeitsdaten (Sortierungen, Aggregationen und Hashtabellen für Verknüpfungen) im Speicher, begrenzt durch die aurora_analytics.query_mem Einstellung (query_memkurz). Der Standardwert von query_mem skaliert mit der Instanzgröße, sodass bei einer größeren Instanz jeder Abfrage automatisch mehr Speicher zur Verfügung steht. Wenn eine Abfrage den Wert überschreitetquery_mem, wird sie in den lokalen Speicher übertragen, der langsamer ist. Weitere Informationen finden Sie unter query_mem an Ihre Arbeitslast anpassen.

• Parallelität: Jede gleichzeitige Fremdtabellenabfrage weist bis zu einem Speicherplatz zuquery_mem, aber die tatsächliche Nutzung hängt von der Abfrage ab, und einfache Abfragen benötigen möglicherweise weit weniger Speicher. Wenn Sie die Größe auf Parallelität auslegen, sollten Sie den Spitzenspeicher einplanen, anstatt davon auszugehen, dass jede Abfrage den vollen Speicher nutzt. query_mem Weitere Informationen finden Sie unter Dimensionierung der Parallelität.

• Zwischenspeichern und Verschütten: Sowohl der Festplatten-Cache für Amazon S3 S3-Daten als auch die temporären Dateien, die nach Datenabfragen verschüttet werden, verwenden den lokalen Speicher der Instance. Lokales NVMe (verfügbar auf D-Instances wiedb.r8gd) ist für beide schneller als Amazon EBS. Wählen Sie daher eine Klasse mit lokalem NVMe-Speicher für Produktionsworkloads, die fremde Tabellen abfragen.

• Workload-Isolierung: Abfragen fremder Tabellen konkurrieren mit dem restlichen Traffic der Instance um CPU und Arbeitsspeicher. Führen Sie bei Workloads, die häufig Fremdtabellen abfragen, diese stattdessen auf einem speziellen Reader aus. Weitere Informationen finden Sie unter Verwendung einer dedizierten Reader-Instanz für Analysen.

Beginnen Sie mit einem Kurs, der zu Ihrer Arbeitslast passt, und passen Sie sich von dort aus anhand dieser Signale an.

• Steigend AuroraAnalyticsMemoryUsage bedeutet, dass der allgemeine Speicherdruck zunimmt. Skalieren Sie auf eine größere Instance-Klasse oder eine niedrigere, query_mem um Platz für Parallelität zu lassen.

• Zunehmend AuroraAnalyticsDiskSpillSize bedeutet, dass einzelne Abfragen die Anzahl der einzelnen Abfragen überschreiten query_mem und in den lokalen Speicher übergehen. Skalieren oder erhöhen Sie die Anzahl, query_mem um jeder Abfrage mehr Platz zu geben.

• Ein Rückgang AuroraAnalyticsCacheHitRatio bedeutet, dass mehr Ihrer Arbeitsdaten erneut aus Amazon S3 gelesen werden. Eine größere Instance-Klasse speichert mehr davon lokal im Cache.

• Ein hoher CPU-Wert beim Abfragen von Fremdtabellen bedeutet, dass Abfragen mehr vCPUs benötigen.

Um mehr gleichzeitige Abfragen zu verarbeiten, skalieren Sie, um mehr Speicherplatz zur Verfügung zu haben, oder fügen Sie ein Lesegerät hinzu, um die Last zu verteilen.

Informationen zu diesen Metriken und zu deren Überwachung finden Sie unter. Überwachung und Problembehebung

Wann sollten EBS-only Instances verwendet werden

Instances ohne lokalen NVMe-Speicher (wie db.r8g unddb.r8i) verwenden Amazon EBS für das Caching. Verwenden Sie sie für Folgendes.

• Workloads, bei denen es eher um Kosten als um Leistung geht.

• Leichte Abfragen oder Ad-hoc-Abfragen in Fremdtabellen.

• Entwicklungs- und Testumgebungen.