С учетом ваших требований:
- A) Низкое использование ОЗУ
- 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" : "C:\X\file.txt",
},
"Y" : {
"file.pdf" : "C:\Y\file.pdf",
"R" : {
"file.js" : "C:\Y\R\file.js",
}
}
}
}
Последний, как вы указали, плохо масштабируется при больших структурах каталогов (я могу вам сказать, что браузеры не оценят BLOB-объект JSON, представляющий даже скромный каталог с несколькими тысячами файлов / папок).Первый, хотя и сродни некоторым реальным файловым системам и эффективен в правильном контексте, является трудной задачей для преобразования в и из JSON.
Мое предложение состоит в том, чтобы разбить каждый каталог на отдельный документ JSON, так как этоустранить все три проблемы, однако ничего не бесплатно, и это увеличит сложность кода, количество запросов на сеанс и т. д.
Приведенная выше структура может быть разбита на следующие документы:
{
"id" : "CCCCCCCC",
"type" : "p",
"name" : "C:",
"children" : [
{ "name" : "X", "type" : "p", "id" : "XXXXXXXX" },
{ "name" : "Y", "type" : "p", "id" : "YYYYYYYY" }
]
}
{
"id" : "XXXXXXXX",
"type" : "p",
"name" : "X",
"children" : [
{ "name" : "B", "type" : "p", "id" : "BBBBBBBB" },
{ "name" : "file.txt", "type" : "f", "path" : "C:\X\file.txt", "size" : "1024" }
]
}
{
"id" : "YYYYYYYY",
"type" : "p",
"name" : "Y",
"children" : [
{ "name" : "R", "type" : "p", "id" : "RRRRRRRR" },
{ "name" : "file.pdf", "type" : "f", "path" : "C:\Y\file.pdf", "size" : "2048" }
]
}
{
"id" : "BBBBBBBB",
"type" : "p",
"name" : "B",
"children" : [ ]
}
{
"id" : "RRRRRRRR",
"type" : "p",
"name" : "R",
"children" : [
{ "name" : "file.js", "type" : "f", "path" : "C:\Y\R\file.js", "size" : "2048" }
]
}
Где каждый документ представляет папку и только ее непосредственные дочерние элементы.Дочерние папки могут быть загружены с использованием их идентификаторов и добавлены к их родителям в пользовательском интерфейсе.Хорошо реализованная отложенная загрузка может предварительно загружать дочерние узлы на желаемую глубину, создавая очень отзывчивый пользовательский интерфейс.Использование оперативной памяти минимально, поскольку ваш сервер должен обрабатывать только небольшие полезные нагрузки по предварительному запросу.Количество запросов значительно возрастает по сравнению с подходом с одним документом, но, опять же, некоторая умная отложенная загрузка может кластеризовать запросы и сокращать общее количество.
ОБНОВЛЕНИЕ 1 : я как-то пропустил вашеВторой последний абзац, прежде чем ответить, так что это, вероятно, более или менее то, что вы имели в виду.Для решения проблемы слишком большого количества документов может быть необходим некоторый уровень узлов кластеризации в документах.Мне нужно сейчас уйти, но я подумаю над этим.
ОБНОВЛЕНИЕ 2 : Я создал суть упрощенной версии упомянутой концепции кластеризации.Он не учитывает файлы, только папки, и он не включает в себя и код для обновления документов.Надеюсь, это даст вам некоторые идеи, я буду продолжать обновлять его для своих собственных целей.
Суть: tree_docs_cluster.js