Với yêu cầu của bạn về:
- A) Sử dụng RAM thấp
- B) Các giới hạn về kích thước tệp họp trong Mongo
- C) Giao diện người dùng đáp ứng
Tôi sẽ xem xét điều gì đó dọc theo những dòng sau đây.
Lấy thư mục ví dụ này
C:\
C:\X\
C:\X\B\
C:\X\file.txt
C:\Y\
C:\Y\file.pdf
C:\Y\R\
C:\Y\R\file.js
Trong JSON, nó có thể được biểu diễn dưới dạng:
{
"C:": {
"X": {
"B": {},
"file.txt": "file information..."
},
"Y": {
"file.pdf": "file information...",
"R": {
"file.js": "file information..."
}
}
}
}
Điều thứ hai, như bạn đã chỉ ra, không mở rộng quy mô tốt với cấu trúc thư mục lớn (tôi có thể nói với bạn rằng các trình duyệt sẽ không đánh giá cao một khối JSON đại diện cho ngay cả một thư mục khiêm tốn với vài nghìn tệp / thư mục). Hệ thống trước đây, mặc dù giống với một số hệ thống tệp thực tế và hoạt động hiệu quả trong ngữ cảnh phù hợp, nhưng rất khó để làm việc với việc chuyển đổi sang và từ JSON.
Đề xuất của tôi là chia từng thư mục thành một tài liệu JSON riêng biệt, vì điều này sẽ giải quyết cả ba vấn đề, tuy nhiên không có gì là miễn phí và điều này sẽ làm tăng độ phức tạp của mã, số lượng yêu cầu mỗi phiên, v.v.
Cấu trúc trên có thể được chia thành các tài liệu sau:
[
{
"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"
}
]
Trong đó mỗi tài liệu đại diện cho một thư mục hoặc tệp và (nếu là thư mục) các ID con ngay lập tức của nó. Các mục con có thể được tải chậm bằng cách sử dụng ID của chúng và được nối với mục mẹ của chúng trong giao diện người dùng. Tải chậm được triển khai tốt có thể tải trước các nút con đến độ sâu mong muốn, tạo ra một giao diện người dùng rất nhạy. Việc sử dụng RAM là tối thiểu vì máy chủ của bạn chỉ phải xử lý các tải trọng nhỏ cho mỗi yêu cầu. Số lượng yêu cầu tăng lên đáng kể so với một cách tiếp cận tài liệu đơn lẻ, nhưng một lần nữa, một số thao tác tải lười thông minh có thể phân cụm các yêu cầu và giảm tổng số.
CẬP NHẬT 1 :Tôi bằng cách nào đó đã bỏ qua đoạn cuối thứ hai của bạn trước khi trả lời, vì vậy đây có lẽ ít nhiều là những gì bạn đã nghĩ đến. Để giải quyết vấn đề quá nhiều tài liệu, một số cấp độ của các nút phân cụm trong tài liệu có thể theo thứ tự. Tôi phải bắt đầu ngay bây giờ nhưng tôi sẽ suy nghĩ lại.
CẬP NHẬT 2 :Tôi đã tạo một ý chính của một phiên bản đơn giản hóa của khái niệm phân cụm mà tôi đã đề cập. Nó không tính đến các tệp tài khoản, chỉ là các thư mục, và nó không bao gồm và mã để cập nhật tài liệu. Hy vọng rằng nó sẽ cung cấp cho bạn một số ý tưởng, tôi sẽ tiếp tục cập nhật nó cho mục đích của riêng tôi.
Gist: tree_docs_cluster.js
