pingcap/tidb

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

Open

#14 392 ouverte le 8 janv. 2020

Voir sur GitHub
 (1 commentaire) (0 réactions) (0 assignés)Go (6 186 forks)batch import
epic/memory-managementhelp wantedsig/executiontype/enhancement

Métriques du dépôt

Stars
 (40 090 stars)
Métriques de merge PR
 (Merge moyen 14j 4h) (346 PRs mergées en 30 j)

Description

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:

Guide contributeur

Direction de recherche
Commencez par examiner l'implémentation existante du stockage externe pour l'exécuteur Sort (issue #12431, PRs #13718, #14279) pour comprendre l'approche. Ensuite, examinez la base de code pour les exécuteurs comme Index Merge Join, Hash Join et Hash Aggregation afin d'identifier les points chauds d'utilisation de la mémoire. Recherchez les interfaces de stockage dans le code source de TiDB et réfléchissez à la manière d'intégrer un stockage externe pour déverser les données sur disque lorsque les limites de mémoire sont dépassées. L'issue comprend plusieurs sous tâches avec des niveaux de difficulté ; concentrez vous sur un exécuteur avec le statut 'help wanted'.
Stack technique
go
Domaine
database
Type d'issue
Fonctionnalité
DifficultéDifficulté estimée pour un nouveau contributeur, de 1 pour un très petit changement à 5 pour un travail expert.
3
Temps estiméFourchette de temps approximative pour investiguer, implémenter, tester et préparer une pull request.
Plus d'une semaine
Statut d'activitéDisponibilité apparente de l'issue : fraîche, active, ancienne, bloquée ou en attente d'un mainteneur.
Active
ClartéClarté avec laquelle l'issue explique le changement attendu, les critères d'acceptation et la prochaine étape.
Claire
Prérequis
GoSQL
Accessibilité débutantScore de 1 à 100 estimant l'accessibilité de cette issue pour un premier contributeur.
30