پيارا ڪميونٽي، هي مضمون سوين لکن ننڍين فائلن کي موثر طريقي سان محفوظ ڪرڻ ۽ ٻيهر حاصل ڪرڻ تي ڌيان ڏيندو. ھن مرحلي ۾، آخري حل تجويز ڪيو ويو آھي POSIX-مطابقت رکندڙ فائل سسٽم لاءِ مڪمل سپورٽ سان لاڪ لاءِ، بشمول ڪلسٽر لاڪ، ۽ بظاھر بظاھر ڪچھري کان سواءِ.
تنهن ڪري مون هن مقصد لاءِ پنهنجو ڪسٽم سرور لکيو.
هن ڪم کي لاڳو ڪرڻ جي دوران، اسان بنيادي مسئلي کي حل ڪرڻ ۾ مدد ڪئي، ۽ ساڳئي وقت ڊسڪ اسپيس ۽ رام ۾ بچت حاصل ڪئي، جيڪو اسان جو ڪلستر فائل سسٽم بي رحمي سان استعمال ڪري رهيو هو. دراصل، اهڙيون ڪيتريون ئي فائلون ڪنهن به ڪلسٽر ٿيل فائيل سسٽم لاءِ نقصانڪار آهن.
خيال هي آهي:
سادي لفظن ۾، ننڍيون فائلون سرور ذريعي اپلوڊ ڪيون وينديون آهن، اهي سڌو آرڪائيو ۾ محفوظ ڪيون وينديون آهن، ۽ ان مان پڙهي پڻ، ۽ وڏيون فائلون هڪ طرف رکيا ويندا آهن. اسڪيم: 1 فولڊر = 1 آرڪائيو، مجموعي طور تي اسان وٽ ڪيترائي ملين آرڪائيوز آهن ننڍيون فائلون، ۽ نه ڪي سئو ملين فائلون. ۽ هي سڀ مڪمل طور تي لاڳو ڪيو ويو آهي، بغير ڪنهن اسڪرپٽ جي يا فائلن کي ٽار / زپ آرڪائيوز ۾ رکڻ جي.
مختصر رکڻ جي ڪوشش ڪندس، پوسٽ ڊگھي ٿيڻ جي صورت ۾ اڳ ۾ معافي وٺندس.
اهو سڀ ان حقيقت سان شروع ٿيو ته مون کي دنيا ۾ هڪ مناسب سرور نه ملي سگهيو آهي جيڪو HTTP پروٽوڪول ذريعي حاصل ڪيل ڊيٽا کي سڌو سنئون آرڪائيوز ۾ محفوظ ڪري سگهي، روايتي آرڪائيوز ۽ اعتراض جي اسٽوريج ۾ موجود نقصانن کان سواءِ. ۽ ڳولا جو سبب 10 سرورن جو اصل ڪلستر هو، جيڪو وڏي پيماني تي وڌي چڪو هو، جنهن ۾ 250,000,000 ننڍيون فائلون اڳ ۾ ئي جمع ٿي چڪيون هيون، ۽ ترقي جو رجحان بند ٿيڻ وارو نه هو.
انهن لاءِ جيڪي مضمون پڙهڻ پسند نٿا ڪن، ٿورڙي دستاويز آسان آهي:
и .
۽ ساڳئي وقت ڊاکر، هاڻي اتي هڪ اختيار آهي صرف nginx سان اندر صرف صورت ۾:
docker run -d --restart=always -e host=localhost -e root=/var/storage
-v /var/storage:/var/storage --name wzd -p 80:80 eltaline/wzdاڳيون:
جيڪڏهن ڪيتريون ئي فائلون آهن، اهم وسيلن جي ضرورت آهي، ۽ بدترين حصو اهو آهي ته انهن مان ڪجهه ضايع ٿي ويا آهن. مثال طور، جڏهن ڪلستر ٿيل فائل سسٽم استعمال ڪندي (هن صورت ۾، MooseFS)، فائل، ان جي حقيقي سائيز کان سواء، هميشه گهٽ ۾ گهٽ 64 KB وٺندو آهي. يعني 3، 10 يا 30 KB سائيز جي فائلن لاءِ، ڊسڪ تي 64 KB گھربل آھن. جيڪڏهن اتي هڪ بلين فائلن جو چوٿون آهي، اسان 2 کان 10 ٽيرا بائيٽ وڃائي ڇڏيون ٿا. اهو ممڪن نه ٿيندو ته نئين فائلن کي اڻڄاتل طور تي ٺاهيو وڃي، ڇو ته MooseFS هڪ حد آهي: هر فائل جي هڪ نقل سان 1 بلين کان وڌيڪ.
جيئن فائلن جو تعداد وڌي ٿو، ميٽاداٽا لاءِ تمام گھڻي RAM جي ضرورت آھي. بار بار وڏا ميٽاداٽا ڊمپ پڻ ايس ايس ڊي ڊرائيو جي لباس ۽ آنسو ۾ حصو وٺندا آهن.
wZD سرور. اسان شين کي ڊسڪ تي ترتيب ڏيو ٿا.
سرور گو ۾ لکيل آهي. سڀ کان پهريان، مون کي فائلن جو تعداد گهٽائڻ جي ضرورت آهي. اهو ڪيئن ڪجي؟ آرڪائيو ڪرڻ جي ڪري، پر هن معاملي ۾ بغير ڪمپريشن، ڇاڪاڻ ته منهنجون فائلون صرف ٺهيل تصويرون آهن. BoltDB بچاء ۾ آيو، جيڪو اڃا تائين ان جي گهٽتائي کان ختم ٿي چڪو هو، اهو دستاويز ۾ ظاهر ٿئي ٿو.
مجموعي طور تي، هڪ بلين فائلن جي چوٿين بدران، منهنجي صورت ۾ صرف 10 ملين بولٽ آرڪائيو رهجي ويا. جيڪڏهن مون کي موجوده ڊاريڪٽري فائل ڍانچي کي تبديل ڪرڻ جو موقعو مليو، اهو ممڪن ٿيندو ته ان کي گھٽائڻ لاء تقريبا 1 ملين فائلن تائين.
سڀئي ننڍيون فائلون بولٽ آرڪائيوز ۾ ڀريل هونديون آهن، جيڪي خودڪار طريقي سان انهن ڊائريڪٽرن جا نالا وصول ڪندا آهن جن ۾ اهي واقع آهن، ۽ سڀئي وڏيون فائلون آرڪائيوز جي اڳيان رهنديون آهن؛ انهن کي پيڪ ڪرڻ جو ڪو به مقصد ناهي، اهو حسب ضرورت آهي. ننڍڙن کي محفوظ ڪيو ويو آهي، وڏن کي اڻ مٽ رهجي ويو آهي. سرور ٻنهي سان شفاف ڪم ڪري ٿو.
آرڪيٽيڪچر ۽ wZD سرور جون خاصيتون.
سرور لينڪس، بي ايس ڊي، سولاريس ۽ او ايس ايڪس آپريٽنگ سسٽم تحت هلندي آهي. مون صرف لينڪس تحت AMD64 آرڪيٽيڪچر لاءِ آزمايو، پر اهو ڪم ڪرڻ گهرجي ARM64، PPC64، MIPS64 لاءِ.
مکيه خاصيتون:
- ملٽي ٽريڊنگ؛
- ملائي سرور، غلطي رواداري ۽ لوڊ توازن فراهم ڪرڻ؛
- صارف يا ڊولپر لاء وڌ ۾ وڌ شفافيت؛
- سپورٽ ٿيل HTTP طريقا: GET، HEAD، PUT ۽ DELETE؛
- ڪلائنٽ هيڊرز ذريعي پڙهڻ ۽ لکڻ جي رويي جو ڪنٽرول؛
- لچڪدار مجازي ميزبانن لاءِ سپورٽ؛
- CRC ڊيٽا جي سالميت کي سپورٽ ڪريو جڏهن لکڻ/پڙهڻ؛
- گھٽ ۾ گھٽ ميموري واپرائڻ لاءِ نيم متحرڪ بفر ۽ بھترين نيٽ ورڪ ڪارڪردگي ٽيننگ؛
- ملتوي ٿيل ڊيٽا گڏ ڪرڻ؛
- ان کان علاوه، هڪ گھڻن موضوعن واري آرڪيور wZA پيش ڪئي وئي آهي لڏپلاڻ فائلن لاءِ خدمت کي روڪڻ کان سواءِ.
حقيقي تجربو:
مان ڪافي عرصي کان لائيو ڊيٽا تي سرور ۽ آرڪيور کي ترقي ۽ جانچ ڪري رهيو آهيان، هاڻي اهو ڪاميابيءَ سان هڪ ڪلستر تي ڪم ڪري رهيو آهي جنهن ۾ 250,000,000 ننڍيون فائلون (تصويرون) شامل آهن جيڪي 15,000,000 ڊائريڪٽرن ۾ موجود آهن الڳ SATA ڊرائيو تي. 10 سرورن جو ڪلستر ھڪڙو اصل سرور آھي جيڪو CDN نيٽ ورڪ جي پويان نصب ٿيل آھي. ان جي خدمت ڪرڻ لاء، 2 Nginx سرور + 2 wZD سرور استعمال ڪيا ويا آھن.
انهن لاءِ جيڪي هن سرور کي استعمال ڪرڻ جو فيصلو ڪن ٿا، اهو حڪمت وارو هوندو ته ڊاريڪٽري جي جوڙجڪ جي رٿابندي ڪرڻ، جيڪڏهن قابل اطلاق هجي، استعمال کان اڳ. مون کي فوري طور تي هڪ رزرويشن ڪرڻ ڏيو ته سرور جو مقصد هر شي کي 1 بولٽ آرڪائيو ۾ گڏ ڪرڻ جو ارادو ناهي.
ڪارڪردگي جاچ:
زپ ٿيل فائل جي سائيز جيتري ننڍي، تيزي سان GET ۽ PUT آپريشن ڪيا ويندا. اچو ته HTTP ڪلائنٽ لکڻ جي مجموعي وقت کي باقاعده فائلن ۽ بولٽ آرڪائيوز سان گڏ پڙهو. 32 KB، 256 KB، 1024 KB، 4096 KB ۽ 32768 KB سائيز جي فائلن سان ڪم ڪريو.
جڏهن بولٽ آرڪائيوز سان ڪم ڪري رهيا آهن، هر فائل جي ڊيٽا جي سالميت کي جانچيو ويندو آهي (CRC استعمال ڪيو ويندو آهي)، رڪارڊنگ کان اڳ ۽ رڪارڊنگ کان پوء، پرواز تي پڙهڻ ۽ ٻيهر حساب ڪتاب ٿئي ٿي، اهو قدرتي طور تي دير سان متعارف ڪرايو آهي، پر بنيادي شيء ڊيٽا سيڪيورٽي آهي.
مون SSD ڊرائيو تي ڪارڪردگي جا امتحان ڪيا، ڇو ته SATA ڊرائيو تي ٽيسٽ واضح فرق نه ڏيکاريندا آهن.
امتحان جي نتيجن تي ٻڌل گراف:
جيئن توهان ڏسي سگهو ٿا، ننڍين فائلن لاءِ آرڪائيو ٿيل ۽ غير آرڪائيو ٿيل فائلن جي وچ ۾ پڙهڻ ۽ لکڻ جي وقت ۾ فرق ننڍڙو آهي.
اسان هڪ مڪمل طور تي مختلف تصوير حاصل ڪندا آهيون جڏهن 32 MB سائيز جي فائلن کي پڙهڻ ۽ لکڻ جي جانچ ڪندي:
فائل پڙهڻ جي وچ ۾ وقت جو فرق 5-25 ms جي اندر آهي. رڪارڊنگ سان، شيون خراب آهن، فرق اٽڪل 150 ايم ايس آهي. پر هن حالت ۾ وڏي فائلن کي اپلوڊ ڪرڻ جي ڪا ضرورت ناهي؛ ائين ڪرڻ ۾ ڪو به مقصد ناهي؛ اهي آرڪائيوز کان الڳ ٿي سگهن ٿيون.
*ٽيڪنيڪي طور، توھان ھي سرور استعمال ڪري سگھو ٿا ڪمن لاءِ جن کي NoSQL جي ضرورت آھي.
wZD سرور سان ڪم ڪرڻ جا بنيادي طريقا:
باقاعده فائل لوڊ ڪندي:
curl -X PUT --data-binary @test.jpg http://localhost/test/test.jpgبولٽ آرڪائيو تي فائل اپلوڊ ڪرڻ (جيڪڏهن سرور پيراميٽر fmaxsize، جيڪو وڌ ۾ وڌ فائل سائيز جو تعين ڪري ٿو جيڪو آرڪائيو ۾ شامل ڪري سگهجي ٿو، ان کان وڌيڪ نه آهي؛ جيڪڏهن اهو وڌي ويو آهي، فائل آرڪائيو جي اڳيان معمول وانگر اپ لوڊ ڪيو ويندو):
curl -X PUT -H "Archive: 1" --data-binary @test.jpg http://localhost/test/test.jpgفائل ڊائون لوڊ ڪرڻ (جيڪڏهن ڊسڪ ۽ آرڪائيو ۾ ساڳئي نالن سان فائلون آهن، پوء ڊائون لوڊ ڪرڻ وقت، ترجيح ڏني ويندي آهي ڊفالٽ غير محفوظ ٿيل فائل کي):
curl -o test.jpg http://localhost/test/test.jpgبولٽ آرڪائيو مان فائل ڊائون لوڊ ڪندي (زبردستي):
curl -o test.jpg -H "FromArchive: 1" http://localhost/test/test.jpgٻين طريقن جا تفصيل دستاويز ۾ آهن.
سرور في الحال صرف HTTP پروٽوڪول کي سپورٽ ڪري ٿو؛ اهو اڃا تائين HTTPS سان ڪم نٿو ڪري. پوسٽ جو طريقو پڻ سپورٽ نه آهي (اهو اڃا تائين فيصلو نه ڪيو ويو آهي ته اهو ضروري آهي يا نه).
جيڪو به سورس ڪوڊ ڳوليندو ان کي اتي بٽر اسڪاچ ملندو، هرڪو اهو پسند نٿو ڪري، پر مون بنيادي ڪوڊ کي ويب فريم ورڪ جي ڪمن سان نه ڳنڍيو، سواءِ انٽرپرٽ هينڊلر جي، تنهن ڪري مستقبل ۾ آئون جلد ئي ان کي تقريباً ڪنهن به لاءِ ٻيهر لکي سگهان ٿو. انجڻ.
ڪرڻ:
- توهان جي پنهنجي ريپليڪٽر ۽ ورهائيندڙ جي ترقي + جيو وڏي سسٽم ۾ استعمال جي امڪان لاءِ بغير ڪلسٽر فائل سسٽم (بالغ لاءِ سڀ ڪجهه)
- ميٽاداٽا جي مڪمل ريورس وصولي جو امڪان جيڪڏهن اهو مڪمل طور تي گم ٿي ويو آهي (جيڪڏهن هڪ تقسيم ڪندڙ استعمال ڪندي)
- مختلف پروگرامنگ ٻولين لاءِ مسلسل نيٽ ورڪ ڪنيڪشن ۽ ڊرائيور استعمال ڪرڻ جي صلاحيت لاءِ اصلي پروٽوڪول
- NoSQL جزو استعمال ڪرڻ لاءِ ترقي يافته امڪان
- مختلف قسمن جا ڪمپريشن (gzip، zstd، snappy) فائلن لاءِ يا بولٽ آرڪائيوز اندر ۽ باقاعده فائلن لاءِ
- بولٽ آرڪائيو اندر فائلن يا قدرن لاءِ مختلف قسمن جا انڪرپشن ۽ باقاعده فائلن لاءِ
- دير ٿيل سرور-سائڊ وڊيو ڪنورشن، بشمول GPU تي
مون وٽ سڀ ڪجهه آهي، مون کي اميد آهي ته هي سرور ڪنهن لاءِ ڪارآمد ثابت ٿيندو، BSD-3 لائسنس، ڊبل ڪاپي رائيٽ، ڇو ته جيڪڏهن ڪا ڪمپني نه هجي ها جتي آئون ڪم ڪريان ها، سرور نه لکيو وڃي ها. مان اڪيلو ڊولپر آهيان. مان شڪر گذار ٿيندس ته توهان کي مليل ڪي به بگ ۽ فيچر جي درخواستن لاءِ.
جو ذريعو: www.habr.com