pingcap/tidb

use external storage to reduce the memory space usage of some executors

Open

#14.392 geöffnet am 8. Jan. 2020

Auf GitHub ansehen
 (1 Kommentar) (0 Reaktionen) (0 zugewiesene Personen)Go (6.186 Forks)batch import
epic/memory-managementhelp wantedsig/executiontype/enhancement

Repository-Metriken

Stars
 (40.090 Stars)
PR-Merge-Metriken
 (Durchschn. Merge 14T 4h) (346 gemergte PRs in 30 T)

Beschreibung

Feature Request

Is your feature request related to a problem? Please describe:

As the title says.

Describe the feature you'd like:

issue difficulty assignee PRs
[ ] #TODO Use external storage for Index Merge Join hard help wanted N/A
[ ] #14675 implement grace hash join for Hash Join to avoid OOM of hash table hard help wanted N/A
[ ] #14413 Use external storage for Hash Aggregation hard help wanted N/A
[ ] #14395 Use external storage for Distinct hard help wanted N/A
[x] #12431 Use external storage for Sort medium @wshwsh12 #13718, #14279
[ ] #TODO Use external storage for Window Function medium help wanted N/A
[ ] #TODO Compare between row-based and vectorized external storage format for different executors hard help wanted N/A

Describe alternatives you've considered:

Teachability, Documentation, Adoption, Migration Strategy:

Contributor Guide

Research-Richtung
Beginnen Sie mit der Überprüfung der bestehenden externen Speicherimplementierung für den Sort Executor (Issue #12431, PRs #13718, #14279), um den Ansatz zu verstehen. Untersuchen Sie dann die Codebasis für Executoren wie Index Merge Join, Hash Join und Hash Aggregation, um Speichernutzungsschwerpunkte zu identifizieren. Suchen Sie nach Speicherschnittstellen im TiDB Quellcode und überlegen Sie, wie externer Speicher integriert werden kann, um Daten auf die Festplatte auszulagern, wenn Speichergrenzen überschritten werden. Das Issue enthält mehrere Unteraufgaben mit Schwierigkeitsbewertungen; konzentrieren Sie sich auf einen Executor mit dem Status 'help wanted'.
Tech Stack
go
Domain
database
Issue Type
Funktion
SchwierigkeitGeschätzte Implementierungsschwierigkeit für neue Contributors, von 1 für sehr kleine Änderungen bis 5 für Expertenarbeit.
3
Geschätzte ZeitEin grober Zeitrahmen, um zu recherchieren, zu implementieren, zu testen und einen Pull Request vorzubereiten.
Über 1 Woche
AktivitätsstatusWie verfügbar das Issue gerade wirkt: frisch, aktiv, stale, blockiert oder wartet auf Maintainer-Input.
Aktiv
KlarheitWie klar das Issue die erwartete Änderung, Akzeptanzkriterien und den nächsten Schritt erklärt.
Klar
Voraussetzungen
GoSQL
EinsteigerfreundlichkeitEin Score von 1 bis 100, der schätzt, wie zugänglich dieses Issue für First-Time Contributors ist.
30