Tallenna tehokkaasti satoja miljoonia pieniä tiedostoja. Itseisännöity ratkaisu

Hyvä yhteisö, Tämä artikkeli keskittyy satojen miljoonien pienten tiedostojen tehokkaaseen tallentamiseen ja hakemiseen. Tässä vaiheessa ehdotetaan lopullista ratkaisua POSIX-yhteensopiville tiedostojärjestelmille, joissa on täysi tuki lukkoille, mukaan lukien klusterilukot, ja näennäisesti jopa ilman kainalosauvoja.

Joten kirjoitin oman mukautetun palvelimeni tätä tarkoitusta varten.
Tätä tehtävää toteutettaessa onnistuimme ratkaisemaan pääongelman ja saavuttamaan samalla levytilan ja RAM-muistin säästöjä, joita klusteritiedostojärjestelmämme kulutti armottomasti. Itse asiassa tällainen tiedostomäärä on haitallinen mille tahansa klusteroidulle tiedostojärjestelmälle.

Idea on tämä:

Yksinkertaisesti sanottuna pienet tiedostot ladataan palvelimen kautta, ne tallennetaan suoraan arkistoon ja myös luetaan siitä, ja suuret tiedostot asetetaan vierekkäin. Kaava: 1 kansio = 1 arkisto, yhteensä meillä on useita miljoonia arkistoja pieniä tiedostoja, ei useita satoja miljoonia tiedostoja. Ja kaikki tämä toteutetaan täysin ilman komentosarjoja tai tiedostojen laittamista tar/zip-arkistoon.

Yritän pitää sen lyhyenä, pahoittelen jo etukäteen, jos postaus on pitkä.

Kaikki alkoi siitä, että en löytänyt maailmasta sopivaa palvelinta, joka voisi tallentaa HTTP-protokollan kautta vastaanotettuja tietoja suoraan arkistoon ilman tavanomaisten arkistointien ja objektien varastointiin liittyviä haittoja. Ja syynä hakuun oli suureksi kasvanut 10 palvelimen Origin-klusteri, johon oli kertynyt jo 250,000,000 XNUMX XNUMX pientä tiedostoa, eikä kasvutrendi pysähdy.

Niille, jotka eivät pidä artikkeleiden lukemisesta, pieni dokumentointi on helpompaa:

täällä и täällä.

Ja docker samaan aikaan, nyt on vaihtoehto vain nginxin kanssa varmuuden vuoksi:

docker run -d --restart=always -e host=localhost -e root=/var/storage 
-v /var/storage:/var/storage --name wzd -p 80:80 eltaline/wzd

Seuraava:

Jos tiedostoja on paljon, tarvitaan merkittäviä resursseja, ja pahinta on, että osa niistä menee hukkaan. Esimerkiksi käytettäessä klusteroitua tiedostojärjestelmää (tässä tapauksessa MooseFS) tiedosto vie todellisesta koostaan ​​riippumatta aina vähintään 64 kt. Toisin sanoen 3, 10 tai 30 kt:n tiedostoille levylle vaaditaan 64 kt. Jos tiedostoja on neljäsosa miljardia, menetämme 2–10 teratavua. Uusia tiedostoja ei voi luoda loputtomiin, koska MooseFS:llä on rajoitus: enintään 1 miljardi kustakin tiedostosta yhdellä kopiolla.

Kun tiedostojen määrä kasvaa, metatietoihin tarvitaan paljon RAM-muistia. Usein esiintyvät suuret metatietojen tyhjennykset lisäävät myös SSD-asemien kulumista.

wZD-palvelin. Laitamme asiat järjestykseen levyillä.

Palvelin on kirjoitettu Go-kielellä. Ensinnäkin minun piti vähentää tiedostojen määrää. Kuinka tehdä se? Arkistoinnin takia, mutta tässä tapauksessa ilman pakkausta, koska tiedostoni ovat vain pakattuja kuvia. BoltDB tuli apuun, joka oli vielä poistettava puutteistaan, tämä näkyy dokumentaatiossa.

