Cet article est en cours de rédaction, son contenu peut évoluer sans préavis et les informations qu'il contient peuvent manquer de précisions.
Introduction
Il n'est pas toujours nécessaire pour des applications de dépendre d'un service de base de données. Pourtant, cette approche est classique pour la plupart des applications d'entreprise, car elle présente de nombreux avantages et garanties. Selon la capacité de votre entreprise, le service de base de données peut être géré par l'équipe de développement. En général, on voit plutôt un DBA ou une équipe de DBA, qui a alors pour charge d'assurer le maintien, la disponibilité d'un tel service, éventuellement de proposer des améliorations aux développeurs dans leur utilisation de la base de données.
Il est des applications, pour lesquelles adjoindre un tel service représente un coût non négligeable sur les capacités de mise en production. D'un côté, il faut comprendre deux points :
- Si l'équipe de développement gère elle-même le service de base de données, elle risque d'être dépassée par la gestion de ce service et être moins productive sur le maintient et les évolutions de leur application.
- Si le service de base de données est gérées par un DBA ou une équipe de DBA, la productivité de l'équipe de développement est liée à la capacité des DBA à comprendre les besoins métiers mis en avant par leur application (qui sera pour eux une parmi plusieurs) et la disponibilité des DBA.
Si la persistance de la donnée est critique pour l'application, ces coûts supplémentaires sont potentiellement justifiés. Mais vous êtes peut-être dans le cas où votre application n'a besoin de stocker la donnée que pour constituer un cache et améliorer ses performances. Dans ce cadre, la perte de la donnée ou une gestion mal optimisée aurait des conséquences sur les performances, certes, mais pas sur la qualité des données en tant que tel, sachant qu'en cas de perte, le cache peut être simplement reconstruit. Le service de base de données et sa gestion représenterait alors un coût qu'il devient moins évident à justifier. Ou alors vous travaillez directement sur des applications mobiles ? Dans ce cas, il faut que votre application soit suffisamment autonome et bénéficie d'une solution de stockage locale qui lui convienne.
Peut-on alors bénéficier d'une solution de stockage locale et structurée sans avoir à dépendre d'un service extérieur, voire à le déployer ?
Dans ce cas, il existe diverses solutions déjà connues. Apache Derby, HSQLDB, H2, et surtout SQLite sont des bases de données relationnelles embarquables (embeddable). Développées en Java ou en C, elles apparaissent sous forme de bibliothèque, directement utilisable dans votre code source. Ces bibliothèques vont alors stocker les données dans des fichiers situés dans le volume local à votre application.
Mais il est possible que l'approche relationnelle ne permette pas de satisfaire vos besoins. Typiquement, la constitution d'un cache implique de travailler avec des données dénormalisées afin d'éviter au consommateur de la donnée de payer le coût de jointures venant affecter la réactivité de votre système, ou de multiplier les appels à vos API (cf. N+1 query problem) qui vont se traduire par des multiplications de communications réseaux déjà coûteux. Vous pouvez aussi avoir le cas où vous avez besoin de données qui au niveau stockage sont déjà pré-triées, afin de faciliter la recherche de données sur des intervalles de valeurs.
Une bonne partie des bases de données NoSQL répondent typiquement à ces cas d'usages. Mais, lorsqu'on pense à base de données NoSQL, on pense à MongoDB, Cassandra, Elasticsearch, Redis, HBase... À nouveau des services, qu'il faut soit déployer, paramétrer et maintenir, soit qui implique une dépendance avec des OPS.
RocksDB peut être vu comme l'équivalent embarcable au base de données NoSQL.
RocksDB
RocksDB est une base de données NoSQL de type clé-valeur triée et embarcable. Elle est optimisée pour des solutions de stockage basée sur mémoire Flash, en particulier les stockages SSD. Elle est aussi hautement configurable. On ne parle pas seulement ici d'adapter les performances de RocksDB, mais aussi de sélectionner uniquement les fonctionnalités de la base qui intéressent.
RocksDB a été créé au sein de Facebook en 2012, déjà connu pour avoir avoir créé Cassandra. C'est un fork de LevelDB de Google.
Sous la JVM, il va vous falloir avant-tout charger l'ensemble des dépendances natives.
RocksDB.loadLibrary()RocksDB.open("data/db")