-1
votes

Comment stocker un indice d'annexe pour de très gros fichiers (CSV)?

Je travaille avec de grands fichiers CSV (>> 10 ^ 6 lignes) et avez besoin d'un indice de ligne pour certaines opérations. Je dois faire des comparaisons entre deux versions des dossiers d'identification des suppressions, donc je pensais que ce serait plus facile d'inclure un indice de ligne. Je suppose que le nombre de lignes rendrait rapidement inefficace les entiers traditionnels. Je suis défavorable à l'idée d'avoir une colonne contenant des lons à 634567775577 en texte brut en tant qu'indice de ligne (suivi de la ligne de données réelle). Y a-t-il des suggestions de meilleure pratique pour ce scénario? Les fichiers résultants doivent rester en texte brut. Sérié / SQLite n'est donc pas une option.

Pour le moment, j'envisage un index basé sur les données de la rangée réelles (par exemple, concaincre les données de la ligne, convertir en base64 ou les goûts), mais cela serait plus raisonnable qu'un entier uni? Il ne devrait y avoir aucune ligne en double dans chaque fichier, alors je suppose que cela pourrait être un moyen.

Bravo, Sacha

PS: J'ai fortement modifié la question initiale de clarification


4 commentaires

C'est possible, mais il réinventer essentiellement la roue. Vous devez mettre un jeu de données cette taille dans une base de données appropriée - doublement, donc si vous avez besoin d'un accès aléatoire aux lignes.


"Le fichier résultant doit encore être lisible par l'homme" - une lecture humaine 1 ligne / s d'un fichier avec 10 ^ 6 rangées sera présumée pendant trois ans. C'est un moyen de dire que le fichier n'est pas lisible par la définition. Vous pouvez exporter les enregistrements pertinents qu'un HUMAM devrait examiner comme un CSV réduit plus tard.


Je peux voir que la discussion déviant de manière inattendue. J'aimerais clarifier: je n'ai pas l'air spécifiquement pour une solution Python, et je suis au courant des solutions de base de données «appropriées» qui gèrent des millions de rangées facilement. Cependant, je travaille sur un HPC et j'aurai besoin de fichiers de format texte clair. La balise Python était trompeuse, elle est là parce que les données brutes sont analysées par ligne de python. Ma motivation à poser la question était d'empêcher un index dans un fichier CSV (c'est ce que je voulais dire par l'homme-lisible) d'être super «large», par exemple: 1122448928304; 12; 23; 12,5 (format CSV). Désolé pour le malentendu!


OK - Alors, oui, Python est toujours une langue appropriée pour cela - mais je peux alors comprendre exactement quel est l'index dont vous avez besoin - juste un décalage d'octet pour le point de départ de chaque ligne?


3 Réponses :


0
votes

Vous pouvez utiliser des chiffres réguliers.

python n'a pas peur des grands nombres :) (Eh bien, à l'ordre de grandeur que vous avez décrit ...)

Ouvrez simplement une coque Python et tapez 10 ** 999 et voyez qu'il ne dépasse pas ou rien.


0 commentaires

0
votes

en Python, il n'y a pas de limite de bits réelle pour les entiers. Dans Python 2, il existe techniquement - un int est de 32 bits et un long est supérieur à 32 bits. Mais si vous déclarez simplement que vous déclarez que la coulée de type se produira implicitement. Python 3 a simplement un type, et il ne se soucie que d'espace mémoire. Donc, il n'y a pas de vraie raison pour laquelle vous ne pouvez pas utiliser un entier si vous voulez vraiment ajouter un index.


0 commentaires

0
votes

La bibliothèque intégrée Python contient SQLITE, une SMDM autonome et un fichier à un fichier - qui contrairement à la perception normale peut être assez performante. Si les enregistrements doivent être consultés par une seule application sans concurrence, il se compare à la SGBD spécialisé THTA nécessite un démon distinct.

Donc, essentiellement, vous pouvez jeter votre CSV dans une base de données SQLITE et créer les indices dont vous avez besoin - même sur les quatre colonnes si c'est le cas.

Voici un script de modèle que vous pourriez personnaliser pour créer un tel dB - Je suppose que les chiffres "1000" pour le nombre d'insérer un moment, mais cela pourrait Ne soyez pas optimal - essayez de modifier l'insertion est trop lent. xxx


2 commentaires

Merci, mais comme je l'ai commenté dans la section ci-dessus, ce n'est pas une solution applicable (probablement, je vais devoir voir à ce sujet). J'ai besoin de fichiers texte pure, car cette tâche n'est qu'une petite partie d'un flux de travail beaucoup plus grand dans lequel toutes les étapes nécessitent des fichiers texte simples. Mais acclamez-vous pour SQLite, c'est (généralement) génial!


Peut-être qu'il est temps de réviser les étapes. Un serveur DBMS approprié pourrait certainement alimenter les données aux consommateurs de manière plus pratique que GBSIZE TXT Files.