ప్రియమైన సంఘం, ఈ కథనం వందల మిలియన్ల చిన్న ఫైల్‌లను సమర్థవంతంగా నిల్వ చేయడం మరియు తిరిగి పొందడంపై దృష్టి పెడుతుంది. ఈ దశలో, క్లస్టర్ లాక్‌లతో సహా లాక్‌లకు పూర్తి మద్దతుతో POSIX-అనుకూల ఫైల్ సిస్టమ్‌ల కోసం తుది పరిష్కారం ప్రతిపాదించబడింది మరియు క్రచెస్ లేకుండా కూడా ఉంటుంది.
కాబట్టి నేను ఈ ప్రయోజనం కోసం నా స్వంత కస్టమ్ సర్వర్‌ని వ్రాసాను.
ఈ పనిని అమలు చేస్తున్నప్పుడు, మేము ప్రధాన సమస్యను పరిష్కరించగలిగాము మరియు అదే సమయంలో మా క్లస్టర్ ఫైల్ సిస్టమ్ కనికరం లేకుండా వినియోగించే డిస్క్ స్థలం మరియు RAMలో పొదుపులను సాధించగలిగాము. వాస్తవానికి, అటువంటి అనేక ఫైల్‌లు ఏదైనా క్లస్టర్డ్ ఫైల్ సిస్టమ్‌కు హానికరం.
ఆలోచన ఇది:
సరళంగా చెప్పాలంటే, చిన్న ఫైల్‌లు సర్వర్ ద్వారా అప్‌లోడ్ చేయబడతాయి, అవి నేరుగా ఆర్కైవ్‌లో సేవ్ చేయబడతాయి మరియు దాని నుండి కూడా చదవబడతాయి మరియు పెద్ద ఫైల్‌లు పక్కపక్కనే ఉంచబడతాయి. పథకం: 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 అవసరం. తరచుగా పెద్ద మెటాడేటా డంప్‌లు కూడా SSD డ్రైవ్‌ల అరిగిపోవడానికి దోహదం చేస్తాయి.
wZD సర్వర్. మేము డిస్క్‌లలో విషయాలను క్రమంలో ఉంచుతాము.
సర్వర్ గోలో వ్రాయబడింది. అన్నింటిలో మొదటిది, నేను ఫైళ్ల సంఖ్యను తగ్గించాల్సిన అవసరం ఉంది. ఇది ఎలా చెయ్యాలి? ఆర్కైవింగ్ కారణంగా, కానీ ఈ సందర్భంలో కుదింపు లేకుండా, నా ఫైల్‌లు కేవలం కంప్రెస్ చేయబడిన చిత్రాలు కాబట్టి. బోల్ట్‌డిబి రక్షించటానికి వచ్చింది, ఇది ఇప్పటికీ దాని లోపాల నుండి తొలగించబడాలి, ఇది డాక్యుమెంటేషన్‌లో ప్రతిబింబిస్తుంది.
మొత్తంగా, పావు బిలియన్ ఫైల్‌లకు బదులుగా, నా విషయంలో 10 మిలియన్ బోల్ట్ ఆర్కైవ్‌లు మాత్రమే మిగిలి ఉన్నాయి. ప్రస్తుత డైరెక్టరీ ఫైల్ నిర్మాణాన్ని మార్చడానికి నాకు అవకాశం ఉంటే, దానిని దాదాపు 1 మిలియన్ ఫైల్‌లకు తగ్గించడం సాధ్యమవుతుంది.
అన్ని చిన్న ఫైల్‌లు బోల్ట్ ఆర్కైవ్‌లలో ప్యాక్ చేయబడతాయి, అవి ఉన్న డైరెక్టరీల పేర్లను స్వయంచాలకంగా స్వీకరిస్తాయి మరియు అన్ని పెద్ద ఫైల్‌లు ఆర్కైవ్‌ల పక్కన ఉంటాయి; వాటిని ప్యాక్ చేయడంలో అర్థం లేదు, ఇది అనుకూలీకరించదగినది. చిన్నవి ఆర్కైవ్ చేయబడ్డాయి, పెద్దవి మారవు. సర్వర్ రెండింటిలోనూ పారదర్శకంగా పనిచేస్తుంది.
wZD సర్వర్ యొక్క ఆర్కిటెక్చర్ మరియు లక్షణాలు.
సర్వర్ Linux, BSD, Solaris మరియు OSX ఆపరేటింగ్ సిస్టమ్‌ల క్రింద పనిచేస్తుంది. నేను Linux క్రింద AMD64 ఆర్కిటెక్చర్ కోసం మాత్రమే పరీక్షించాను, కానీ అది ARM64, PPC64, MIPS64 కోసం పని చేయాలి.
ప్రధాన లక్షణాలు:
- మల్టీథ్రెడింగ్;
- మల్టీసర్వర్, ఫాల్ట్ టాలరెన్స్ మరియు లోడ్ బ్యాలెన్సింగ్‌ను అందిస్తుంది;
- వినియోగదారు లేదా డెవలపర్ కోసం గరిష్ట పారదర్శకత;
- మద్దతు ఉన్న HTTP పద్ధతులు: GET, HEAD, PUT మరియు DELETE;
- క్లయింట్ శీర్షికల ద్వారా చదవడం మరియు వ్రాయడం ప్రవర్తన నియంత్రణ;
- సౌకర్యవంతమైన వర్చువల్ హోస్ట్‌లకు మద్దతు;
- వ్రాస్తున్నప్పుడు / చదివేటప్పుడు CRC డేటా సమగ్రతకు మద్దతు ఇవ్వండి;
- కనిష్ట మెమరీ వినియోగం మరియు సరైన నెట్‌వర్క్ పనితీరు ట్యూనింగ్ కోసం సెమీ-డైనమిక్ బఫర్‌లు;
- వాయిదా వేసిన డేటా కాంపాక్షన్;
- అదనంగా, సేవను ఆపకుండా ఫైల్‌లను తరలించడానికి బహుళ-థ్రెడ్ ఆర్కైవర్ wZA అందించబడుతుంది.
నిజమైన అనుభవం:
నేను చాలా కాలంగా లైవ్ డేటాలో సర్వర్ మరియు ఆర్కైవర్‌ని డెవలప్ చేస్తున్నాను మరియు పరీక్షిస్తున్నాను, ఇప్పుడు ఇది ప్రత్యేక SATA డ్రైవ్‌లలోని 250,000,000 డైరెక్టరీలలో ఉన్న 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 ఎంఎస్‌లు. కానీ ఈ సందర్భంలో పెద్ద ఫైల్‌లను అప్‌లోడ్ చేయవలసిన అవసరం లేదు; అలా చేయడంలో అర్థం లేదు; వారు ఆర్కైవ్‌ల నుండి విడిగా జీవించగలరు.
*సాంకేతికంగా, మీరు 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