ګرانه ټولنه، دا مقاله به په اغیزمنه توګه د سلګونو میلیونو کوچنیو فایلونو ذخیره کولو او بیرته ترلاسه کولو تمرکز وکړي. په دې مرحله کې، وروستی حل د POSIX سره مطابقت لرونکي فایل سیسټمونو لپاره وړاندیز شوی چې د لاکونو لپاره بشپړ ملاتړ لري، په شمول د کلستر لاکونو په شمول، او داسې ښکاري چې حتی د کرچ پرته.
نو ما د دې هدف لپاره خپل ګمرک سرور ولیکه.
د دې کار د پلي کولو په جریان کې، موږ د اصلي ستونزې حل کولو توان درلود، او په ورته وخت کې د ډیسک ځای او RAM کې سپما ترلاسه کړه، کوم چې زموږ د کلستر فایل سیسټم په بې رحمۍ سره مصرفوي. په حقیقت کې، دا ډول ډیری فایلونه د هر کلستر شوي فایل سیسټم لپاره زیانمن دي.
نظر دا دی:
په ساده کلمو کې، کوچني فایلونه د سرور له لارې اپلوډ کیږي، دوی په مستقیم ډول آرشیف کې خوندي کیږي، او له هغې څخه لوستل کیږي، او لوی فایلونه څنګ ته کیښودل کیږي. سکیم: 1 فولډر = 1 آرشیف، په مجموع کې موږ د کوچنیو فایلونو سره څو ملیون آرشیفونه لرو، نه څو سوه ملیون فایلونه. او دا ټول په بشپړ ډول پلي کیږي، پرته له کوم سکریپټ یا د ټار / زپ آرشیفونو کې فایلونه اچول.
زه به هڅه وکړم چې لنډ یې کړم، زه مخکې له مخکې بخښنه غواړم که پوسټ اوږد وي.
دا ټول د دې حقیقت سره پیل شوي چې زه نشم کولی په نړۍ کې یو مناسب سرور ومومم چې کولی شي د HTTP پروتوکول له لارې ترلاسه شوي ډاټا په مستقیم آرشیفونو کې خوندي کړي، پرته له دې چې په دودیز آرشیفونو او د شیانو ذخیره کې زیانونه شتون ولري. او د لټون لامل د 10 سرورونو اصلي کلستر و چې په لویه پیمانه وده کړې وه ، په کوم کې چې 250,000,000 کوچني فایلونه لا دمخه راټول شوي و ، او د ودې رجحان به ودریږي.
د هغو کسانو لپاره چې د مقالو لوستل نه خوښوي، لږ اسناد اسانه دي:
и .
او ډاکر په ورته وخت کې ، اوس یوازې د نګینکس سره یو اختیار شتون لري یوازې په قضیه کې:
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 ته اړتیا ده. په مکرر ډول لوی میټاډاټا ډمپونه د SSD ډرایو په اغوستلو کې هم مرسته کوي.
wZD سرور. موږ شیان په ډیسکونو کې ترتیب کوو.
سرور په Go کې لیکل شوی. له هرڅه دمخه ، زه اړتیا لرم چې د فایلونو شمیر کم کړم. دا څنګه وکړو؟ د آرشیف کولو له امله، مګر پدې حالت کې د کمپریشن پرته، ځکه چې زما فایلونه یوازې کمپرس شوي عکسونه دي. BoltDB د ژغورنې لپاره راغلی، کوم چې لاهم باید د خپلو نیمګړتیاوو څخه لیرې شي، دا په اسنادو کې منعکس کیږي.
په مجموع کې، د یو ملیارد فایلونو د څلورمې برخې پرځای، زما په قضیه کې یوازې 10 ملیون بولټ آرشیفونه پاتې وو. که زه د اوسني لارښود فایل جوړښت بدلولو فرصت وموم ، نو دا به ممکن وي چې دا نږدې 1 ملیون فایلونو ته راټیټ کړم.
ټول کوچني فایلونه د بولټ آرشیفونو کې بسته شوي، کوم چې په اتوماتيک ډول د هغه لارښوونو نومونه ترلاسه کوي چې دوی پکې موقعیت لري، او ټول لوی فایلونه د آرشیف تر څنګ پاتې کیږي؛ د دوی بسته کولو کې هیڅ معنی نشته، دا د دودیز وړ دی. کوچني یې آرشیف شوي دي، لوی یې په بدل کې پاتې دي. سرور د دواړو سره په شفاف ډول کار کوي.
د wZD سرور جوړښت او ځانګړتیاوې.
سرور د لینکس، BSD، سولاریس او OSX عملیاتي سیسټمونو لاندې کار کوي. ما یوازې د لینکس لاندې د AMD64 جوړښت لپاره ازموینه کړې، مګر دا باید د ARM64، PPC64، MIPS64 لپاره کار وکړي.
اصلي ځانګړتیاوې:
- څو اړخیزه
- ملټي سرور، د غلطۍ زغم او د بار توازن چمتو کوي؛
- د کارونکي یا پراختیا کونکي لپاره اعظمي شفافیت؛
- ملاتړ شوي HTTP میتودونه: GET، HEAD، PUT او DELETE؛
- د پیرودونکي سرلیکونو له لارې د لوستلو او لیکلو چلند کنټرول؛
- د انعطاف وړ مجازی کوربه لپاره ملاتړ؛
- د لیکلو / لوستلو پر مهال د CRC ډیټا بشپړتیا ملاتړ کول؛
- نیمه متحرک بفرونه د لږترلږه حافظې مصرف او د شبکې غوره فعالیت تنظیم کولو لپاره؛
- ځنډول شوي ډاټا ترکیب؛
- برسېره پردې، یو څو اړخیز آرشیور wZA د خدمت بندولو پرته د فایلونو مهاجرت لپاره وړاندیز کیږي.
رښتینې تجربه:
زه له ډیرې مودې راهیسې په ژوندیو ډیټا کې سرور او آرشیور رامینځته او ازموینه کوم ، اوس دا په بریالیتوب سره په کلستر کې کار کوي چې پکې 250,000,000 کوچني فایلونه (عکسونه) شامل دي چې په جلا SATA ډرایو کې په 15,000,000 لارښودونو کې موقعیت لري. د 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 ms په اړه دی. مګر پدې حالت کې د لوی فایلونو اپلوډ کولو ته اړتیا نشته؛ په ساده ډول د دې کولو لپاره هیڅ معنی نشته؛ دوی کولی شي له آرشیف څخه جلا ژوند وکړي.
* په تخنیکي توګه، تاسو کولی شئ دا سرور د هغه دندو لپاره وکاروئ چې 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 سره کار نه کوي. د POST میتود هم نه دی ملاتړ شوی (دا لاهم پریکړه نده شوې چې ایا ورته اړتیا ده یا نه).
څوک چې د سرچینې کوډ ته کیندل به هلته بټرسکوچ ومومي ، هرڅوک یې نه خوښوي ، مګر ما اصلي کوډ د ویب چوکاټ دندو سره نه و تړلی ، پرته له مداخلې هینډلر ، نو په راتلونکي کې زه کولی شم ژر تر ژره دا د هرچا لپاره بیا ولیکم. انجن
کول:
- ستاسو د خپل نقل کونکي او توزیع کونکي + جیو پراختیا د کلسټر فایل سیسټمونو پرته په لوی سیسټمونو کې د کارولو امکان لپاره (د لویانو لپاره هرڅه)
- د میټاډاټا د بشپړ بیرته راګرځیدو امکان که چیرې دا په بشپړ ډول ورک شوی وي (که د توزیع کونکي په کارولو سره)
- اصلي پروتوکول د مختلف پروګرامینګ ژبو لپاره د دوامداره شبکې اتصال او ډرایور کارولو وړتیا لپاره
- د NoSQL برخې کارولو لپاره پرمختللي امکانات
- د بولټ آرشیف دننه فایلونو یا ارزښتونو او منظم فایلونو لپاره د مختلف ډولونو فشارونه (gzip, zstd, snappy)
- د بولټ آرشیف دننه او د منظم فایلونو لپاره د فایلونو یا ارزښتونو لپاره د مختلف ډولونو کوډ کول
- د سرور اړخ ویډیو تبادله ځنډول شوې ، پشمول د GPU په شمول
زه هرڅه لرم ، زه امید لرم چې دا سرور به د یو چا لپاره ګټور وي ، د BSD-3 جواز ، دوه ځله کاپي حق ، ځکه چې که چیرې کوم شرکت شتون نه درلود چیرې چې زه کار کوم ، سرور به نه و لیکل شوی. زه یوازینی پرمخ وړونکی یم. زه به د هر هغه بګ او فیچر غوښتنو لپاره مننه وکړم چې تاسو یې ومومئ.
سرچینه: www.habr.com