PayPal a ouvert le code source du SGBD JunoDB tolérant aux pannes, qui manipule les données dans un format clé-valeur. Le système a été initialement conçu avec une sécurité élevée, une évolutivité horizontale, une tolérance aux pannes et la capacité de gérer des centaines de milliers de connexions simultanées avec des latences prévisibles à l'esprit. Chez PayPal, presque tous les services, depuis la connexion des utilisateurs jusqu'au traitement des transactions financières, sont liés à JunoDB. Le code du projet est écrit en Go (une bibliothèque client Java) et est distribué sous la licence Apache 2.0. Le développement ultérieur acceptera les corrections, les améliorations et les changements de la part de la communauté.
L'architecture de JunoDB est basée sur l'utilisation d'un équilibreur de charge qui accepte les requêtes des applications clientes et les distribue entre des serveurs proxy qui accèdent simultanément à un groupe de serveurs de stockage lorsque la requête est exécutée. Chaque serveur proxy établit des connexions à tous les serveurs de stockage en même temps et transmet les requêtes à un groupe de serveurs de stockage en fonction de l'index de partition, qui est stocké dans la configuration etcd du système de stockage distribué.
Les données sont partitionnées et liées aux nœuds de stockage à l'aide du hachage, ce qui réduit le mouvement des données à mesure que les nœuds du cluster augmentent ou diminuent. Pour garantir la tolérance aux pannes, chaque élément de données est répliqué sur plusieurs nœuds de stockage, ce qui vous permet de sauvegarder les informations en cas de panne de serveurs individuels. La création de stockages géographiquement répartis est prise en charge, dans lesquels des groupes de nœuds sont situés dans différents centres de données.
Sur les nœuds de stockage de données, ils sont situés en RAM ou dans un stockage local basé sur la bibliothèque RocksDB. Lorsqu'elles sont stockées de manière permanente, les données sont stockées sous forme cryptée (la clé de cryptage peut être déterminée soit par le client, soit définie au niveau du proxy).
Pour accéder à la base de données à partir des applications, une bibliothèque client est fournie qui fournit une API pour les applications en Java, Go et C++. La partie client est simplifiée autant que possible et la logique et les paramètres complexes sont transférés du côté SGBD chaque fois que cela est possible. L'interaction entre le client et l'équilibreur ou le proxy s'effectue via un canal de communication crypté. Pour gérer et envoyer des requêtes, vous pouvez utiliser l'interface de ligne de commande, qui réplique toutes les fonctionnalités de l'API client.
Le système est conçu pour traiter les demandes avec de faibles latences prévisibles, par exemple, un cluster de trois nœuds de stockage et un proxy, formé à partir d'environnements n1-highmem-32 (32 processeurs Intel Xeon 2.30 GHz, 214 Go de RAM et 450 Go de stockage sur SSD). , a pu fournir des délais fixes ne dépassant pas 2.5 ms dans 95 % des cas et 16 ms dans 99 % lors du traitement de 200 15 connexions TLS simultanées et d'un flux de 3000 80 requêtes par seconde (avec 6 95 connexions simultanées et un flux de 15 99 requêtes par seconde, les retards ne dépassaient pas 350 ms dans XNUMX % des cas et XNUMX ms dans XNUMX %). Chez PayPal, les services basés sur JunoDB traitent environ XNUMX milliards de requêtes par jour.
Source: opennet.ru