आपकी आवश्यकताओं को देखते हुए:
- A) कम RAM उपयोग
- B) Mongo में फ़ाइल आकार की सीमाओं को पूरा करना
- C) एक प्रतिक्रियाशील UI
मैं निम्नलिखित की तर्ज पर कुछ विचार करूंगा।
इस उदाहरण निर्देशिका को लें
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 दस्तावेज़ में विभाजित करना है, क्योंकि यह सभी तीन मुद्दों को संबोधित करेगा, हालांकि कुछ भी मुफ़्त नहीं है, और इससे कोड जटिलता, प्रति सत्र अनुरोधों की संख्या आदि बढ़ जाएगी।
उपरोक्त संरचना को निम्नलिखित दस्तावेजों में तोड़ा जा सकता है:
[
{
"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"
}
]
जहां प्रत्येक दस्तावेज़ एक निर्देशिका या फ़ाइल का प्रतिनिधित्व करता है और (यदि निर्देशिका) इसकी तत्काल चाइल्ड आईडी। चाइल्ड आइटम को उनकी आईडी का उपयोग करके आलसी लोड किया जा सकता है और UI में उनके माता-पिता के साथ जोड़ा जा सकता है। अच्छी तरह से कार्यान्वित आलसी लोडिंग बच्चे के नोड्स को वांछित गहराई तक लोड कर सकती है, एक बहुत ही प्रतिक्रियाशील यूआई बना सकती है। रैम का उपयोग न्यूनतम है क्योंकि आपके सर्वर को प्रति अनुरोध केवल छोटे पेलोड को संभालना होता है। एकल दस्तावेज़ दृष्टिकोण की तुलना में अनुरोधों की संख्या काफी बढ़ जाती है, लेकिन फिर से, कुछ चतुर आलसी-लोडिंग अनुरोधों को क्लस्टर कर सकते हैं और कुल संख्या को कम कर सकते हैं।
अपडेट 1 :मैंने किसी तरह उत्तर देने से पहले आपके दूसरे अंतिम पैराग्राफ को अनदेखा कर दिया, इसलिए शायद यह आपके मन में कमोबेश यही था। बहुत सारे दस्तावेज़ों के मुद्दे को हल करने के लिए दस्तावेज़ों के भीतर क्लस्टरिंग नोड्स के कुछ स्तर क्रम में हो सकते हैं। मुझे अभी जाना है, लेकिन मैं इस पर कुछ विचार करूंगा।
अपडेट 2 :मैंने अपने द्वारा उल्लिखित क्लस्टरिंग अवधारणा के सरलीकृत संस्करण का सार तैयार किया है। यह फ़ाइलों, केवल फ़ोल्डरों को ध्यान में नहीं रखता है, और इसमें दस्तावेज़ों को अद्यतन करने के लिए शामिल और कोड नहीं है। उम्मीद है कि यह आपको कुछ विचार देगा, मैं इसे अपने उद्देश्यों के लिए अपडेट करना जारी रखूंगा।
