Problème théorique de grand volume, impossible d'utiliser la collection pour trier .NET

Question

Excusez le titre de ce post, mais je ne peux pas vraiment penser à un titre plus créatif.

J'appelle un service Web de tiers où les auteurs commandent les résultats des transactions les plus récents. Le nombre total de transactions est supérieur à 100 000. Pour rendre les choses plus intéressantes, le service Web envoie des objets complexes représentant chaque transaction, donc si je demande 100 000 à la fois, un délai d'attente se produira. Les appels vers ce service Web doivent donc être groupés pour ne renvoyer que 1000 enregistrements à la fois. Cela signifie 100 appels individuels à ce service Web. Jusqu'à présent, tout est bon, sauf que les transactions doivent être traitées du plus ancien au plus récent, j'ai donc besoin d'un endroit pour contenir temporairement les identifiants de ces transactions, de sorte que plus tard, je puisse rappeler les ID dans le bon ordre (du plus ancien au plus récent) après les avoir triés.

Ce qui me manque dans cette solution est un SGBDR, je songe à utiliser un fichier texte pour stocker les valeurs.

Excuse la longue intro, si vous êtes encore éveillé ici sont les considérations:

(1)

1. Si je stocke seulement les valeurs dans un fichier texte, je vais finir avec plus de 100 000 lignes dans le fichier texte dans le mauvais ordre, ce qui signifie que je dois mettre en place un moyen de lire le fichier de bas en haut
2. Je ne suis pas sûr, mais il pourrait y avoir ajouter au début d'un fichier texte existant sans aucun des pénalités de performance, de cette façon une fois le fichier créé, je pourrais utiliser .net intégré pour lire le fichier de haut en bas.
3. Je pourrais raccorder un pilote odbc de texte et peut-être utiliser un ordre SQL par clause, mais je n'ai jamais fait cela auparavant, et je ne veux pas ajouter d'autres étapes de déploiement à mon application.
4. Peut-être que l'utilisation d'un fichier texte n'est pas le chemin à parcourir, peut-être qu'il existe une meilleure solution pour ce problème que je ne connais pas.

C'est une question d'architecture/logistique, toute aide serait appréciée, merci

Answer 1

Si vous utilisez un ordinateur de classe PC/Serveur standard, la mémoire permettant de stocker 100 000 ID et les horodatages associés n'est pas considérée comme volumineuse. Envisagez d'utiliser une liste triée en mémoire.

Si vous voulez vraiment écrire dans un fichier, vous pouvez utiliser File.ReadAllLines et parcourir le tableau de chaînes résultant vers l'arrière.

Answer 2

S'ils sont juste ID, vous avez certainement besoin d'utiliser un fichier en premier lieu? Supposons qu'il s'agisse d'ID de 32 octets ... 100 000 d'entre eux ne sont encore qu'à un peu plus de 3 Mo.? Es-tu vraiment poussé pour la mémoire?

Je voudrais vraiment essayer une solution en mémoire pour commencer - assurez-vous que tout ira bien dans le pire des cas imaginables (par exemple doubler le volume attendu), mais alors allez-y. La morale de base est de ne pas avoir trop peur des chiffres qui sonne gros: 100 000 articles peuvent être beaucoup en termes humains, mais à moins qu'il y ait beaucoup de données par article, ce sont des arachides pour un ordinateur moderne.

Answer 3

Vous pouvez essayer de stocker les informations dans une combinaison DataSet/DataTable et d'utiliser une DataView associée au DataSet pour modifier l'ordre de tri lorsque vous récupérez vos données. En fonction de la structure du fichier XML que vous récupérez du service Web, vous pourrez peut-être le lire directement dans le DataSet et le laisser l'analyser dans les DataTables pour vous (si cela fonctionne, j'irais pour cela pour le facteur de simplicité).

Cette méthode implique le moins de code, mais vous devez évaluer les performances du DataSet avec les 100 000 éléments qu'il contient.

Je vous suggère de stocker toute la transaction de cette façon (y compris l'ID), vous aurez alors toutes les données à traiter et vous pourrez la parcourir dans l'ordre que vous aurez spécifié. J'ai l'impression que vous étiez à l'origine pour simplement stocker les ID, les trier - puis re-interroger le service Web pour chaque ID dans votre ordre trié, mais cela signifierait frapper le service deux fois pour les mêmes données. Je l'éviterais si possible.