Yhteensä neljäsosan miljardin tiedoston sijaan minun tapauksessani oli jäljellä vain 10 miljoonaa Bolt-arkistoa. Jos minulla olisi mahdollisuus muuttaa nykyistä hakemistotiedostorakennetta, se olisi mahdollista pienentää noin 1 miljoonaan tiedostoon.

Kaikki pienet tiedostot pakataan Bolt-arkistoon, joka vastaanottaa automaattisesti niiden hakemistojen nimet, joissa ne sijaitsevat, ja kaikki suuret tiedostot jäävät arkistojen viereen; niitä on turha pakata, tämä on muokattavissa. Pienet arkistoidaan, suuret jätetään ennalleen. Palvelin toimii läpinäkyvästi molempien kanssa.

wZD-palvelimen arkkitehtuuri ja ominaisuudet.

Palvelin toimii Linux-, BSD-, Solaris- ja OSX-käyttöjärjestelmillä. Testasin vain AMD64-arkkitehtuuria Linuxissa, mutta sen pitäisi toimia ARM64:ssä, PPC64:ssä, MIPS64:ssä.

Pääpiirteet:

• Monisäikeinen;
• Monipalvelin, joka tarjoaa vikasietoisuuden ja kuormituksen tasapainotuksen;
• Maksimaalinen läpinäkyvyys käyttäjälle tai kehittäjälle;
• Tuetut HTTP-menetelmät: GET, HEAD, PUT ja DELETE;
• Luku- ja kirjoituskäyttäytymisen hallinta asiakasotsikoiden kautta;
• Joustavien virtuaalisten isäntien tuki;
• Tukee CRC-tietojen eheyttä kirjoitettaessa/lukeessa;
• Puolidynaamiset puskurit minimaaliseen muistinkulutukseen ja optimaaliseen verkon suorituskyvyn viritykseen;
• Viivästetty tietojen pakkaaminen;
• Lisäksi tarjolla on monisäikeinen arkistointi wZA tiedostojen siirtämiseen ilman palvelun pysäyttämistä.

Todellinen kokemus:

Olen kehittänyt ja testannut palvelinta ja arkistaattoria livedatalla melko pitkään, nyt se toimii menestyksekkäästi klusterissa, joka sisältää 250,000,000 15,000,000 10 pientä tiedostoa (kuvaa), jotka sijaitsevat 2 2 XNUMX hakemistossa erillisillä SATA-asemilla. XNUMX palvelimen klusteri on CDN-verkon taakse asennettu Origin-palvelin. Sen huoltamiseen käytetään XNUMX Nginx-palvelinta + XNUMX wZD-palvelinta.

Niiden, jotka päättävät käyttää tätä palvelinta, olisi viisasta suunnitella hakemistorakenne tarvittaessa ennen käyttöä. Haluan tehdä varauksen heti, että palvelimen ei ole tarkoitus tukkia kaikkea 1 Bolt -arkistoon.

Suorituskykytestaus:

Mitä pienempi pakatun tiedoston koko on, sitä nopeammin GET- ja PUT-toiminnot suoritetaan sille. Verrataan HTTP-asiakkaan kirjoittamisen kokonaisaikaa tavallisiin tiedostoihin ja Bolt-arkistoon sekä lukemiseen. Verrataan työskentelyä 32 kt, 256 kt, 1024 kt, 4096 kt ja 32768 kt tiedostojen kanssa.

Bolt-arkistojen kanssa työskennellessä jokaisen tiedoston tietojen eheys tarkistetaan (CRC on käytössä), ennen tallennusta ja myös tallennuksen jälkeen tapahtuu lennossa lukemista ja uudelleenlaskentaa, mikä luonnollisesti aiheuttaa viiveitä, mutta pääasia on tietoturva.

Tein suorituskykytestejä SSD-asemille, koska SATA-asemien testit eivät osoita selvää eroa.

