හිතවත් ප්‍රජාව, මෙම ලිපියෙන් කුඩා ගොනු මිලියන සිය ගණනක් කාර්යක්ෂමව ගබඩා කිරීම සහ නැවත ලබා ගැනීම කෙරෙහි අවධානය යොමු කරනු ඇත. මෙම අවස්ථාවෙහිදී, පොකුරු අගුලු ඇතුළුව අගුලු සඳහා පූර්ණ සහය ඇති 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 සේවාදායකය. අපි තැටි මත දේවල් පිළිවෙලට තබමු.
සේවාදායකය Go වලින් ලියා ඇත. ඔක්කොටම කලින් මට files ගාන අඩු කරන්න ඕන උනා. එය කරන්නේ කෙසේද? සංරක්ෂිත කිරීම හේතුවෙන්, නමුත් මෙම අවස්ථාවේ දී සම්පීඩනයකින් තොරව, මගේ ලිපිගොනු හුදෙක් සම්පීඩිත පින්තූර බැවින්. BoltDB ගලවා ගැනීමට පැමිණි අතර එය තවමත් එහි අඩුපාඩු වලින් තුරන් කිරීමට සිදු විය, මෙය ලේඛනගත කිරීමෙන් පිළිබිඹු වේ.
සමස්තයක් වශයෙන්, ගොනු බිලියන හතරෙන් එකක් වෙනුවට, මගේ නඩුවේ ඉතිරිව ඇත්තේ බෝල්ට් ලේඛනාගාර මිලියන 10 ක් පමණි. දැනට පවතින ඩිරෙක්ටරි ගොනු ව්‍යුහය වෙනස් කිරීමට මට අවස්ථාව ලැබුණේ නම්, එය දළ වශයෙන් ගොනු මිලියන 1 දක්වා අඩු කිරීමට හැකි වනු ඇත.
සියලුම කුඩා ලිපිගොනු බෝල්ට් ලේඛනාගාරයට අසුරා ඇති අතර, ඒවා පිහිටා ඇති නාමාවලිවල නම් ස්වයංක්‍රීයව ලැබෙන අතර සියලුම විශාල ලිපිගොනු ලේඛනාගාරය අසල පවතී; ඒවා ඇසුරුම් කිරීමේ තේරුමක් නැත, මෙය අභිරුචිකරණය කළ හැකිය. කුඩා ඒවා සංරක්ෂණය කර ඇත, විශාල ඒවා නොවෙනස්ව පවතී. සේවාදායකය දෙකම සමඟ විනිවිද පෙනෙන ලෙස ක්රියා කරයි.
wZD සේවාදායකයේ ගෘහ නිර්මාණ ශිල්පය සහ විශේෂාංග.
සේවාදායකය Linux, BSD, Solaris සහ OSX මෙහෙයුම් පද්ධති යටතේ ක්‍රියාත්මක වේ. මම ලිනක්ස් යටතේ AMD64 ගෘහ නිර්මාණ ශිල්පය සඳහා පමණක් පරීක්ෂා කළ නමුත් එය ARM64, PPC64, MIPS64 සඳහා ක්රියා කළ යුතුය.
ප්රධාන ලක්ෂණ:
- බහු නූල්;
- Multiserver, දෝෂ ඉවසීම සහ බර සමතුලිත කිරීම සැපයීම;
- පරිශීලකයා හෝ සංවර්ධකයා සඳහා උපරිම විනිවිදභාවය;
- සහාය දක්වන HTTP ක්රම: GET, HEAD, PUT සහ DELETE;
- සේවාලාභී පාර්ශවීය ශීර්ෂ හරහා කියවීමේ සහ ලිවීමේ හැසිරීම කළමනාකරණය කිරීම;
- ඉහළ වින්‍යාසගත කළ හැකි අතථ්‍ය ධාරක සඳහා සහාය;
- ලිවීමේදී/කියවන විට CRC දත්ත අඛණ්ඩතාවට සහාය වීම;
- අවම මතක පරිභෝජනය සහ ප්‍රශස්ත ජාල කාර්ය සාධන සුසර කිරීම සඳහා අර්ධ ගතික බෆර;
- කල් දැමූ දත්ත සංයුක්ත කිරීම;
- මීට අමතරව, සේවාව නතර නොකර ගොනු සංක්‍රමණය කිරීම සඳහා බහු-නූල් ලේඛනාගාරයක් wZA පිරිනමනු ලැබේ.
සැබෑ අත්දැකීම:
මම සෑහෙන කාලයක් තිස්සේ සජීවී දත්ත මත සේවාදායකය සහ ලේඛනාගාරය සංවර්ධනය කර පරීක්ෂා කරමින් සිටිමි, දැන් එය වෙනම SATA ධාවකවල නාමාවලි 250,000,000 ක ඇති කුඩා ගොනු 15,000,000 (පින්තූර) ඇතුළත් පොකුරක් මත සාර්ථකව ක්‍රියාත්මක වේ. සේවාදායක 10 ක පොකුරක් යනු CDN ජාලයක් පිටුපස ස්ථාපනය කර ඇති Origin server එකකි. එය සේවය කිරීම සඳහා, 2 Nginx සේවාදායකයන් + 2 wZD සේවාදායකයන් භාවිතා කරනු ලැබේ.
මෙම සේවාදායකය භාවිතා කිරීමට තීරණය කරන අය සඳහා, භාවිතා කිරීමට පෙර, අදාළ නම්, නාමාවලි ව්‍යුහය සැලසුම් කිරීම නුවණට හුරුය. සේවාදායකය 1 බෝල්ට් ලේඛනාගාරයක් තුළට සියල්ල හිර කිරීමට අදහස් නොකරන බව මට වහාම වෙන් කරවා ගැනීමට ඉඩ දෙන්න.
කාර්ය සාධන පරීක්ෂණය:
සිප් කළ ගොනුවේ ප්‍රමාණය කුඩා වන තරමට එය මත GET සහ PUT මෙහෙයුම් වේගවත් වේ. HTTP සේවාලාභියා ලිවීමේ සම්පූර්ණ කාලය සාමාන්‍ය ලිපිගොනු සහ බෝල්ට් ලේඛනාගාරයට මෙන්ම කියවීමට සසඳමු. 32 KB, 256 KB, 1024 KB, 4096 KB සහ 32768 KB ප්රමාණයේ ගොනු සමඟ වැඩ කිරීම සැසඳේ.
බෝල්ට් ලේඛනාගාරය සමඟ වැඩ කරන විට, එක් එක් ගොනුවේ දත්ත අඛණ්ඩතාව පරීක්ෂා කරනු ලැබේ (CRC භාවිතා වේ), පටිගත කිරීමට පෙර සහ පටිගත කිරීමෙන් පසුව, පියාසර කියවීම සහ නැවත ගණනය කිරීම සිදු වේ, මෙය ස්වාභාවිකවම ප්‍රමාදයන් හඳුන්වා දෙයි, නමුත් ප්රධාන දෙය වන්නේ දත්ත ආරක්ෂාවයි.
SATA ධාවකවල පරීක්ෂණ පැහැදිලි වෙනසක් නොපෙන්වන බැවින් මම SSD ධාවකයන් මත කාර්ය සාධන පරීක්ෂණ සිදු කළෙමි.
පරීක්ෂණ ප්රතිඵල මත පදනම් වූ ප්රස්තාර:
ඔබට පෙනෙන පරිදි, කුඩා ගොනු සඳහා සංරක්ෂිත සහ සංරක්ෂිත නොවන ගොනු අතර කියවීමේ සහ ලිවීමේ වේලාවන්හි වෙනස කුඩා වේ.
32 MB ප්රමාණයේ ලිපිගොනු කියවීම සහ ලිවීම පරීක්ෂා කිරීමේදී අපට සම්පූර්ණයෙන්ම වෙනස් පින්තූරයක් ලැබේ:
ලිපිගොනු කියවීම අතර කාල වෙනස 5-25 ms අතර වේ. පටිගත කිරීම සමඟ, දේවල් වඩාත් නරක ය, වෙනස 150 ms පමණ වේ. නමුත් මෙම අවස්ථාවේ දී විශාල ගොනු උඩුගත කිරීම අවශ්ය නොවේ; එසේ කිරීමේ තේරුමක් නැත; ඔවුන්ට ලේඛනාගාරයෙන් වෙන්ව ජීවත් විය හැකිය.
*තාක්ෂණිකව, ඔබට NoSQL අවශ්ය කාර්යයන් සඳහා මෙම සේවාදායකය භාවිතා කළ හැක.
wZD සේවාදායකය සමඟ වැඩ කිරීමේ මූලික ක්රම:
සාමාන්‍ය ගොනුවක් පූරණය කරමින්:
curl -X PUT --data-binary @test.jpg http://localhost/test/test.jpgBolt සංරක්ෂිතයට ගොනුවක් උඩුගත කිරීම (සංරක්ෂිතයට ඇතුළත් කළ හැකි උපරිම ගොනු ප්‍රමාණය තීරණය කරන සේවාදායක පරාමිතිය 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