Rustā rakstīta objektu krātuve RustFS uz 4 KB objektiem apstrādā 2,3 reizes vairāk pieprasījumu nekā MinIO. Tas ir skaitlis, ko projekta komanda liek pašā GitHub apraksta pirmajā rindā, un tests ir mērīts uz apzināti vājas mašīnas — 2 procesora kodoli, 4 GB atmiņas, 15 Gb/s tīkls. Uz lieliem failiem attēls apgriežas otrādi, un tieši šī nianse padara RustFS interesantu.
RustFS ir S3 saderīga izkliedēta objektu krātuve ar Apache 2.0 licenci. To raksta kā tiešu alternatīvu MinIO — tam pašam rīkam, ko daudzas komandas pameta pēc 2021. gada, kad MinIO pārgāja uz AGPLv3 licenci. Kods ir gandrīz pilnībā Rustā (94,7 % repozitorija), un projekts jūlijā ir sasniedzis 30 000 zvaigžņu GitHub, ar 1 300 forkiem.
Kur RustFS ir ātrāks un kur ne
Mazie objekti ir RustFS stiprā puse. Papildus izstrādātāju 2,3x skaitlim to apstiprina arī neatkarīgi kopienas mērījumi. Salīdzinājumā ar warp rīku RustFS uz maziem failu ierakstiem sasniedza 4 472 rindas sekundē pret MinIO 2 845 rindām.
Bet uz lieliem sekvenciāliem lasījumiem MinIO paliek priekšā, un starpība nav maza. Testā ar 20 MiB objektiem MinIO deva aptuveni 53 Gb/s caurlaidspēju, RustFS — ap 23 Gb/s. Vēl krasāka atšķirība ir laikā līdz pirmajam baitam: MinIO atbild 24 milisekundēs, RustFS — 260. Tīra GET slodze arī nav RustFS labā: 6 819 objekti sekundē pret 2 259, tātad MinIO apkalpo aptuveni trīsreiz vairāk.
RustFS komanda šo caurumu neslēpj un ir ielikusi lielo failu optimizāciju ceļakartē. Praktiskā secinājumā tas nozīmē diezgan skaidru dalījumu: daudz mazu objektu ar augstu paralēlismu — RustFS priekšrocība; retāki, bet apjomīgi lejupielādes un straumēšanas darbi — MinIO joprojām vada.
Kāpēc licence ir galvenais arguments
Lielākajai daļai komandu pirmais jautājums nav ātrums, bet licence. MinIO 2021. gadā pārgāja no Apache 2.0 uz AGPLv3. AGPL prasa atklāt pirmkodu, ja programmatūru piedāvā kā tīkla servisu, un tas rada berzi mākoņu pakalpojumu sniedzējiem un komerciāliem produktiem, kas grib objektu krātuvi iebūvēt sevī bez pienākuma publicēt savas izmaiņas.
RustFS Apache 2.0 licence šo pienākumu noņem. Pirmkodu var modificēt un iebūvēt slēgtā produktā bez atklāšanas prasībām. Sealos raksts par RustFS to formulē tieši:
Komandām, kas pameta MinIO pēc pārejas uz AGPLv3, tas parasti ir pirmais, kas svarīgs.
Šeit jāpatur prātā, ka licence risina juridisku, nevis tehnisku problēmu. Ceph un SeaweedFS arī pastāv kā alternatīvas, taču tās nav S3 saderīgas tik tieši vai nav tik vieglas uz vājas dzelzs. RustFS mēģina apvienot MinIO vienkāršību ar Rusta atmiņas drošību un licenci, kas neuzliek copyleft slogu.
Pāreja arī nav visu vai neko. RustFS ir veidots tā, lai migrētu un līdzāspastāvētu ar citām S3 saderīgām platformām, tostarp MinIO un Ceph. Praktiski tas nozīmē, ka datus var pārcelt pakāpeniski un kādu laiku vecās un jaunās krātuves darbina paralēli, nevis vienā naktī pārmet visu produkciju uz beta versiju.
Kā tas uzbūvēts
RustFS izmanto erasure coding, nevis pilnu replikāciju. Trīskārša replikācija prasa 200 % papildu vietas, erasure coding tuvāk 50 %, tāpēc krātuve ir lētāka pie tā paša drošības līmeņa. Sistēmai nav centrāla metadatu servera: katrs mezgls glabā gan datus, gan metadatus, kas vajadzīgi pieprasījuma apkalpošanai, tāpēc nav vienas vietas, kuras krišana apturētu visu klasteri.
Zem pārsega strādā Tokio asinhronais izpildlaiks. Rustam nav atkritumu savākšanas, tāpēc nav arī neparedzamu pauzu, ko Go dzinējs reizēm ienes slodzes maksimumos. Tieši šī jitera prombūtne ir viens no iemesliem, kāpēc RustFS pozicionē sevi AI apmācības darba slodzēm, kur krātuves aizķeršanās var apturēt visu apmācības ciklu. Krātuve pati pārbauda kontrolsummas un atjauno bojātus fragmentus. S3 API klāt nāk arī OpenStack Swift atbalsts ar Keystone autentifikāciju.
Kopienas salīdzinājumā ar MinIO un SeaweedFS aina ir tāda pati kā mērījumos: neviens no trim nav uzvarētājs visos scenārijos. SeaweedFS ir spēcīgs uz milzīga skaita sīku failu, MinIO uz caurlaidspējas, RustFS uz mazu objektu operāciju ātruma un vājākas dzelzs. Izvēle beidzas ne pie labākā rīka, bet pie tā, kāda ir konkrētā slodze.
Ko tas nozīmē tagad
Versija ir v1.0.0-beta.10, un uzturētāji atklāti iesaka to vēl nelikt produkcijā, kamēr nav stabilā 1.0 laidiena. Tas ir godīgs brīdinājums, ko der ievērot: 30 000 zvaigžņu nav tas pats, kas gadiem noslīpēta krātuve zem reālas slodzes. MinIO joprojām ir nobriedušāks un ātrāks uz lieliem failiem.
Kam šo vērts izmēģināt jau tagad? Komandām, kurām AGPL ir šķērslis un slodze sastāv no daudziem maziem objektiem — piemēram, AI un datu ezera darba slodzēm ar milzumu mazu fragmentu. Kam labāk pagaidīt? Ražošanas sistēmām ar lielu sekvenciālu lasīšanu, kur 260 ms līdz pirmajam baitam ir par daudz. Kopienas atbildes ātrums ir labs — vidēji problēmas atrisina ātrāk nekā diennaktī — bet līdz brīdim, kad RustFS aizver lielo failu caurumu, izvēle paliek atkarīga no tā, kādi objekti plūst caur krātuvi.
Avoti
- RustFS repozitorijs GitHub
- Sealos: What Is RustFS? Apache 2.0 MinIO Alternative
- RustFS benchmark issue #2154 (warp mērījumi)
- RustFS discussion #1500: MinIO, SeaweedFS un RustFS salīdzinājums
Titulbildes pamatā: fotogrāfija „28TB” (autors jared), CC BY 2.0, Flickr; apstrādāta ar itn zīmola efektu.
Komentāri
Šim rakstam vēl nav komentāru. Esi pirmais, kurš dalās ar savu viedokli.