Présentation du problème

Lorsque l'on doit récupérer le contenu d'un fichier Parquet de grande taille, il est souvent nécessaire de paginer les résultats pour éviter les limites de taille des réponses API. La méthode la plus évidente consiste à utiliser les clauses LIMIT et OFFSET, mais cela peut s'avérer inefficace si le fichier contient un grand nombre de lignes.

Fonctionnement de file_row_number

DuckDB propose une option appelée file_row_number qui permet de récupérer le numéro de ligne physique de chaque ligne dans le fichier Parquet. Cela permet de filtrer les lignes en fonction d'une plage de numéros de ligne spécifique, plutôt que d'utiliser OFFSET.

SELECT id, k, name, category, value, payload, ts
   FROM read_parquet($path, file_row_number => true)
   WHERE file_row_number >= $lo AND file_row_number < $hi

Cette approche permet à DuckDB de sauter les lignes qui se trouvent avant la plage spécifiée, sans avoir à les décompresser.

Implications et limites

Il est important de noter que cette approche dépend du nombre de groupes de lignes dans le fichier Parquet. Si le fichier contient un seul groupe de lignes, cette méthode ne présente aucun avantage.

Il est également important de noter que la clause LIMIT/OFFSET ne garantit pas l'ordre des lignes, ce qui peut entraîner des problèmes si l'ordre d'insertion n'est pas préservé.

INSTALL crypto FROM community;
   LOAD crypto;
   SELECT crypto_hash_agg(
           'blake3',
           hash((id, k, name,…)

Il est recommandé d'utiliser la fonction crypto_hash_agg pour valider les résultats, plutôt que de simplement compter les lignes.

Conclusion

L'utilisation de file_row_number peut améliorer significativement les performances des requêtes sur les fichiers Parquet, en particulier lorsque les fichiers contiennent un grand nombre de lignes. Cependant, il est important de prendre en compte les limites et les implications de cette approche, notamment en ce qui concerne l'ordre des lignes et la validation des résultats.