Minamahal na Komunidad, Ang artikulong ito ay tumutuon sa mahusay na pag-iimbak at pagkuha ng daan-daang milyong maliliit na file. Sa yugtong ito, ang pangwakas na solusyon ay iminungkahi para sa POSIX-compatible na mga file system na may ganap na suporta para sa mga lock, kabilang ang mga cluster lock, at tila kahit na walang saklay.
Kaya sinulat ko ang sarili kong pasadyang server para sa layuning ito.
Sa kurso ng pagpapatupad ng gawaing ito, nagawa naming lutasin ang pangunahing problema, at sa parehong oras makamit ang mga pagtitipid sa puwang sa disk at RAM, na walang awa na ginagamit ng aming cluster file system. Sa totoo lang, ang ganitong bilang ng mga file ay nakakapinsala para sa anumang clustered file system.
Ang ideya ay ito:
Sa mga simpleng salita, ang mga maliliit na file ay na-upload sa pamamagitan ng server, sila ay nai-save nang direkta sa archive, at binabasa din mula dito, at ang mga malalaking file ay inilalagay nang magkatabi. Scheme: 1 folder = 1 archive, sa kabuuan mayroon kaming ilang milyong mga archive na may maliliit na file, at hindi ilang daang milyong mga file. At ang lahat ng ito ay ganap na ipinatupad, nang walang anumang mga script o paglalagay ng mga file sa tar/zip archive.
Iβll try to keep it short, I apologize in advance kung mahaba ang post.
Nagsimula ang lahat sa katotohanang wala akong mahanap na angkop na server sa mundo na makakapag-save ng data na natanggap sa pamamagitan ng HTTP protocol nang direkta sa mga archive, nang walang mga disadvantages na likas sa mga conventional archive at object storage. At ang dahilan ng paghahanap ay ang Origin cluster ng 10 server na lumaki sa isang malaking sukat, kung saan 250,000,000 na maliliit na file ang naipon na, at ang trend ng paglago ay hindi titigil.
Para sa mga hindi gustong magbasa ng mga artikulo, mas madali ang kaunting dokumentasyon:
ΠΈ .
At docker sa parehong oras, ngayon ay may isang pagpipilian lamang sa nginx sa loob kung sakali:
docker run -d --restart=always -e host=localhost -e root=/var/storage
-v /var/storage:/var/storage --name wzd -p 80:80 eltaline/wzdSusunod:
Kung mayroong maraming mga file, kailangan ang mga makabuluhang mapagkukunan, at ang pinakamasamang bahagi ay ang ilan sa mga ito ay nasasayang. Halimbawa, kapag gumagamit ng isang clustered file system (sa kasong ito, MooseFS), ang file, anuman ang aktwal na laki nito, ay palaging tumatagal ng hindi bababa sa 64 KB. Iyon ay, para sa mga file na 3, 10 o 30 KB ang laki, 64 KB ang kinakailangan sa disk. Kung mayroong isang-kapat ng isang bilyong file, mawawala tayo mula 2 hanggang 10 terabytes. Hindi magiging posible na lumikha ng mga bagong file nang walang katiyakan, dahil ang MooseFS ay may limitasyon: hindi hihigit sa 1 bilyon na may isang kopya ng bawat file.
Habang dumarami ang mga file, maraming RAM ang kailangan para sa metadata. Ang madalas na malalaking metadata dump ay nakakatulong din sa pagkasira ng mga SSD drive.
wZD server. Inayos namin ang mga bagay sa mga disk.
Ang server ay nakasulat sa Go. Una sa lahat, kailangan kong bawasan ang bilang ng mga file. Paano ito gagawin? Dahil sa pag-archive, ngunit sa kasong ito nang walang compression, dahil ang aking mga file ay mga naka-compress na larawan lamang. Ang BoltDB ay dumating upang iligtas, na kailangan pa ring alisin mula sa mga pagkukulang nito, ito ay makikita sa dokumentasyon.
Sa kabuuan, sa halip na isang-kapat ng isang bilyong mga file, sa aking kaso ay mayroon lamang 10 milyong mga archive ng Bolt na natitira. Kung magkakaroon ako ng pagkakataong baguhin ang kasalukuyang istraktura ng file ng direktoryo, posibleng bawasan ito sa humigit-kumulang 1 milyong mga file.
Ang lahat ng maliliit na file ay naka-pack sa mga archive ng Bolt, na awtomatikong natatanggap ang mga pangalan ng mga direktoryo kung saan sila matatagpuan, at ang lahat ng malalaking file ay nananatili sa tabi ng mga archive; walang saysay na i-pack ang mga ito, ito ay nako-customize. Ang mga maliliit ay naka-archive, ang mga malalaki ay hindi nababago. Ang server ay gumagana nang malinaw sa pareho.
Arkitektura at mga tampok ng wZD server.
Ang server ay tumatakbo sa ilalim ng Linux, BSD, Solaris at OSX operating system. Sinubukan ko lang para sa arkitektura ng AMD64 sa ilalim ng Linux, ngunit dapat itong gumana para sa ARM64, PPC64, MIPS64.
Pangunahing tampok:
- Multithreading;
- Multiserver, nagbibigay ng fault tolerance at load balancing;
- Pinakamataas na transparency para sa user o developer;
- Mga sinusuportahang pamamaraan ng HTTP: GET, HEAD, PUT at DELETE;
- Kontrolin ang pag-uugali sa pagbabasa at pagsulat sa pamamagitan ng mga header ng kliyente;
- Suporta para sa nababaluktot na virtual host;
- Suportahan ang integridad ng data ng CRC kapag nagsusulat/nagbabasa;
- Mga semi-dynamic na buffer para sa minimal na pagkonsumo ng memorya at pinakamainam na pag-tune ng pagganap ng network;
- Ipinagpaliban ang compaction ng data;
- Bilang karagdagan, ang isang multi-threaded archiver wZA ay inaalok para sa paglipat ng mga file nang hindi humihinto sa serbisyo.
Tunay na Karanasan:
Matagal ko nang binuo at sinusubok ang server at archiver sa live na data, ngayon ay matagumpay itong nagpapatakbo sa isang kumpol na kinabibilangan ng 250,000,000 maliliit na file (mga larawan) na matatagpuan sa 15,000,000 na mga direktoryo sa magkahiwalay na SATA drive. Ang isang cluster ng 10 server ay isang Origin server na naka-install sa likod ng isang CDN network. Para maserbisyuhan ito, 2 Nginx server + 2 wZD server ang ginagamit.
Para sa mga nagpasya na gamitin ang server na ito, makabubuting planuhin ang istraktura ng direktoryo, kung naaangkop, bago gamitin. Hayaan akong magpareserba kaagad na hindi nilayon ng server na isiksik ang lahat sa isang 1 Bolt archive.
Subukan ang performance:
Kung mas maliit ang laki ng naka-zip na file, mas mabilis na ginagawa ang GET at PUT na mga operasyon dito. Ihambing natin ang kabuuang oras para sa pagsusulat ng HTTP client sa mga regular na file at mga archive ng Bolt, pati na rin ang pagbabasa. Paggawa gamit ang mga file na may sukat na 32 KB, 256 KB, 1024 KB, 4096 KB at 32768 KB ang inihambing.
Kapag nagtatrabaho sa mga archive ng Bolt, ang integridad ng data ng bawat file ay nasuri (ginamit ang CRC), bago mag-record at pagkatapos din ng pag-record, nangyayari ang on-the-fly na pagbabasa at muling pagkalkula, natural itong nagpapakilala ng mga pagkaantala, ngunit ang pangunahing bagay ay ang seguridad ng data.
Nagsagawa ako ng mga pagsubok sa pagganap sa mga SSD drive, dahil ang mga pagsubok sa mga SATA drive ay hindi nagpapakita ng malinaw na pagkakaiba.
Mga graph batay sa mga resulta ng pagsubok:
Tulad ng nakikita mo, para sa maliliit na file ang pagkakaiba sa mga oras ng pagbasa at pagsulat sa pagitan ng mga naka-archive at hindi naka-archive na mga file ay maliit.
Nakakakuha kami ng ganap na kakaibang larawan kapag sinusubukan ang pagbabasa at pagsusulat ng mga file na 32 MB ang laki:
Ang pagkakaiba sa oras sa pagitan ng pagbabasa ng mga file ay nasa loob ng 5-25 ms. Sa pag-record, ang mga bagay ay mas masahol pa, ang pagkakaiba ay tungkol sa 150 ms. Ngunit sa kasong ito ay hindi na kailangang mag-upload ng malalaking file; walang saysay na gawin ito; maaari silang mamuhay nang hiwalay sa mga archive.
*Sa teknikal, maaari mong gamitin ang server na ito para sa mga gawaing nangangailangan ng NoSQL.
Mga pangunahing paraan ng pagtatrabaho sa wZD server:
Naglo-load ng regular na file:
curl -X PUT --data-binary @test.jpg http://localhost/test/test.jpgAng pag-upload ng file sa Bolt archive (kung ang server parameter fmaxsize, na tumutukoy sa maximum na laki ng file na maaaring isama sa archive, ay hindi lalampas; kung ito ay lumampas, ang file ay ia-upload gaya ng dati sa tabi ng archive):
curl -X PUT -H "Archive: 1" --data-binary @test.jpg http://localhost/test/test.jpgPag-download ng isang file (kung mayroong mga file na may parehong mga pangalan sa disk at sa archive, pagkatapos ay kapag nagda-download, ang priyoridad ay binibigyan ng default sa hindi naka-archive na file):
curl -o test.jpg http://localhost/test/test.jpgNagda-download ng file mula sa Bolt archive (sapilitang):
curl -o test.jpg -H "FromArchive: 1" http://localhost/test/test.jpgAng mga paglalarawan ng iba pang mga pamamaraan ay nasa dokumentasyon.
Kasalukuyang sinusuportahan lamang ng server ang HTTP protocol; hindi pa ito gumagana sa HTTPS. Ang pamamaraan ng POST ay hindi rin suportado (hindi pa napagpasyahan kung kailangan o hindi).
Ang sinumang maghukay sa source code ay makakahanap ng butterscotch doon, hindi lahat ay nagustuhan ito, ngunit hindi ko itinali ang pangunahing code sa mga pag-andar ng web framework, maliban sa interrupt handler, kaya sa hinaharap maaari ko itong mabilis na muling isulat para sa halos anumang makina.
ToDo:
- Pag-develop ng iyong sariling replicator at distributor + geo para sa posibilidad na magamit sa malalaking system na walang mga cluster file system (Lahat para sa mga nasa hustong gulang)
- Posibilidad ng kumpletong reverse recovery ng metadata kung ito ay ganap na nawala (kung gumagamit ng isang distributor)
- Native protocol para sa kakayahang gumamit ng patuloy na koneksyon sa network at mga driver para sa iba't ibang programming language
- Mga advanced na posibilidad para sa paggamit ng bahagi ng NoSQL
- Mga compression ng iba't ibang uri (gzip, zstd, snappy) para sa mga file o value sa loob ng mga archive ng Bolt at para sa mga regular na file
- Pag-encrypt ng iba't ibang uri para sa mga file o halaga sa loob ng mga archive ng Bolt at para sa mga regular na file
- Naantala ang conversion ng video sa gilid ng server, kasama ang GPU
Mayroon akong lahat, umaasa ako na ang server na ito ay magiging kapaki-pakinabang sa isang tao, lisensya ng BSD-3, dobleng copyright, dahil kung walang kumpanya kung saan ako nagtatrabaho, ang server ay hindi naisulat. Ako lang ang nag-develop. Magpapasalamat ako para sa anumang mga bug at mga kahilingan sa tampok na makikita mo.
Pinagmulan: www.habr.com