Предвид вашите изисквания за:
- A) Ниско използване на RAM
- B) Спазване на ограниченията за размера на файла в Mongo
- C) Отзивчив потребителски интерфейс
Бих обмислил нещо от рода на следното.
Вземете тази примерна директория
C:\
C:\X\
C:\X\B\
C:\X\file.txt
C:\Y\
C:\Y\file.pdf
C:\Y\R\
C:\Y\R\file.js
В JSON може да бъде представено като:
{
"C:": {
"X": {
"B": {},
"file.txt": "file information..."
},
"Y": {
"file.pdf": "file information...",
"R": {
"file.js": "file information..."
}
}
}
}
Последният, както посочихте, не се мащабира добре с големи структури на директории (мога да ви кажа от първа ръка, че браузърите няма да оценят JSON петно, представляващо дори скромна директория с няколко хиляди файла/папки). Първата, макар и подобна на някои действителни файлови системи и ефективна в правилния контекст, е трудна за работа с конвертирането към и от JSON.
Моето предложение е всяка директория да бъде разделена на отделен JSON документ, тъй като това ще реши и трите проблема, но нищо не е безплатно и това ще увеличи сложността на кода, броя на заявките на сесия и т.н.
Горната структура може да бъде разделена на следните документи:
[
{
"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"
}
]
Където всеки документ представлява директория или файл и (ако е директория) неговите непосредствени дъщерни идентификатори. Дъщерните елементи могат да се зареждат отложено, като се използват техните идентификатори и да се добавят към техния родител в потребителския интерфейс. Добре реализираното отложено зареждане може предварително да зареди дъщерни възли до желана дълбочина, създавайки много отзивчив потребителски интерфейс. Използването на RAM е минимално, тъй като вашият сървър трябва да обработва само малки полезни натоварвания на заявка. Броят на заявките се увеличава значително в сравнение с подхода с един документ, но отново, някои интелигентни отложени зареждания могат да групират заявките и да намалят общия брой.
АКТУАЛИЗАЦИЯ 1 :Някак си пропуснах втория ви последен параграф, преди да отговоря, така че вероятно това е горе-долу това, което сте имали предвид. За справяне с проблема с твърде много документи може да е подходящо определено ниво на клъстерни възли в рамките на документите. Сега трябва да тръгвам, но ще помисля малко.
АКТУАЛИЗАЦИЯ 2 :Създадох същината на опростена версия на концепцията за групиране, която споменах. Той не взема под внимание файлове, а само папки и не включва и код за актуализиране на документите. Надяваме се, че ще ви даде някои идеи, ще продължа да го актуализирам за собствените си цели.
Gist:tree_docs_cluster.js
