La société PayPal a publié le code source de sa base de données résiliente JunoDB, qui manipule les données au format clé-valeur. Le système a été initialement conçu en tenant compte d'une grande sécurité, d'une évolutivité horizontale, d'une résilience et de la capacité à gérer des centaines de milliers de connexions simultanées avec des latences prévisibles. Chez PayPal, presque tous les services, de l'authentification des utilisateurs à la gestion des transactions financières, dépendent de JunoDB. Le code du projet est écrit en Go (avec une bibliothèque cliente en Java) et est distribué sous licence Apache 2.0. Lors des développements futurs, les corrections, améliorations et modifications de la communauté seront acceptées.
L'architecture de JunoDB repose sur un équilibreur de charge qui reçoit les requêtes des applications clientes et les répartit entre plusieurs serveurs proxy, qui accèdent simultanément à un groupe serveurs de stockage lors du traitement d'une requête. Chaque serveur proxy établit des connexions avec tous les serveurs très chargés serveurs de stockage et redirige les requêtes vers le groupe de serveurs de stockage en fonction d'un index de partitionnement, qui est stocké dans un système de stockage distribué de configuration etcd.
Les données sont partitionnées et associées aux nœuds de stockage à l'aide de hachage, ce qui réduit le déplacement des données lors de l'ajout ou de la suppression de nœuds dans le cluster. Pour garantir la résilience, chaque portion de données est répliquée sur plusieurs nœuds de stockage, ce qui permet de conserver l'information en cas de panne de certains serveurs. La création de stockages répartis géographiquement est prise en charge, où des groupes de nœuds sont situés dans différents centres de données.
Sur les nœuds de stockage, les données sont placées en mémoire vive ou dans un stockage local basé sur la bibliothèque RocksDB. Pour le stockage permanent, les données sont stockées sous forme chiffrée (la clé de chiffrement peut être déterminée à la fois par le client et définie au niveau du proxy).
Pour accéder à la base de données depuis des applications, une bibliothèque cliente est fournie, offrant une API pour des applications dans les langages Java, Go et C++. La partie cliente est simplifiée au maximum, tandis que la logique complexe et les paramètres sont, dans la mesure du possible, transférés vers le SGBD. L'interaction entre le client et le répartiteur de charge ou le proxy se fait via un canal de communication chiffré. Pour gérer et envoyer des requêtes, on peut utiliser une interface en ligne de commande qui reproduit toutes les fonctionnalités de l'API cliente.
Le système est conçu pour traiter des requêtes avec des latences prévisibles et faibles, par exemple, un cluster composé de trois nœuds de stockage et d'un proxy, formé d'environnements n1-highmem-32 (32 CPU Intel Xeon 2,30 GHz, 214 Go de RAM et 450 Go de stockage SSD), a pu fournir des latences fixes ne dépassant pas 2,5 ms dans 95 % des cas et 16 ms dans 99 % lors du traitement de 200 000 connexions TLS simultanées et d'un flux de 15 000 requêtes par seconde (avec 3 000 connexions simultanées et un flux de 80 000 requêtes par seconde, les latences n'ont pas dépassé 6 ms dans 95 % des cas et 15 ms dans 99 %). Chez PayPal, les services basés sur JunoDB traitent environ 350 milliards de requêtes par jour.
Source : opennet.ru
