Biorąc pod uwagę Twoje wymagania:
- A) Niskie użycie pamięci RAM
- B) Ograniczenia rozmiaru pliku spotkania w Mongo
- C) Responsywny interfejs użytkownika
Rozważę coś podobnego do następujących.
Weź ten przykładowy katalog
C:\
C:\X\
C:\X\B\
C:\X\file.txt
C:\Y\
C:\Y\file.pdf
C:\Y\R\
C:\Y\R\file.js
W JSON może to być reprezentowane jako:
{
"C:": {
"X": {
"B": {},
"file.txt": "file information..."
},
"Y": {
"file.pdf": "file information...",
"R": {
"file.js": "file information..."
}
}
}
}
Ta ostatnia, jak zauważyłeś, nie skaluje się dobrze w przypadku dużych struktur katalogów (mogę powiedzieć z pierwszej ręki, że przeglądarki nie docenią blobów JSON reprezentujących nawet skromny katalog z kilkoma tysiącami plików/folderów). Ten pierwszy, choć podobny do niektórych rzeczywistych systemów plików i wydajny we właściwym kontekście, jest trudny do pracy z konwersją do iz formatu JSON.
Proponuję podzielić każdy katalog na osobny dokument JSON, ponieważ rozwiąże to wszystkie trzy problemy, jednak nic nie jest bezpłatne, a to zwiększy złożoność kodu, liczbę żądań na sesję itp.
Powyższą strukturę można podzielić na następujące dokumenty:
[
{
"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"
}
]
Gdzie każdy dokument reprezentuje katalog lub plik oraz (jeśli katalog) jego bezpośrednie identyfikatory podrzędne. Elementy podrzędne mogą być ładowane z opóźnieniem przy użyciu ich identyfikatorów i dołączane do elementu nadrzędnego w interfejsie użytkownika. Dobrze zaimplementowane leniwe ładowanie może wstępnie ładować węzły podrzędne do pożądanej głębokości, tworząc bardzo responsywny interfejs użytkownika. Użycie pamięci RAM jest minimalne, ponieważ twój serwer musi obsługiwać tylko małe ładunki na żądanie. Liczba żądań znacznie wzrasta w porównaniu z podejściem opartym na pojedynczym dokumencie, ale znowu, sprytne leniwe ładowanie może grupować żądania i zmniejszyć całkowitą liczbę.
AKTUALIZACJA 1 :Jakoś przeoczyłem twój przedostatni akapit przed udzieleniem odpowiedzi, więc prawdopodobnie mniej więcej to miałeś na myśli. Aby rozwiązać problem zbyt wielu dokumentów, może być potrzebny pewien poziom klastrowania węzłów w dokumentach. Muszę już iść, ale zastanowię się.
AKTUALIZACJA 2 :Stworzyłem sedno uproszczonej wersji koncepcji klastrowania, o której wspomniałem. Nie uwzględnia plików, tylko folderów i nie zawiera kodu do aktualizacji dokumentów. Mam nadzieję, że podsunie ci to kilka pomysłów, nadal będę go aktualizować do własnych celów.
Treść:tree_docs_cluster.js
