Je n'ai jamais essayé ceci - alors je ne sais pas si je rencontrais des problèmes de mémoire.
Mais un SQLDatreader peut-il lire un billion de dollars? C'est tout en continu? Je suis un peu vert à ce que le protocole SQL / TDS fait sous les couvertures.
3 Réponses :
Oui, cela va ranger ... mais je ne pense pas que vous devriez réellement essayer de le faire.
Si vous pouviez lire un million d'enregistrements par seconde (ce qui me semble peu probable), vous avez toujours besoin de 12 jours pour lire un billion de billions ... c'est beaucoup de travail à risquer de perdre à mi-chemin.
Maintenant, je me rends compte que vous ne vraiment veux-tu lire un billion de billions, mais que je veux dire que si vous pouvez séparer votre "gros montant" de travail en lots logiques de toute façon, c'est probablement une bonne idée.
Donc, ma question originale allait être quelle est la meilleure stratégie de combats pour Ado.net et SQL Server ... alors quelle est la meilleure façon de faire face à 1000 enregistrements à la fois. Dites que vous faites une activité de type MapReduce. Je me rends compte qu'il existe d'autres outils pour cela (ouvert et commercial), mais si la société que vous travaillez pour ne vous laissera pas les utiliser ... ils ne me font pas de bien. (Sauf pour essayer d'emprunter des idées de)
Bon point sur les 12 jours +1. Peut-être que j'ai choisi un nombre trop élevé.
Pour être honnête, la meilleure stratégie de lots dépendra de la nature exacte de la tâche. Pouvez-vous diviser de manière fiable en lots même si les requêtes sont exécutées à une date ultérieure? Pouvez-vous le diviser en lots à l'avance et donner des ordinateurs différents différents lots? Quelque chose d'autre est-il d'écrire dans ces données? Existe-t-il des index appropriés? Fondamentalement, il s'agit d'une affaire de travail de manière à scinder vos données sous une forme interrogée et efficace.
Donc, ces types de questions sont ce que je me battais avec. Les gens peuvent écrire aux données pendant que je suis au milieu du processus. Je n'ai pas de bonne stratégie "instantanée". C'est celui que j'essaie vraiment d'obtenir mon cerveau.
Au début, il peut s'agir d'un serveur (4 cœurs) travaillant sur les données. Peut-être deux ou trois serveurs d'ici la fin de l'année. Penser à utiliser certains F # dans ce projet. Semble bien adapté à cela.
Oui - cela pourrait prendre un certain temps (tant que votre SQL ne faisait rien d'idiot essayant de prendre un instantané ou quoi que ce soit), mais si votre serveur peut le diffuser, le SQLDatreader ne doit pas avoir de problème d'utilisation de la mémoire. .
Il y a quelques détails.
sqldatreader va normalement lire une ligne entière en mémoire et le mettre en cache. Cela inclut tous les champs de blob, de sorte que vous puissiez finir par mettre en cache plusieurs champs de 2 Go en mémoire (XML, Varbinary (Max), Varchar (Max), NvarchaRar (MAX)). Si de tels champs sont une préoccupation, vous devez passer dans le CommandBehavior.SuCessAccess à ExecuTereader et utilisez les capacités de diffusion de la SQLClient spécifique Types tels que SQLBYtes.Stream . < / p>
Une connexion est occupée jusqu'à ce que le Sqldatreader se termine. Cela crée des problèmes transactionnels car vous ne serez pas en mesure de traiter dans la base de données dans la même transaciton, car la connexion est occupée. Essayer d'ouvrir un conneccion différent et s'inscrire à la même transaction échouera, car les transactivités distribuées de la boucle sont interdites. La loution est d'utiliser Mars . Vous le faites en définissant multipléceptiveresultsultsultsultsultsUtes = true sur la connexion. Cela vous permet de publier la commande sur la connexion la même tandis qu'un lecteur de données est toujours actif (boucle de récupération de processch typique). Lisez le lien avec Christian Kleinerman's avec beaucoup de soin, assurez-vous de comprendre les problèmes et les restrictions autour des mars et des transactions, ils sont assez subtils et contretents intuitifs.
Un long traitement dans le client bloquera le serveur. Votre requête sera toujours exécutée tout ce temps et le serveur devra la suspendre lorsque le tuyau de communication se remplit. Une requête consomme un travailleur (ou plus s'il a des plans parallèles) et Les ouvrages sont un très matières rares sur un serveur (ils équivalent à peu près aux threads).
Vous ne serez pas à Bale pour donner à de nombreux clients traitant d'énormes ensembles de résultats à leur propre leuf.
taille de transaction. Traitement des enregistrements de trillions sur une transaction ne fonctionnera jamais. Le journal devra se développer pour accueillir la transaction totale et ne pas tronquer et réutiliser les VLFS, entraînant une croissance énorme la croissance du journal.
temps de récupération. Si le traitement échoue au record de 999 milliards, il devra retourner tout le travail effectué, de sorte qu'il faudra un autre «12» jours »juste pour la restauration.
Très bonne information. +1 Quel rôle les transactions jouent-elles dans le système si les données doivent être éventuellement stimulantes? Que suggéreriez-vous est la bonne façon de traiter le processus de lot 1000 ou 10000 à la fois? (Voir les commentaires à Jon Skeet)
La manière appropriée de créer des lots pouvant être reprises en toute sécurité dépend de la tâche réelle effectuée. Un exemple trivial consiste à avoir une table avec la valeur de la clé en cluster «actuelle». Dans une transaction, vous obtenez la valeur de la table, sélectionnez la commande suivante 10K Commande par clé en cluster, ce qui les traite, mettez à jour la valeur de la clé actuelle dans le tableau, commettre. Rincer, cycle et répétition.
Vous envisagez de lire un trillion dossiers? Ou est-ce juste pour intéresser?