Komunitas sing dihormati, Artikel iki bakal fokus ing nyimpen lan njupuk atusan yuta file cilik kanthi efisien. Ing tahap iki, solusi pungkasan diusulake kanggo sistem file sing kompatibel karo POSIX kanthi dhukungan lengkap kanggo kunci, kalebu kunci kluster, lan katon tanpa kruk.
Dadi aku nulis server khususku dhewe kanggo tujuan iki.
Ing Course saka ngleksanakake tugas iki, kita ngatur kanggo ngatasi masalah utama, lan ing wektu sing padha entuk tabungan ing papan disk lan RAM, kang sistem file kluster iki mercilessly akeh. Bener, sawetara file kasebut mbebayani kanggo sistem file clustered.
Gagasane yaiku:
Ing tembung prasaja, file cilik diunggah liwat server, padha disimpen langsung menyang arsip, lan uga diwaca saka iku, lan file gedhe diselehake sisih dening sisih. Skema: 1 folder = 1 arsip, total kita duwe sawetara yuta arsip kanthi file cilik, lan ora sawetara atus yuta file. Lan kabeh iki ditindakake kanthi lengkap, tanpa skrip utawa nglebokake file menyang arsip tar / zip.
Aku bakal nyoba kanggo tetep cendhak, aku njaluk ngapura sadurunge yen kiriman dawa.
Iku kabeh diwiwiti kanthi nyatane aku ora bisa nemokake server sing cocok ing donya sing bisa nyimpen data sing ditampa liwat protokol HTTP langsung menyang arsip, tanpa kekurangan sing ana ing arsip konvensional lan panyimpenan obyek. Lan alasan telusuran yaiku kluster Asal saka 10 server sing wis berkembang dadi skala gedhe, ing ngendi 250,000,000 file cilik wis diklumpukake, lan tren pertumbuhan ora bakal mandheg.
Kanggo sing ora seneng maca artikel, dokumentasi sethithik luwih gampang:
и .
Lan docker ing wektu sing padha, saiki ana pilihan mung karo nginx ing njero:
docker run -d --restart=always -e host=localhost -e root=/var/storage
-v /var/storage:/var/storage --name wzd -p 80:80 eltaline/wzdSabanjure:
Yen ana akeh file, sumber daya sing signifikan dibutuhake, lan sing paling awon yaiku sawetara sing boroske. Contone, nalika nggunakake sistem file clustered (ing kasus iki, MooseFS), file, preduli saka ukuran nyata, tansah njupuk paling sethithik 64 KB. Sing, kanggo file ukuran 3, 10 utawa 30 KB, 64 KB dibutuhake ing disk. Yen ana seprapat milyar file, kita ilang saka 2 nganti 10 terabyte. Ora bakal bisa nggawe file anyar tanpa wates, amarga MooseFS duwe watesan: ora luwih saka 1 milyar kanthi siji replika saben file.
Nalika jumlah file mundhak, akeh RAM dibutuhake kanggo metadata. Kerep mbuwang metadata gedhe uga nyumbang kanggo nyandhang drive SSD.
server wZD. We sijine iku supaya ing disk.
Server ditulis ing Go. Kaping pisanan, aku kudu nyuda jumlah file. Carane nindakake? Amarga arsip, nanging ing kasus iki tanpa komprèsi, wiwit file sandi mung gambar teken. BoltDB teka kanggo ngluwari, sing isih kudu diilangi saka kekurangane, iki dibayangke ing dokumentasi.
Secara total, tinimbang seprapat milyar file, ing kasusku mung ana 10 yuta arsip Bolt. Yen aku duwe kesempatan kanggo ngganti struktur file direktori saiki, bisa dikurangi dadi kira-kira 1 yuta file.
Kabeh file cilik dikemas menyang arsip Bolt, sing kanthi otomatis nampa jeneng direktori sing ana, lan kabeh file gedhe tetep ing jejere arsip; ora ana gunane kanggo ngemas, iki bisa disesuaikan. Sing cilik diarsipake, sing gedhe ora diganti. Server dianggo transparan karo loro.
Arsitektur lan fitur saka server wZD.
Server beroperasi ing sistem operasi Linux, BSD, Solaris lan OSX. Aku mung dites kanggo arsitektur AMD64 ing Linux, nanging kudu bisa kanggo ARM64, PPC64, MIPS64.
Fitur utama:
- Multithreading;
- Multiserver, nyedhiyakake toleransi fault lan load balancing;
- Transparansi maksimal kanggo pangguna utawa pangembang;
- Cara HTTP sing didhukung: GET, HEAD, PUT lan DELETE;
- Kontrol prilaku maca lan nulis liwat header klien;
- Dhukungan kanggo host virtual fleksibel;
- Ndhukung integritas data CRC nalika nulis / maca;
- Buffer semi-dinamis kanggo konsumsi memori minimal lan tuning kinerja jaringan optimal;
- Kompaksi data sing ditundha;
- Kajaba iku, wZA archiver multi-threaded ditawakake kanggo migrasi file tanpa mungkasi layanan kasebut.
Pengalaman Nyata:
Aku wis ngembangake lan nguji server lan arsip ing data langsung kanggo wektu sing cukup suwe, saiki wis sukses ing kluster sing kalebu 250,000,000 file cilik (gambar) sing ana ing 15,000,000 direktori ing drive SATA sing kapisah. Kluster 10 server minangka server Asal sing diinstal ing mburi jaringan CDN. Kanggo layanan kasebut, 2 server Nginx + 2 server wZD digunakake.
Kanggo sing arep nggunakake server iki, iku bakal wicaksana kanggo rencana metu struktur direktori, yen ditrapake, sadurunge digunakake. Ayo kula nggawe leladen langsung sing server ora dimaksudaké kanggo cram kabeh menyang arsip 1 Bolt.
Tes kinerja:
Sing luwih cilik ukuran file zip, operasi GET lan PUT luwih cepet ditindakake. Ayo mbandhingake total wektu kanggo nulis klien HTTP menyang file biasa lan arsip Bolt, uga maca. Dibandhingake karo file ukuran 32 KB, 256 KB, 1024 KB, 4096 KB lan 32768 KB.
Nalika nggarap arsip Bolt, integritas data saben file dicenthang (CRC digunakake), sadurunge ngrekam lan uga sawise ngrekam, maca lan recalculation on-the-fly ana, iki kanthi alami ngenalake telat, nanging sing utama yaiku keamanan data.
Aku nganakake tes kinerja ing drive SSD, amarga tes ing drive SATA ora nuduhake prabédan sing jelas.
Grafik adhedhasar asil tes:
Nalika sampeyan bisa ndeleng, kanggo file cilik prabédan ing wektu maca lan nulis antarane file arsip lan non-arsip cilik.
Kita entuk gambar sing beda banget nalika nyoba maca lan nulis file kanthi ukuran 32 MB:
Bentenipun wektu antarane maca file ing 5-25 ms. Kanthi ngrekam, kahanan luwih elek, bedane kira-kira 150 ms. Nanging ing kasus iki ora perlu ngunggah file gedhe, mung ora ana gunane, bisa urip kanthi kapisah saka arsip.
* Secara teknis, sampeyan bisa nggunakake server iki kanggo tugas sing mbutuhake NoSQL.
Cara dhasar nggarap server wZD:
Loading file biasa:
curl -X PUT --data-binary @test.jpg http://localhost/test/test.jpgNgunggah file menyang arsip Bolt (yen parameter server fmaxsize, sing nemtokake ukuran file maksimal sing bisa dilebokake ing arsip, ora ngluwihi; yen ngluwihi, file kasebut bakal diunggah kaya biasane ing jejere arsip):
curl -X PUT -H "Archive: 1" --data-binary @test.jpg http://localhost/test/test.jpgNgundhuh file (yen ana file kanthi jeneng sing padha ing disk lan ing arsip, banjur nalika ndownload, prioritas diwenehi standar kanggo file sing ora diarsipake):
curl -o test.jpg http://localhost/test/test.jpgNgundhuh file saka arsip Bolt (dipeksa):
curl -o test.jpg -H "FromArchive: 1" http://localhost/test/test.jpgKatrangan cara liya ana ing dokumentasi.
Server saiki mung ndhukung protokol HTTP; durung bisa digunakake karo HTTPS. Cara POST uga ora didhukung (durung diputusake apa perlu utawa ora).
Sapa sing digali menyang kode sumber bakal nemokake butterscotch ana, ora kabeh wong seneng, nanging aku ora dasi kode utama kanggo fungsi saka framework web, kajaba handler interrupted, supaya ing mangsa aku bisa cepet nulis maneh kanggo meh wae. mesin.
ToDo:
- Pangembangan replikator lan distributor sampeyan dhewe + geo kanggo kemungkinan digunakake ing sistem gedhe tanpa sistem file kluster (Kabeh kanggo wong diwasa)
- Kemungkinan metadata mbalikke lengkap yen wis ilang (yen nggunakake distributor)
- Protokol asli kanggo kemampuan nggunakake sambungan jaringan lan driver sing terus-terusan kanggo macem-macem basa pamrograman
- Kemungkinan lanjut kanggo nggunakake komponen NoSQL
- Kompresi saka macem-macem jinis (gzip, zstd, snappy) kanggo file utawa nilai ing arsip Bolt lan kanggo file biasa
- Enkripsi macem-macem jinis file utawa nilai ing arsip Bolt lan file biasa
- Konversi video sisih server telat, kalebu ing GPU
Aku duwe kabeh, Mugi server iki bakal migunani kanggo wong, lisensi BSD-3, hak cipta pindho, awit yen ora ana perusahaan ngendi aku bisa, server ora bakal ditulis. Aku mung pangembang. Aku bakal ngucapke matur nuwun kanggo sembarang kewan omo lan panjalukan fitur sampeyan nemokake.
Source: www.habr.com