Binuksan ng PayPal ang source code ng fault-tolerant na DBMS JunoDB, na nagmamanipula ng data sa isang key-value na format. Ang system ay unang idinisenyo na may mataas na seguridad, pahalang na scalability, fault tolerance, at ang kakayahang pangasiwaan ang daan-daang libong magkakasabay na koneksyon na may nahuhulaang mga latency sa isip. Sa PayPal, halos lahat ng mga serbisyo, mula sa mga login ng user hanggang sa pagproseso ng mga transaksyong pinansyal, ay nakatali sa JunoDB. Ang project code ay nakasulat sa Go (isang Java client library) at ipinamamahagi sa ilalim ng Apache 2.0 na lisensya. Ang karagdagang pag-unlad ay tatanggap ng mga pagwawasto, pagpapahusay at pagbabago mula sa komunidad.
Ang arkitektura ng JunoDB ay batay sa paggamit ng isang load balancer na tumatanggap ng mga kahilingan mula sa mga application ng kliyente at ipinamamahagi ang mga ito sa mga proxy server na sabay-sabay na nag-a-access sa isang pangkat ng mga server ng imbakan kapag ang kahilingan ay naisakatuparan. Ang bawat proxy server ay nagtatatag ng mga koneksyon sa lahat ng mga server ng imbakan nang sabay-sabay at nagpapasa ng mga kahilingan sa isang pangkat ng mga server ng imbakan batay sa index ng partition, na nakaimbak sa distributed storage system etcd configuration.
Ang data ay nahahati at naka-link sa mga storage node gamit ang hashing, na nagpapababa sa paggalaw ng data habang lumalaki o lumiliit ang mga node sa cluster. Para matiyak ang fault tolerance, ang bawat piraso ng data ay ginagaya sa ilang storage node, na nagbibigay-daan sa iyong mag-save ng impormasyon kapag nabigo ang mga indibidwal na server. Ang paglikha ng mga imbakan na ipinamamahagi sa heograpiya ay sinusuportahan, kung saan ang mga pangkat ng mga node ay matatagpuan sa iba't ibang mga sentro ng data.
Sa mga node ng imbakan ng data, matatagpuan ang mga ito sa RAM o sa lokal na imbakan batay sa library ng RocksDB. Kapag permanenteng naka-imbak, ang data ay iniimbak sa naka-encrypt na anyo (ang encryption key ay maaaring matukoy ng kliyente o itakda sa antas ng proxy).
Upang ma-access ang database mula sa mga application, isang client library ang ibinibigay na nagbibigay ng API para sa mga application sa Java, Go at C++. Ang bahagi ng kliyente ay pinasimple hangga't maaari, at ang kumplikadong lohika at mga setting ay inililipat sa bahagi ng DBMS hangga't maaari. Ang pakikipag-ugnayan sa pagitan ng kliyente at ng balancer o proxy ay isinasagawa sa pamamagitan ng isang naka-encrypt na channel ng komunikasyon. Upang pamahalaan at magpadala ng mga kahilingan, maaari mong gamitin ang interface ng command line, na ginagaya ang lahat ng mga kakayahan ng client API.
Ang system ay idinisenyo upang iproseso ang mga kahilingan na may predictable na mababang latency, halimbawa, isang kumpol ng tatlong storage node at isang proxy, na nabuo mula sa n1-highmem-32 na kapaligiran (32 Intel Xeon 2.30GHz na CPU, 214G RAM at 450G SSD-based na storage) , ay nakapagbigay ng mga nakapirming pagkaantala na hindi hihigit sa 2.5 ms sa 95% ng mga kaso at 16 ms sa 99% kapag nagpoproseso ng 200 libong sabay-sabay na koneksyon sa TLS at isang daloy ng 15 libong kahilingan bawat segundo (na may 3000 sabay-sabay na koneksyon at daloy ng 80 libong kahilingan bawat segundo, ang mga pagkaantala ay hindi lalampas sa 6 ms sa 95% ng mga kaso at 15 ms sa 99%). Sa PayPal, ang mga serbisyong nakabatay sa JunoDB ay naghahatid ng humigit-kumulang 350 bilyong kahilingan bawat araw.
Pinagmulan: opennet.ru