Comment renvoyer un grand nombre de données de la base de données à un client Web?

Question

J'ai le problème suivant:
J'ai une application Web qui stocke des données dans la base de données. Je voudrais que les clients puissent extraire les données par ex. de 2 tables dans un fichier (local au client).
La base de données peut être arbitrairement grande (ce qui signifie que je n'ai aucune idée du nombre de données pouvant potentiellement se trouver dans la base de données.
Quelle est la meilleure approche pour cela?
Est-ce que toutes les données sont SELECT et sont renvoyées au client sous la forme d'une structure unique à stocker dans un fichier?
Ou les données doivent-elles être récupérées dans des parties, par ex. d'abord 100 puis 100 prochaines entrées etc et créer la structure unique dans le client?
Y a-t-il des avantages à considérer ici?

Answer 1

Nous avons un cas d'utilisation similaire avec un cluster oracle contenant env. 40 Go de données. La solution qui fonctionne le mieux pour nous est un maximum de données par instruction select, car elle réduit significativement la surcharge de la base de données.

Cela étant dit, il y a trois optimisations qui ont travaillé très bien pour nous:

1.) Nous partitionner les données en 10 ensembles à peu près de même taille et les sélectionner dans la base de données en parallèle. Pour notre cluster, nous avons trouvé que 8 connexions en parallèle fonctionnent environ. 8 fois plus rapide qu'une seule connexion. Il y a une accélération supplémentaire jusqu'à 12 connexions mais cela dépend de votre base de données et de votre dba. 2.) Restez à l'écart de la mise en veille prolongée ou d'autres ORM et utilisez des JDBC personnalisées lorsque vous parlez de grandes quantités de données. Utilisez toutes les optimisations que vous pouvez y trouver (par exemple ResultSet.setFetchSize())

3.) Nos données se compriment très bien et le fait de mettre les données à travers un gziper permet d'économiser beaucoup de temps d'E/S. Dans notre cas, il a éliminé les E/S du chemin critique. En passant, c'est également vrai pour stocker les données dans un fichier.

Answer 2

J'ai construit quelque chose de similaire - il y a quelques problèmes vraiment gênants ici, d'autant plus que la taille du fichier peut dépasser ce que vous pouvez gérer confortablement dans un navigateur. À mesure que la quantité de données augmente, le temps de génération du fichier augmente; À son tour, ce n'est pas ce qu'une application Web est bonne, donc vous courez le risque que votre serveur web ne soit pas content même d'un petit nombre de visiteurs qui demandent tous un gros fichier.

Ce que nous avons fait est de diviser l'application en 3 parties.

La "demande de fichier" était une simple page Web, dans laquelle les utilisateurs authentifiés peuvent demander leur fichier. Ceci lance la deuxième partie en dehors du contexte de la demande de page Web:

Générateur de fichiers. Dans notre cas, il s'agissait d'un service Windows qui examinait une table de base de données avec des demandes de fichiers, sélectionnait la dernière requête, exécutait la requête SQL appropriée, écrivait la sortie dans un fichier CSV et la ZIPtraitait avant de la déplacer vers la sortie répertoire et l'envoi de l'utilisateur avec un lien. Il définit l'état de l'enregistrement dans la base de données pour s'assurer qu'un seul processus s'est produit à un moment donné. Les fichiers ZIP ont été écrits dans un dossier accessible via FTP et WebDAV - ces protocoles ont tendance à mieux fonctionner avec des fichiers volumineux qu'avec un téléchargement HTTP standard. Cela a plutôt bien fonctionné - les utilisateurs n'aimaient pas attendre leurs fichiers, mais le délai était rarement supérieur à quelques minutes.