Ang PayPal ay may open-sourced na JunoDB, isang fault-tolerant database management system na namamahala ng key-value data. Ang system ay dinisenyo mula sa simula para sa mataas na seguridad, pahalang na scalability, fault tolerance, at ang kakayahang pangasiwaan ang daan-daang libong magkakasabay na koneksyon na may predictable latency. Halos lahat ng mga serbisyo ng PayPal, mula sa pag-login ng user hanggang sa pagproseso ng transaksyong pinansyal, ay umaasa sa JunoDB. Ang code ng proyekto ay nakasulat sa Go (na may isang Java client library) at may lisensya sa ilalim ng Apache 2.0 na lisensya. Kasama sa karagdagang pag-unlad ang 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 aplikasyon ng kliyente at ipinamamahagi ang mga ito sa mga proxy server na sabay-sabay na nag-a-access sa isang grupo ng mga... mga server imbakan kapag isinasagawa ang isang kahilingan. Ang bawat proxy server ay nagtatatag ng mga koneksyon sa lahat ng mga ito nang sabay-sabay. mga server nagruruta ng mga kahilingan sa imbakan at nagruruta sa isang grupo ng mga storage server batay sa isang partitioning index na nakaimbak sa etcd distributed configuration storage system.
Ang data ay nahahati at itinalaga sa mga storage node gamit ang hashing, na binabawasan ang paggalaw ng data kapag ang mga node sa isang cluster ay pinalawak o nababawasan. Para matiyak ang fault tolerance, ang bawat bahagi ng data ay ginagaya sa maraming storage node, na pinapanatili ang impormasyon kahit na nabigo ang mga indibidwal na server. Ang mga sistema ng imbakan na ipinamahagi sa heograpiya ay sinusuportahan, na may mga pangkat ng mga node na matatagpuan sa iba't ibang mga sentro ng data.
Ang data ay nakaimbak sa mga storage node sa RAM o sa lokal na storage gamit ang RocksDB library. Para sa patuloy na imbakan, ang data ay naka-imbak na naka-encrypt (ang encryption key ay maaaring tukuyin ng kliyente o i-configure sa antas ng proxy).
Upang ma-access ang database mula sa mga application, isang client library ang ibinigay, na nagbibigay ng API para sa mga application na nakasulat sa Java, Go, at C++. Ang panig ng kliyente ay pinasimple hangga't maaari, na may kumplikadong lohika at mga setting na inilipat sa bahagi ng DBMS hangga't maaari. Ang komunikasyon sa pagitan ng kliyente at ng load balancer o proxy ay isinasagawa sa pamamagitan ng isang naka-encrypt na channel ng komunikasyon. Ang interface ng command-line, na ginagaya ang lahat ng kakayahan ng client API, ay maaaring gamitin para sa pamamahala at pagpapadala ng mga kahilingan.
Ang system ay idinisenyo upang iproseso ang mga kahilingan na may predictable na mababang latency. Halimbawa, ang isang kumpol ng tatlong storage node at isang proxy, na nabuo mula sa n1-highmem-32 na kapaligiran (32 Intel Xeon 2.30GHz na mga CPU, 214G RAM, at 450G SSD storage), ay nakapagbigay ng mga nakapirming latency na hindi hihigit sa 2.5 ms sa 95% ng mga kaso at 16 ms sa 200% ng magkasabay na mga kaso, kapag nagpoproseso ng TLS at magkasabay na mga kaso, 80% ng mga kaso. ng 15 kahilingan sa bawat segundo (na may 3000 kasabay na koneksyon at daloy ng 99 kahilingan bawat segundo, ang mga latency ay hindi lalampas sa 6 ms sa 95% ng mga kaso at 15 ms sa 99%). Ang mga serbisyong nakabatay sa JunoDB ng PayPal ay humahawak ng humigit-kumulang 350 bilyong kahilingan bawat araw.
Pinagmulan: opennet.ru
