J'ai été chargé de télécharger environ 100 millions de lignes de données de stockage de table Azure. La chose importante ici étant de la vitesse.
Le processus que nous utilisons télécharge 10 000 rangs du stockage de table Azure. Traiter-les dans une instance locale de SQL Server. Lors du traitement des lignes, il supprime 100 rangées à la fois de la table Azure. Ce processus est fileté pour avoir 8 threads téléchargeant 10 000 lignes à la fois. P>
Le seul problème est que, selon nos calculs. Il faudra environ 40 jours pour télécharger et traiter l'environ 100 millions de lignes que nous avons stockées. Est-ce que quelqu'un sait un moyen plus rapide d'accomplir cette tâche? P>
Une question secondaire: Pendant le processus de téléchargement, Azure, vous renvoyera XML qui ne dispose que de données. Cela ne renvoie pas une erreur. Mais il envoie ceci: p>
<?xml version="1.0" encoding="utf-8" standalone="yes"?> <feed xml:base="azure-url/" xmlns:d="http://schemas.microsoft.com/ado/2007/08/dataservices" xmlns:m="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata" xmlns="http://www.w3.org/2005/Atom"> <title type="text">CommandLogTable</title> <id>azure-url/CommandLogTable</id> <updated>2010-07-12T19:50:55Z</updated> <link rel="self" title="CommandLogTable" href="CommandLogTable" /> </feed> 0
6 Réponses :
Très probablement, votre facteur de limitation est la bande passante réseau, pas le traitement. Si tel est le cas, votre seul espoir réel est de développer: plus de machines fonctionnent plus de threads pour télécharger des données.
BTW, n'a pas d'azur exposer un mécanisme "exportation" qui supprimera la nécessité de télécharger toutes les lignes manuellement?
D'après ce que je peux dire que le facteur limitant n'est pas une bande passante. C'est la latence d'obtenir et de supprimer des rangées d'Azure c'est le problème.
@jwoose: Comment déterminez-vous cela? J'ai du mal à croire que vous n'êtes pas I / O lié.
sur votre question secondaire, je m'attends à ce que vous obteniez un "jeton de continuation". Si vous utilisez la bibliothèque client de stockage .NET, essayez d'ajouter .AStataServiceQuery () à votre requête.
Quant à votre question principale, la requête est la meilleure chose que vous puissiez faire. On dirait que vous accédez à votre stockage à partir d'une machine locale (non sous Windows Azure). Si tel est le cas, je voudrais imaginer que vous puissiez accélérer un peu de choses en déployant un petit service à Windows Azure qui récupère les données du stockage de table (beaucoup plus rapidement, car il y a une bande passante plus élevée et une latence plus faible dans le centre de données), puis compresse la Résultats et les renvoie à votre machine locale. Il y a beaucoup de frais généraux sur les tables XML Windows Azure renvoyer en arrière, alors en décentrant que les lignes et regrouperaient probablement beaucoup de temps de transfert.
Je suis d'accord avec l'approche suggérée de Steve. En outre, envisagez de rédiger vos images comprimées sur Blob Stockage. Cela les rend très faciles à récupérer de votre environnement sur site.
Vous êtes correct sur ma question secondaire. Le jeton de continuation est renvoyé si votre demande prend plus de 5 secondes.
Outre les suggestions sur les limites de la bande passante, vous pouvez facilement exécuter des limites de compte de stockage, car chaque partition de table est limitée à environ 500 transactions par seconde.
En outre: il y a une optimisation déployée (algorithme de Nagle) qui pourrait réellement ralentir les choses pour les petites lectures (telles que vos données de données 1K). Voici un Poste du blog sur la désactivation de la nagage , qui pourrait potentiellement accélérer vos lectures considérablement, surtout si vous courez directement dans un service d'azur sans latence Internet à la manière.
En plus des suggestions de Désactivation de Naging , il y a un message extrêmement beau sur Améliorer les performances du stockage de table azur . En fait, Cependant, Stockage de table n'est peut-être pas la meilleure solution pour d'énormes scénarios de stockage (plus de millions de disques). La latence est le facteur de meurtre ici . Pour contourner ce problème, j'utilise avec succès des stockages de base de données basés sur des fichiers, où les modifications sont effectuées localement (sans la latence de clap de réseau) et sont engagées à blob en téléchargeant le fichier de retour (la simultanée et la mise à l'échelle ont été appliquées ici par < Un href = "https://code.google.com/archive/p/lokad-cqrs" rel = "nofollow NOREFERRER"> LOKAD.CQRS Moteur d'applications pour Windows Azure).
Insertion de 10 millions d'enregistrements à la base de données SQLITE à une fois (dans la transaction, où chaque enregistrement a été indexé par 2 champs et que des données schémas arbitraires sérialisées via Protobuf) n'ont pris que de 200 secondes sur la moyenne. Téléchargement / Téléchargement de fichier résultant - Environ 15 secondes sur la moyenne. Lectures aléatoires par index - instantanée (à condition que le fichier soit mis en cache dans le stockage local et l'ETAG correspond à la correspondance).
Merci pour vos conseils. Cela devrait finir par aider beaucoup. Et je voulais juste dire que oui, le stockage de la table n'est pas idéal pour ces nombreux enregistrements. C'était un travail autour d'être battu par SQL Azure. Le problème SQL Azure a été corrigé et nous ne stockons plus les données du stockage de table, mais nous voulons toujours les données stockées là-bas.
Je suis content que j'ai aidé. Le stockage de la table est bon (bien que l'API aurait pu être beaucoup mieux mieux) et irremplaçable pour des choses comme le stockage de données d'affichage des applications Web hautement évolutives. Pourtant, dans des scénarios nécessitant une latence extrêmement faible et un débit élevé - ce n'est pas le meilleur (juste comme SQL Azure)
Rinat et jwoose. Le stockage de la table Azure n'est pas relationnel. C'est un NOSQL, Noschema, une base de données distribuée, probablement implémentée d'une manière similaire à ce que vous décrivez. Le stockage de la table Azure est spécialement conçu pour les gazillions d'enregistrements.
Panagiotis, personne ne s'est disputé à la RDB.
Le gros facteur ici est la manière dont les données sont réparties entre les partitions. Une requête selon laquelle les limites de la partition s'étendront à chaque frontière nécessitant un soumettant - même si la partition en question a 0 rangées. Si les données sont 1 partition = 1 rangée, il sera lent, mais vous pouvez augmenter le nombre de threads bien au-dessus de 8. Si les données sont dans n partitions = m lignes, les idées ci-dessous devraient vous accélérer.
En supposant que vous avez plusieurs partitions et chacun avec un certain nombre de lignes, le moyen le plus rapide d'aller sera de tourner autant de fils que possible (si vous utilisez .NET .NET le plinq ou parallèle.foreach (partition) ou queue () et avoir un thread scanner sa partition pour toutes les lignes, processus, post sur SQL et supprimer avant de revenir.
Compte tenu des latences impliquées (10s de MS) et les multiples voyages ronds, même avec des threads, vous n'êtes probablement pas aussi occupé que vous pourriez penser. En outre, vous ne mentionnez pas quelle machine virtuelle que vous utilisez mais que vous souhaiterez peut-être profiler différentes tailles.
Alternativement, une autre façon de le faire serait de tirer parti d'une file d'attente et de certains ouvriers. Pour chaque partition (ou ensemble de partitions), mettez un message dans la file d'attente. Demandez aux travailleurs de la file d'attente (multi-filetés) et de la requête / processus / post / répétition. Vous pouvez faire une pause autant de travailleurs que nécessaire et être répandu sur plus du centre de données (c'est-à-dire plus de débit, etc.).
Le moyen le plus rapide d'obtenir vos données, pris en charge par Amazon, mais pas encore Azure, est de les expédier un disque USB (même un bâton USB), demandez-leur de mettre les données sur le disque et de les expédier à vous.
Une autre option consiste à utiliser le bus de service Appfabric pour obtenir les données sur un autre système lors de sa création, au lieu d'attendre de la télécharger à la fois.
Combien de données par ligne? 400 octets, 400kb, un MEG?
Je n'ai pas travaillé avec Azure, alors je n'essaye donc pas de difficulquer de tirer d'une vue SQL / réseau; Cependant, je lis à travers des blogs et ils disent tous que la même chose - en utilisant Atom est très verbeuse et inefficace pour de grands ensembles de données. Maintenant, je ne suis pas sûr à quel point il est difficile de changer cela; Mais voici un exemple de différences de vitesse / de données weblogs.asp.net/rgillen/archive/2009/08/20/...