Compte tenu de vos exigences :
- A) Faible utilisation de la RAM
- B) Respecter les limites de taille de fichier dans Mongo
- C) Une interface utilisateur réactive
Je considérerais quelque chose dans le sens de ce qui suit.
Prenons cet exemple de répertoire
C:\
C:\X\
C:\X\B\
C:\X\file.txt
C:\Y\
C:\Y\file.pdf
C:\Y\R\
C:\Y\R\file.js
En JSON, il pourrait éventuellement être représenté comme :
{
"C:": {
"X": {
"B": {},
"file.txt": "file information..."
},
"Y": {
"file.pdf": "file information...",
"R": {
"file.js": "file information..."
}
}
}
}
Ce dernier, comme vous l'avez souligné, ne s'adapte pas bien aux grandes structures de répertoires (je peux vous dire de première main que les navigateurs n'apprécieront pas un blob JSON représentant même un répertoire modeste avec quelques milliers de fichiers/dossiers). Le premier, bien que semblable à certains systèmes de fichiers réels et efficace dans le bon contexte, est pénible à convertir vers et depuis JSON.
Ma proposition est de diviser chaque répertoire en un document JSON distinct, car cela résoudra les trois problèmes, mais rien n'est gratuit, et cela augmentera la complexité du code, le nombre de requêtes par session, etc.
La structure ci-dessus pourrait être décomposée dans les documents suivants :
[
{
"id": "00000000-0000-0000-0000-000000000000",
"type": "d",
"name": "C:",
"children": [
"11111111-1111-1111-1111-111111111111",
"22222222-2222-2222-2222-222222222222"
]
},
{
"id": "11111111-1111-1111-1111-111111111111",
"type": "d",
"name": "X",
"children": [
"33333333-3333-3333-3333-333333333333",
"55555555-5555-5555-5555-555555555555"
]
},
{
"id": "22222222-2222-2222-2222-222222222222",
"type": "d",
"name": "Y",
"children": [
"44444444-4444-4444-4444-444444444444",
"66666666-6666-6666-6666-666666666666"
]
},
{
"id": "33333333-3333-3333-3333-333333333333",
"type": "d",
"name": "B",
"children": []
},
{
"id": "44444444-4444-4444-4444-444444444444",
"type": "d",
"name": "R",
"children": [
"77777777-7777-7777-7777-777777777777"
]
},
{
"id": "55555555-5555-5555-5555-555555555555",
"type": "f",
"name": "file.txt",
"size": "1024"
},
{
"id": "66666666-6666-6666-6666-666666666666",
"type": "f",
"name": "file.pdf",
"size": "2048"
},
{
"id": "77777777-7777-7777-7777-777777777777",
"type": "f",
"name": "file.js",
"size": "2048"
}
]
Où chaque document représente un répertoire ou un fichier et (si répertoire) ses ID enfants immédiats. Les éléments enfants peuvent être chargés paresseusement à l'aide de leurs identifiants et ajoutés à leur parent dans l'interface utilisateur. Un chargement paresseux bien implémenté peut précharger les nœuds enfants à la profondeur souhaitée, créant ainsi une interface utilisateur très réactive. L'utilisation de la RAM est minimale car votre serveur ne doit gérer que de petites charges utiles par requête. Le nombre de requêtes augmente considérablement par rapport à une approche à document unique, mais encore une fois, un chargement paresseux astucieux peut regrouper les requêtes et réduire le nombre total.
MISE À JOUR 1 :J'ai en quelque sorte oublié votre avant-dernier paragraphe avant de répondre, donc c'est probablement plus ou moins ce que vous aviez en tête. Pour résoudre le problème d'un trop grand nombre de documents, un certain niveau de nœuds de regroupement dans les documents peut être nécessaire. Je dois partir maintenant, mais je vais y réfléchir.
MISE À JOUR 2 :J'ai créé l'essentiel d'une version simplifiée du concept de clustering que j'ai mentionné. Il ne prend pas en compte les fichiers, juste les dossiers, et il n'inclut pas de code pour mettre à jour les documents. J'espère que cela vous donnera quelques idées, je continuerai à le mettre à jour pour mes propres besoins.
Essentiel :tree_docs_cluster.js
