L'azienda PayPal ha reso disponibili i codici sorgente del database resiliente JunoDB, che gestisce i dati nel formato chiave-valore. Il sistema è stato progettato fin dall'inizio con un occhio alla massima sicurezza, scalabilità orizzontale, resilienza e capacità di gestire centinaia di migliaia di connessioni simultanee con ritardi prevedibili. In PayPal, praticamente tutti i servizi, dall'accesso degli utenti all'elaborazione delle transazioni finanziarie, dipendono da JunoDB. Il codice del progetto è scritto in linguaggio Go (la libreria client è in Java) e viene distribuito con licenza Apache 2.0. Durante lo sviluppo futuro, saranno accettate correzioni, miglioramenti e modifiche dalla comunità.
L'architettura di JunoDB si basa sull'utilizzo di un bilanciatore di carico che riceve le richieste dalle applicazioni client e le distribuisce tra i server proxy, che accedono contemporaneamente a un gruppo server di archiviazione durante l'elaborazione della richiesta. Ogni server proxy stabilisce connessioni contemporaneamente con tutti server memorizza e reindirizza le richieste a un gruppo di server di archiviazione in base all'indice di partizionamento, che è conservato in un sistema di archiviazione distribuito di configurazione etcd.
I dati sono partizionati e associati ai nodi di archiviazione utilizzando l'hashing, il che riduce il movimento dei dati quando i nodi nel cluster aumentano o diminuiscono. Per garantire l'affidabilità, ogni porzione di dati è replicata su più nodi di archiviazione, consentendo di mantenere le informazioni anche in caso di guasto di singoli server. È supportata la creazione di archivi distribuiti geograficamente, in cui i gruppi di nodi sono situati in diversi data center.
I dati sono memorizzati nei nodi di archiviazione in memoria volatile o in uno storage locale basato sulla libreria RocksDB. Quando i dati sono archiviati in modo permanente, vengono conservati in forma crittografata (la chiave di crittografia può essere definita sia dal cliente che impostata a livello di proxy).
Per accedere al database dalle applicazioni, viene fornita una libreria client che offre un'API per applicazioni scritte in Java, Go e C++. La parte client è stata semplificata al massimo, mentre la logica complessa e le configurazioni sono state spostate, dove possibile, sul lato del DBMS. L'interazione tra il client e il bilanciatore di carico o il proxy avviene tramite un canale di comunicazione crittografato. Per gestire e inviare richieste è possibile utilizzare un'interfaccia da riga di comando, che replica tutte le funzionalità dell'API client.
Il sistema è stato progettato per gestire richieste con latenze basse e prevedibili. Ad esempio, un cluster composto da tre nodi di archiviazione e un proxy, costituito da ambienti n1-highmem-32 (32 CPU Intel Xeon 2.30GHz, 214G RAM e 450G di archiviazione SSD), è riuscito a fornire latenze fisse non superiori a 2,5 ms nel 95% dei casi e 16 ms nel 99% durante il trattamento di 200.000 connessioni TLS simultanee e un flusso di 15.000 richieste al secondo. (Nel caso di 3.000 connessioni simultanee e un flusso di 80.000 richieste al secondo, le latenze non hanno superato i 6 ms nel 95% dei casi e 15 ms nel 99%). In PayPal, i servizi basati su JunoDB gestiscono circa 350 miliardi di richieste al giorno.
Fonte: opennet.ru
