Il existe près de 900 BDD (cf https://dbdb.io/) et chacune a ses particularités : modèle de requêtage, modélisation de la donnée, moteur de stockage, ….

Existe-t-il une de ces trois caractéristiques que l’on peut mutualiser ?

Oui, toutes les bases de données stockent de la donnée, on doit donc pouvoir mutualiser le stockage.

Avec un moteur de stockage séparé, les BDD deviennent stateless !

Ce moteur doit être performant, scallable, fournir une abstraction pour construire des BDD, et faciliter les opérations et la maintenance.

FoundationDB répond à tout ça !

Les concepts :

• Moteur transactionnel scallable aux performances du NoSQL (forte volumétrie de lecture / écriture)
• Fonctionnalités réduites
• Clé / Valeur (get, put, scan)
• Les clés sont ordonnées
• Transaction de type « strict serializability »

FoundationDB est un projet créé en 2009, acheté par Apple en 2015, et mis en OSS en 2018 sous licence Apache v2. Utilisé aussi par Snowflake qui est un important contributeur.

Apple l’utilise entre autre dans iCloud.

Architecture macro :

• Architecture basée sur des acteurs qui ont un rôle
• Pour scaller, on ajoute des acteurs sur le rôle qui est à la limite
• La base de données diagnostique automatiquement les rôles qui manquent d’acteurs : facilite les opérations !
• Sépare lecture et écriture qui peuvent être scallées séparément

Grâce à ce modèle : scallabilité quasi linéaire ! Jusqu’à 10 millions d’opérations par seconde avec 400 cœurs.

Debugger un système distribué en production est un enfer, FoundationDB a créé un simulateur pour pouvoir simuler et injecter des fautes pour tester sa base de données d’une manière déterministe. Permets d’injecter des fautes dans les I/O disque ou réseau, dans le temps, sur un rôle / un acteur donné.
Apple et Snowflake font tourner des scenarii de simulation qui correspondent, par an, à 4000 ans de chaos testing.

Clever Cloud travail sur une solution de BDD serverless basé sur FoundationDB codée en Rust.

Rentrons en détail dans FoundationDB :

• API Java Clé / Valeur simple avec rejeux infini en cas d’erreur, transactionnelle par défaut.
• Clé et valeur sont des tableaux de bytes.
• Les transactions sont rejouées automatiquement en cas de conflit transactionnel.
• Par défaut, les mutations sont gardées en mémoire 5s, les transactions ne peuvent donc pas durer plus de 5s. FoundationDB ne peut donc pas être utilisé pour de l’analytics.
• Les clés ne peuvent dépasser 10Ko et la valeur 100Ko. Pour stocker plus, il faut découper la donnée à stocker en plusieurs clés / valeurs.