Angesichts Ihrer Anforderungen von:
- A) Niedrige RAM-Nutzung
- B) Einhaltung von Dateigrößenbeschränkungen in Mongo
- C) Eine ansprechende Benutzeroberfläche
Ich würde etwas in der Art des Folgenden in Betracht ziehen.
Nehmen Sie dieses Beispielverzeichnis
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 könnte es möglicherweise dargestellt werden als:
{
"C:": {
"X": {
"B": {},
"file.txt": "file information..."
},
"Y": {
"file.pdf": "file information...",
"R": {
"file.js": "file information..."
}
}
}
}
Letzteres lässt sich, wie Sie bereits betont haben, nicht gut mit großen Verzeichnisstrukturen skalieren (ich kann Ihnen aus erster Hand sagen, dass Browser einen JSON-Blob nicht zu schätzen wissen, der selbst ein bescheidenes Verzeichnis mit ein paar tausend Dateien/Ordnern darstellt). Ersteres ist zwar mit einigen tatsächlichen Dateisystemen verwandt und im richtigen Kontext effizient, aber es ist mühsam, mit der Konvertierung in und aus JSON zu arbeiten.
Mein Vorschlag ist, jedes Verzeichnis in ein separates JSON-Dokument aufzuteilen, da dies alle drei Probleme angeht, jedoch nichts kostenlos ist, und dies die Codekomplexität, die Anzahl der Anfragen pro Sitzung usw. erhöht.
Die obige Struktur könnte in die folgenden Dokumente aufgeteilt werden:
[
{
"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"
}
]
Wobei jedes Dokument ein Verzeichnis oder eine Datei und (falls Verzeichnis) seine unmittelbar untergeordneten IDs darstellt. Untergeordnete Elemente können mit ihren IDs verzögert geladen und in der Benutzeroberfläche an ihre übergeordneten Elemente angehängt werden. Gut implementiertes verzögertes Laden kann untergeordnete Knoten bis zu einer gewünschten Tiefe vorladen, wodurch eine sehr reaktionsschnelle Benutzeroberfläche entsteht. Die RAM-Nutzung ist minimal, da Ihr Server nur kleine Nutzlasten pro Anfrage verarbeiten muss. Die Anzahl der Anfragen steigt im Vergleich zu einem Einzeldokument-Ansatz erheblich, aber auch hier kann ein cleveres Lazy-Loading Anfragen gruppieren und die Gesamtzahl reduzieren.
AKTUALISIERUNG 1 :Irgendwie habe ich Ihren vorletzten Absatz übersehen, bevor ich geantwortet habe, also ist das wahrscheinlich mehr oder weniger das, was Sie im Sinn hatten. Um das Problem zu vieler Dokumente anzugehen, kann eine bestimmte Ebene von Clustering-Knoten innerhalb von Dokumenten in Ordnung sein. Ich muss jetzt aufbrechen, aber ich werde darüber nachdenken.
AKTUALISIERUNG 2 :Ich habe eine Zusammenfassung einer vereinfachten Version des von mir erwähnten Clustering-Konzepts erstellt. Es berücksichtigt keine Dateien, nur Ordner, und es enthält keinen Code zum Aktualisieren der Dokumente. Hoffentlich gibt es Ihnen einige Ideen, ich werde es für meine eigenen Zwecke weiter aktualisieren.
Inhalt:tree_docs_cluster.js
