PayPal het die bronkode van die foutverdraagsame DBMS JunoDB oopgemaak, wat data in 'n sleutelwaarde-formaat manipuleer. Die stelsel is aanvanklik ontwerp met hoë sekuriteit, horisontale skaalbaarheid, fouttoleransie en die vermoë om honderde duisende gelyktydige verbindings te hanteer met voorspelbare vertragings in gedagte. By PayPal is byna alle dienste, van gebruikersaanmeldings tot die verwerking van finansiële transaksies, aan JunoDB gekoppel. Die projekkode is geskryf in Go ('n Java-kliëntbiblioteek) en word onder die Apache 2.0-lisensie versprei. Verdere ontwikkeling sal regstellings, verbeterings en veranderinge van die gemeenskap aanvaar.
JunoDB se argitektuur is gebaseer op die gebruik van 'n lasbalanseerder wat versoeke van kliënttoepassings aanvaar en dit versprei onder proxy-bedieners wat gelyktydig toegang tot 'n groep ... verkry. bedieners berging wanneer 'n versoek uitgevoer word. Elke instaanbediener vestig verbindings met almal gelyktydig. bedieners berging en roeteer versoeke na 'n groep bergingsbedieners gebaseer op 'n partisie-indeks wat in die etcd verspreide konfigurasiebergingstelsel gestoor is.
Data word gepartisioneer en aan stoornodusse gekoppel deur gebruik te maak van hashing, wat databeweging verminder namate nodusse in die groep groei of krimp. Om fouttoleransie te verseker, word elke stuk data op verskeie stoornodusse gerepliseer, wat jou toelaat om inligting te stoor wanneer individuele bedieners misluk. Die skepping van geografies verspreide bergings word ondersteun, waarin groepe nodusse in verskillende datasentrums geleë is.
Op data stoor nodusse is hulle geleë in RAM of in plaaslike berging gebaseer op die RocksDB biblioteek. Wanneer dit permanent gestoor word, word die data in geënkripteerde vorm gestoor (die enkripsiesleutel kan óf deur die kliënt bepaal word óf op die proxy-vlak gestel word).
Om toegang tot die databasis vanaf toepassings te verkry, word 'n kliëntbiblioteek verskaf wat 'n API vir toepassings in Java, Go en C++ verskaf. Die kliëntdeel word soveel as moontlik vereenvoudig, en komplekse logika en instellings word waar moontlik na die DBMS-kant oorgedra. Die interaksie tussen die kliënt en die balanseerder of gevolmagtigde word deur 'n geënkripteerde kommunikasiekanaal uitgevoer. Om versoeke te bestuur en te stuur, kan u die opdragreël-koppelvlak gebruik, wat al die vermoëns van die kliënt-API herhaal.
Die stelsel is ontwerp om versoeke met voorspelbare lae vertragings te verwerk, byvoorbeeld 'n groep van drie stoornodusse en een instaanbediener, gevorm uit n1-highmem-32-omgewings (32 Intel Xeon 2.30GHz SVE's, 214G RAM en 450G SSD-gebaseerde berging) , was in staat om vaste vertragings van nie meer as 2.5 ms in 95% van die gevalle en 16 ms in 99% te verskaf wanneer 200 duisend gelyktydige TLS-verbindings en 'n vloei van 15 duisend versoeke per sekonde verwerk is (met 3000 80 gelyktydige verbindings en 'n vloei van 6 duisend versoeke) per sekonde het vertragings in 95% van gevalle nie 15 ms oorskry nie en in 99% 350 ms. By PayPal bedien JunoDB-gebaseerde dienste ongeveer XNUMX miljard versoeke per dag.
Bron: opennet.ru