Kaaviot, jotka perustuvat testituloksiin:

Kuten näet, pienten tiedostojen luku- ja kirjoitusajoissa ero arkistoitujen ja ei-arkistoitujen tiedostojen välillä on pieni.

Saamme täysin erilaisen kuvan, kun testataan 32 MB:n kokoisia luku- ja kirjoitustiedostoja:

Aikaero tiedostojen lukemisen välillä on 5-25 ms. Nauhoituksen kanssa asiat ovat huonommin, ero on noin 150 ms. Mutta tässä tapauksessa ei ole tarvetta ladata suuria tiedostoja, ei yksinkertaisesti ole mitään järkeä tehdä niin, ne voivat elää erillään arkistoista.

*Teknisesti voit käyttää tätä palvelinta tehtäviin, jotka vaativat NoSQL:n.

Perusmenetelmät wZD-palvelimen kanssa työskentelemiseen:

Tavallisen tiedoston lataaminen:

curl -X PUT --data-binary @test.jpg http://localhost/test/test.jpg

Tiedoston lataaminen Bolt-arkistoon (jos palvelinparametria fmaxsize, joka määrittää arkistoon sisällytettävän tiedoston enimmäiskoon, ei ylitetä; jos se ylitetään, tiedosto ladataan tavalliseen tapaan arkiston viereen):

curl -X PUT -H "Archive: 1" --data-binary @test.jpg http://localhost/test/test.jpg

Tiedoston lataaminen (jos levyllä ja arkistossa on samannimisiä tiedostoja, niin latauksen aikana etusija annetaan oletusarvoisesti arkistoitumattomalle tiedostolle):

curl -o test.jpg http://localhost/test/test.jpg

Tiedoston lataaminen Bolt-arkistosta (pakotettu):

curl -o test.jpg -H "FromArchive: 1" http://localhost/test/test.jpg

Muiden menetelmien kuvaukset ovat dokumentaatiossa.

wZD-dokumentaatio
wZA-dokumentaatio

Palvelin tukee tällä hetkellä vain HTTP-protokollaa, se ei vielä toimi HTTPS:n kanssa. Myöskään POST-menetelmää ei tueta (ei ole vielä päätetty, tarvitaanko sitä vai ei).

Se joka kaivautuu lähdekoodiin, löytää sieltä butterscotchin, kaikki eivät pidä siitä, mutta en sido pääkoodia verkkokehyksen toimintoihin, paitsi keskeytyskäsittelijää, joten voin jatkossa kirjoittaa sen nopeasti uudelleen melkein mille tahansa moottori.

Tehtävät:

• Oman replikaattorin ja jakelijan kehittäminen + geo mahdollista käyttöä varten suurissa järjestelmissä ilman klusteritiedostojärjestelmiä (kaikki aikuisille)
• Mahdollisuus palauttaa metatiedot kokonaan käänteisesti, jos ne katoavat kokonaan (jos käytetään jakelijaa)
• Natiiviprotokolla, jolla voidaan käyttää pysyviä verkkoyhteyksiä ja ohjaimia eri ohjelmointikielille
• Edistyneet mahdollisuudet NoSQL-komponentin käyttöön
• Erityyppiset pakkaukset (gzip, zstd, snappy) Bolt-arkistojen tiedostoille tai arvoille ja tavallisille tiedostoille
• Erityyppisten tiedostojen tai arvojen salaus Bolt-arkistojen sisällä ja tavallisille tiedostoille
• Viivästynyt palvelinpuolen videomuunnos, myös GPU:ssa

Minulla on kaikki, toivottavasti tästä palvelimesta on jollekin hyötyä, BSD-3-lisenssi, kaksinkertainen tekijänoikeus, koska jos ei olisi yritystä missä työskentelen, palvelinta ei olisi kirjoitettu. Olen ainoa kehittäjä. Olisin kiitollinen kaikista löytämistäsi virheistä ja ominaisuuspyynnöistä.

Lähde: will.com