Gezien uw vereisten van:
- A) Laag RAM-gebruik
- B) Voldoen aan bestandsgroottebeperkingen in Mongo
- C) Een responsieve gebruikersinterface
Ik zou iets in de trant van het volgende overwegen.
Neem deze voorbeeldmap
C:\
C:\X\
C:\X\B\
C:\X\file.txt
C:\Y\
C:\Y\file.pdf
C:\Y\R\
C:\Y\R\file.js
In JSON kan het mogelijk worden weergegeven als:
{
"C:": {
"X": {
"B": {},
"file.txt": "file information..."
},
"Y": {
"file.pdf": "file information...",
"R": {
"file.js": "file information..."
}
}
}
}
De laatste schaalt, zoals je al aangaf, niet goed met grote directorystructuren (ik kan je uit eerste hand vertellen dat browsers een JSON-blob niet zullen waarderen die zelfs maar een bescheiden directory met een paar duizend bestanden/mappen vertegenwoordigt). De eerste, hoewel verwant aan sommige echte bestandssystemen en efficiënt in de juiste context, is lastig om te werken met het converteren van en naar JSON.
Mijn voorstel is om elke map op te splitsen in een apart JSON-document, omdat dit alle drie de problemen aanpakt, maar niets is gratis, en dit zal de codecomplexiteit, het aantal verzoeken per sessie, enz. vergroten.
De bovenstaande structuur kan worden onderverdeeld in de volgende documenten:
[
{
"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"
}
]
Waarbij elk document een directory of bestand vertegenwoordigt en (indien directory) de directe onderliggende ID's. Onderliggende items kunnen lui worden geladen met behulp van hun ID's en worden toegevoegd aan hun bovenliggende in de gebruikersinterface. Goed geïmplementeerde lazy loading kan onderliggende nodes vooraf laden tot een gewenste diepte, waardoor een zeer responsieve gebruikersinterface ontstaat. Het RAM-gebruik is minimaal omdat uw server slechts kleine payloads per verzoek hoeft te verwerken. Het aantal verzoeken gaat aanzienlijk omhoog in vergelijking met een benadering met één document, maar nogmaals, een beetje slim lui laden kan verzoeken clusteren en het totale aantal verminderen.
UPDATE 1 :Ik heb op de een of andere manier je voorlaatste alinea over het hoofd gezien voordat ik antwoordde, dus dit is waarschijnlijk min of meer wat je in gedachten had. Om het probleem van te veel documenten aan te pakken, kan een bepaald niveau van clusteringknooppunten in documenten op zijn plaats zijn. Ik moet nu weg, maar ik zal er even over nadenken.
UPDATE 2 :Ik heb een samenvatting gemaakt van een vereenvoudigde versie van het clusteringconcept dat ik noemde. Het houdt geen rekening met bestanden, alleen met mappen, en het bevat geen code om de documenten bij te werken. Hopelijk geeft het je wat ideeën, ik zal het blijven updaten voor mijn eigen doeleinden.
Kern:tree_docs_cluster.js