Top 13 des logiciels de base de données open source pour votre prochain projet

Les données sont omniprésentes. Et par extension, les bases de données aussi. Voici quelques options open source fantastiques pour votre prochain projet.

Alors que le monde a été dominé pendant si longtemps par des entreprises de bases de données telles qu’Oracle et SQL Server, il semble qu’il y ait aujourd’hui une multitude de solutions. Une partie de la raison est l’innovation alimentée par l’Open Source – des développeurs vraiment talentueux voulant gratter une démangeaison et créer quelque chose dont ils peuvent se délecter.

L’autre partie est l’émergence de nouveaux modèles commerciaux, dans lesquels les entreprises maintiennent une version communautaire de leur produit pour gagner en notoriété et en traction, tout en proposant une offre commerciale complémentaire.

Résultat ?

Il y a plus de bases de données que l’on ne peut en gérer. Il n’y a pas de statistiques officielles à ce sujet, mais je suis presque sûr que nous avons plus d’une centaine d’options disponibles aujourd’hui si vous combinez tout, des bases de données d’objets spécifiques aux piles aux projets peu populaires des universités.

Je sais, cela m’effraie aussi. Trop d’options – trop de documentation à parcourir – et une vie si courte 🙂

C’est pourquoi j’ai décidé d’écrire cet article, présentant dix des meilleures bases de données que vous pouvez utiliser pour améliorer vos solutions, que vous construisiez pour vous-même ou pour d’autres.

Pas de MySQL

Veuillez noter que cette liste ne contiendra pas MySQL, même s’il s’agit de la solution de base de données Open Source la plus populaire.

Pourquoi ?

Tout simplement parce que MySQL est partout – c’est ce que tout le monde apprend en premier, il est supporté par pratiquement tous les CMS ou frameworks existants, et il est très, très bon pour la plupart des cas d’utilisation. En d’autres termes, MySQL n’a pas besoin d’être “découvert” 🙂

Ceci dit, veuillez noter que les solutions suivantes ne sont pas nécessairement des alternatives à MySQL. Dans certains cas, elles peuvent l’être, alors que dans d’autres, elles sont une solution complètement différente pour un besoin complètement différent. Ne vous inquiétez pas, car je discuterai également de leur utilisation.

Note spéciale : compatibilité

Avant de commencer, je dois également mentionner que la compatibilité est quelque chose que vous devez garder à l’esprit. Si vous avez un projet qui, pour une raison ou une autre, ne supporte qu’un moteur de base de données particulier, vos choix sont pratiquement limités.

Par exemple, si vous utilisez WordPress, cet article ne vous sera d’aucune utilité 🙂 De même, ceux qui font tourner des sites statiques sur JAMStack ne gagneront rien à chercher trop sérieusement des alternatives.

C’est à vous de trouver l’équation de la compatibilité. Cependant, si vous disposez d’une ardoise vierge et que l’architecture vous appartient, voici quelques recommandations intéressantes.

PostgreSQL

Si vous venez du monde du PHP (WordPress, Magento, Drupal, etc.), PostgreSQL vous semblera étranger. Pourtant, ce logiciel de base de données relationnelle existe depuis 1997 et constitue le premier choix dans des communautés telles que Ruby, Python, Go, etc.

En fait, de nombreux développeurs finissent par “passer” à PostgreSQL pour les fonctionnalités qu’il offre ou simplement pour sa stabilité. Il est difficile de convaincre quelqu’un dans un court article comme celui-ci, mais considérez PostgreSQL comme un produit bien conçu qui ne vous laissera jamais tomber.

De nombreux clients SQL sont disponibles pour se connecter à la base de données PostgreSQL pour l’administration et le développement.

Fonctionnalités uniques

PostgreSQL possède plusieurs caractéristiques fascinantes par rapport aux autres bases de données relationnelles (en particulier, MySQL), telles que :

• Types de données intégrés pour les tableaux, les plages, les UUID, la géolocalisation, etc.
• Prise en charge native du stockage de documents (style JSON), du XML et du stockage de valeurs clés (Hstore)
• Réplication synchrone et asynchrone
• Possibilité de créer des scripts en PL, Perl, Python, etc
• Recherche plein texte

Mes favoris sont le moteur de géolocalisation (qui vous soulage lorsque vous travaillez avec des applications basées sur la localisation – essayez de trouver tous les points proches manuellement, et vous verrez ce que je veux dire) et le support des tableaux (de nombreux projets MySQL sont annulés à cause du manque de tableaux, optant à la place pour les fameuses chaînes de caractères séparées par des virgules).

Quand utiliser PostgreSQL

PostgreSQL est toujours un meilleur choix que n’importe quel autre moteur de base de données relationnelle. En d’autres termes, si vous démarrez un nouveau projet et que vous avez déjà été mordu par MySQL, c’est le bon moment pour envisager PostgreSQL. J’ai des amis qui ont abandonné la lutte contre les mystérieuses défaillances des verrous transactionnels de MySQL et sont passés définitivement à autre chose. Si vous décidez de faire de même, vous n’exagérerez pas.

PostgreSQL présente également un avantage certain si vous avez besoin d’installations NoSQL partielles pour un modèle de données hybride. Puisque le stockage de documents et de clés-valeurs est nativement supporté, vous n’avez pas besoin de chercher, d’installer, d’apprendre et de maintenir une autre solution de base de données.

Quand ne pas utiliser PostgreSQL

PostgreSQL n’a pas de sens lorsque votre modèle de données n’est pas relationnel et/ou lorsque vous avez des exigences architecturales très spécifiques. Par exemple, considérez l’analyse, où de nouveaux rapports sont constamment créés à partir de données existantes. De tels systèmes sont lourds en lecture et souffrent lorsqu’un schéma strict leur est imposé. Certes, PostgreSQL dispose d’un moteur de stockage de documents, mais les choses commencent à s’effondrer lorsque vous traitez de grands ensembles de données.

En d’autres termes, utilisez toujours PostgreSQL à moins que vous ne sachiez à 100 % ce que vous faites ! 🙂

Si vous souhaitez en savoir plus, consultez le cours SQL & PostgreSQL pour débutants.

MariaDB

MariaDB a été créé pour remplacer MySQL par la même personne qui a développé MySQL.

Vous êtes confus ?

En fait, après que MySQL a été racheté par Oracle en 2010 (en acquérant Sun Microsystems, ce qui, soit dit en passant, est aussi la façon dont Oracle a pris le contrôle de Java), le créateur de MySQL a lancé un nouveau projet open source appelé MariaDB.

Pourquoi tous ces détails ennuyeux ont-ils de l’importance, me direz-vous ? Parce que MariaDB a été créé à partir de la même base de code que MySQL (dans le monde des logiciels libres, on appelle cela “forker” un projet existant). Par conséquent, MariaDB est présenté comme un remplacement “direct” de MySQL.

En d’autres termes, si vous utilisez MySQL et que vous souhaitez migrer vers MariaDB, le processus est si simple que vous n’en reviendrez pas.

Malheureusement, cette migration est à sens unique. Revenir de MariaDB à MySQL n’est pas possible, et si vous essayez de forcer le processus, une corruption permanente de la base de données est assurée !

Des caractéristiques uniques

Bien que MariaDB soit essentiellement un clone de MySQL, ce n’est pas tout à fait vrai. Depuis l’introduction de la base de données, les différences entre les deux se sont accrues. À ce jour, l’adoption de MariaDB doit être une décision mûrement réfléchie de votre part. Cela dit, il y a beaucoup de nouveautés dans MariaDB qui peuvent vous aider à faire cette transition :

• Vraiment libre et ouvert : Comme il n’y a pas d’entité corporative unique qui contrôle MariaDB, vous pouvez être à l’abri des licences prédatrices et d’autres soucis.
• Plusieurs options supplémentaires de moteurs de stockage pour des besoins spécialisés : par exemple, le moteur Spider pour les transactions distribuées ; ColumnStore pour l’entreposage massif de données ; le moteur ColumnStore pour le stockage parallèle et distribué ; et bien d’autres encore.
• Amélioration de la vitesse par rapport à MySQL, notamment grâce au moteur de stockage Aria pour les requêtes complexes.
• Colonnes dynamiques pour les différentes lignes d’une table.
• Meilleures capacités de réplication (par exemple, réplication multi-sources)
• Plusieurs fonctions JSON
• Colonnes virtuelles

. . . Et bien d’autres encore. C’est épuisant de suivre toutes les fonctionnalités de MariaDB 🙂

Quand utiliser MariaDB

Si vous voulez un vrai remplacement de MySQL, vous devriez utiliser MariaDB car ils veulent rester à la pointe de l’innovation et n’ont pas l’intention de revenir à MySQL. Un excellent cas d’utilisation est l’utilisation de nouveaux moteurs de stockage dans MariaDB pour compléter le modèle de données relationnel existant de votre projet.

Quand ne pas utiliser MariaDB

La compatibilité avec MySQL est la seule préoccupation ici. Cela dit, c’est de moins en moins un problème car des projets comme WordPress, Joomla, Magento, etc. ont commencé à prendre en charge MariaDB. Je vous conseille de ne pas utiliser MariaDB pour tromper un CMS qui ne le supporte pas, car de nombreuses astuces spécifiques à la base de données peuvent facilement faire planter le système.

Consultez la différence entre MariaDB et MySQL et le guide d’installation de MariaDB.

CockroachDB

L’équipe à l’origine de CockroachDB semble être composée de masochistes. Avec un nom de produit comme celui-là, ils veulent sûrement retourner toutes les chances contre eux et gagner quand même ?

Ce n’est pas tout à fait le cas.

L’idée derrière le mot “cafard” est qu’il s’agit d’un insecte conçu pour survivre. Quoi qu’il arrive – prédateurs, inondations, obscurité éternelle, nourriture en décomposition, bombardements – le cafard trouve un moyen de survivre et de se multiplier.

L’idée est que l’équipe à l’origine de CockroachDB (composée d’anciens ingénieurs de Google) était frustrée par les limites des solutions SQL traditionnelles lorsqu’il s’agit de grandes échelles. En effet, historiquement, les solutions SQL étaient censées être hébergées sur une seule machine (les données n’étaient pas si volumineuses). Pendant longtemps, il n’y avait aucun moyen de construire un cluster de bases de données exécutant SQL, ce qui explique pourquoi MongoDB a attiré tant d’attention.

Même lorsque la réplication et le clustering sont apparus dans MySQL, PostgreSQL et MariaDB, c’était au mieux pénible. CoackroachDB veut changer cela, en apportant le sharding, le clustering et la haute disponibilité sans effort dans le monde de SQL.

Quand utiliser CockroachDB ?

CockroachDB est le rêve de l’architecte système devenu réalité. Si vous ne jurez que par SQL et que vous avez été surpris par les capacités de mise à l’échelle de MongoDB, vous allez adorer CockroachDB. Désormais, vous pouvez rapidement mettre en place un cluster, y lancer des requêtes et dormir tranquillement la nuit 🙂

Quand ne pas utiliser CockroachDB

Mieux vaut le diable que vous connaissez que celui que vous ne connaissez pas. Je veux dire par là que si votre SGBDR existant fonctionne bien pour vous et que vous pensez pouvoir gérer les problèmes de mise à l’échelle qu’il entraîne, ne le quittez pas. CockroachDB est un nouveau produit pour tous les génies impliqués, et vous ne voulez pas avoir à vous battre contre lui plus tard. Une autre raison majeure est la compatibilité SQL – si vous faites des choses exotiques en SQL et que vous comptez sur lui pour des choses critiques, CockroachDB présentera trop de cas limites à votre goût.

À partir de maintenant, nous envisagerons des solutions de bases de données non SQL (ou NoSQL, comme on les appelle) pour des besoins très spécialisés.

ClickHouse

Vous recherchez un système de base de données OLAP rapide et open-source ?

Optez pour ClickHouse.

Il utilise chaque matériel au maximum de son potentiel pour traiter chaque requête plus rapidement. Les performances maximales de traitement d’une requête restent généralement supérieures à deux téraoctets par seconde. Pour éviter une augmentation de la latence, les lectures sont équilibrées automatiquement entre les répliques saines.

Il prend en charge la réplication asynchrone multimaître et vous pouvez le déployer dans différents centres de données. Les nœuds étant maintenus égaux, vous pouvez éviter les points de défaillance simples. L’indisponibilité d’un seul nœud ou d’un centre de données complet n’affectera jamais la disponibilité du système en termes d’écritures et de lectures.

ClickHouse est très simple et facile à utiliser. Il rationalise le traitement des données, place toutes vos données dans un système de manière organisée et est disponible instantanément pour créer des rapports. De plus, le dialecte SQL permet d’exprimer le résultat sans utiliser d’API non standard, que vous pouvez trouver dans d’autres systèmes.

Vous pouvez compter sur ce système de gestion de base de données pour le configurer comme un système distribué situé sur des nœuds distincts sans points de défaillance. En outre, ses fonctions de sécurité sont robustes, y compris la sécurité de niveau entreprise et les mécanismes de sécurité intégrée en cas d’erreurs humaines.

ClickHouse peut traiter les requêtes plus rapidement que les systèmes orientés lignes ayant la même capacité de CPU et le même débit d’E/S. Le format de stockage des données en colonnes permet de conserver les données en temps réel. Son format de stockage de données en colonnes permet de conserver davantage de données dans la mémoire vive, ce qui se traduit par des temps de réponse plus courts.

Le coût total de possession peut être réduit en utilisant du matériel de base doté de lecteurs de disques rotatifs plutôt que d’utiliser des NVMe/SSD sans sacrifier la latence des requêtes. Il s’efforce d’améliorer l’efficacité du processeur, d’optimiser l’accès au lecteur de disque et de minimiser les transferts de données.

En outre, grâce à sa base de données SQL riche en fonctionnalités, vous pouvez traiter efficacement vos requêtes en un rien de temps, joindre des données co-localisées et distribuées, gérer efficacement les informations dénormalisées, etc. ClickHouse évolue horizontalement et verticalement et s’adapte facilement pour fonctionner sur un seul serveur ou sur des grappes de plusieurs milliers de nœuds.

Utilisez ClickHouse pour l’analyse de sites web et d’applications, les télécommunications, les réseaux publicitaires, les jeux en ligne, l’IdO, la veille stratégique, la finance, le commerce électronique, la surveillance, etc.

Il s’intègre à Hadoop, Postgres et MySQL.

Si vous n’êtes pas prêt à installer et à configurer un serveur, vous pouvez essayer Kamatera qui propose ClickHouse en un clic.

Neo4j

L’un des développements les plus importants de la dernière décennie est celui des données connectées. Le monde qui nous entoure n’est pas divisé en tableaux, en lignes et en boîtes – c’est un gigantesque fouillis où tout est connecté à presque tout le reste.

Les réseaux sociaux en sont un excellent exemple, et la construction d’un modèle de données similaire à l’aide de SQL ou même de bases de données documentaires est un cauchemar.

En effet, la structure de données idéale pour ces solutions est le graphe, qui est une bête entièrement différente. Et pour cela, vous avez besoin d’une base de données de graphes comme Neo4j.

L’exemple ci-dessus est tiré directement du site web de Neo4j et montre comment les étudiants d’une université sont connectés à leurs départements et à leurs cours. Un tel modèle de données est tout simplement impossible avec SQL, car il sera difficile d’éviter les boucles infinies et les dépassements de mémoire.

Des caractéristiques uniques

Lesbases de données de graphes sont uniques en elles-mêmes, et Neo4j est pratiquement la seule option pour travailler avec des graphes. Par conséquent, toutes les fonctionnalités qu’il possède sont uniques 🙂

• Prise en charge des applications transactionnelles et de l’analyse des graphes.
• Capacités de transformation des données pour digérer des données tabulaires à grande échelle dans des graphiques.
• Langage de requête spécialisé (Cypher) pour interroger la base de données de graphes
• Fonctions de visualisation et de découverte

Il est inutile de se demander quand utiliser Neo4j et quand ne pas l’utiliser. Si vous avez besoin de relations graphiques entre vos données, vous avez besoin de Neo4j 🙂

MongoDB

MongoDB a été la première base de données non relationnelle à faire des vagues dans l’industrie technologique et continue d’attirer une bonne partie de l’attention.

Contrairement aux bases de données relationnelles, MongoDB est une “base de données documentaire”, qui stocke les données par morceaux, les données connexes étant regroupées dans le même morceau. La meilleure façon de le comprendre est d’imaginer une agrégation de structures JSON comme celle-ci :

Ici, contrairement à une structure basée sur un tableau, les coordonnées et les niveaux d’accès de l’utilisateur se trouvent dans le même objet. La récupération de l’objet utilisateur permet de récupérer automatiquement les données associées, et il n’y a pas de concept de jointure. Vous trouverez ici une présentation plus détaillée de MongoDB.

Des caractéristiques uniques

MongoDB possède des caractéristiques importantes (j’ai presque envie d’écrire “génial” pour exprimer l’impact, mais ce ne serait pas approprié sur un site web public, peut-être) qui ont poussé plusieurs architectes chevronnés à abandonner définitivement le monde relationnel :

• Un schéma flexible pour les cas d’utilisation spécialisés/imprévisibles.
• Un sharding et un clustering ridiculement simples. Il vous suffit d’établir la configuration d’un cluster et de l’oublier.
• L’ajout ou le retrait d’un nœud d’une grappe est d’une simplicité déconcertante.
• Verrous transactionnels distribués. Cette fonctionnalité n’existait pas dans les versions précédentes, mais elle a finalement été introduite.
• Elle est optimisée pour les écritures très rapides, ce qui la rend particulièrement adaptée aux données analytiques en tant que système de mise en cache.

Si j’ai l’air d’être un porte-parole de MongoDB, je m’en excuse, mais il est difficile de surestimer les avantages de MongoDB. Certes, la modélisation des données NoSQL est bizarre au début, et certains ne parviennent jamais à la maîtriser, mais pour de nombreux architectes, elle l’emporte presque toujours sur un schéma basé sur des tables.

Quand utiliser MongoDB ?

MongoDB est une excellente passerelle entre le monde structuré et strict de SQL et celui, amorphe et presque confus, de NoSQL. Il excelle dans le développement de prototypes, car il n’y a tout simplement pas de schéma dont il faut se préoccuper, et lorsque vous avez vraiment besoin d’une mise à l’échelle. Oui, vous pouvez utiliser un service SQL en nuage pour vous débarrasser des problèmes de mise à l’échelle de la base de données, mais c’est cher !

Enfin, il existe des cas d’utilisation pour lesquels les solutions basées sur SQL ne conviennent tout simplement pas. Par exemple, si vous créez un produit comme Canva, où l’utilisateur peut créer des designs arbitrairement complexes et les modifier ultérieurement, bonne chance avec une base de données relationnelle !

Quand ne pas utiliser MongoDB

L’absence totale de schéma que fournit MongoDB peut être une véritable fosse à goudron pour ceux qui ne savent pas ce qu’ils font. La non-concordance des données, les données mortes, les champs vides qui ne devraient pas l’être, tout cela et bien d’autres choses encore sont possibles. MongoDB est essentiellement un magasin de données “muet”, et si vous le choisissez, le code de l’application doit assumer une grande part de responsabilité dans le maintien de l’intégrité des données.

Si vous êtes développeur, vous trouverez ce document utile.

RethinkDB

Comme son nom l’indique, RethinkDB “repense” l’idée et les capacités d’une base de données lorsqu’il s’agit d’applications en temps réel.

Lorsqu’une base de données est mise à jour, l’application n’a aucun moyen de le savoir. L’approche habituelle consiste à envoyer une notification à l’application dès qu’il y a une mise à jour, qui est transmise au front-end par le biais d’un pont complexe (PHP -> Redis -> Node -> Socket.io en est un exemple).

Mais que se passerait-il si les mises à jour pouvaient être poussées directement de la base de données vers le front-end ?

Oui, c’est la promesse de RethinkDB. Si vous souhaitez créer une véritable application en temps réel (jeu, place de marché, analyse, etc.), Rethink DB mérite un coup d’œil.

Redis

Lorsqu’il s’agit de bases de données, il est presque trop facile d’ignorer l’existence de Redis. C’est parce que Redis est une base de données en mémoire et qu’elle est principalement utilisée dans des fonctions de support comme la mise en cache.

L’apprentissage de cette base de données est un travail de dix minutes (littéralement !), et il s’agit d’un simple magasin de valeurs clés qui stocke des chaînes de caractères avec un délai d’expiration (qui peut être fixé à l’infini, bien sûr). Ce que Redis perd en fonctionnalités, il le compense en utilité et en performances. Comme il vit entièrement en mémoire vive, les lectures et les écritures sont extrêmement rapides (quelques centaines de milliers d’opérations par seconde ne sont pas à exclure).

Redis dispose également d’un système pub-sub sophistiqué, qui rend cette “base de données” deux fois plus attrayante.

En d’autres termes, si vous avez un projet qui pourrait bénéficier de la mise en cache ou qui comporte des composants distribués, Redis est le premier choix.

SQLite

Oui, j’ai promis que nous en avions fini avec les bases de données relationnelles, mais SQLite est trop mignon pour être ignoré.

SQLite est une bibliothèque C légère qui fournit un moteur de stockage de base de données relationnelle. Tout ce qui se trouve dans cette base de données se trouve dans un seul fichier (avec une extension .sqlite) que vous pouvez placer n’importe où dans votre système de fichiers. Et c’est tout ce dont vous avez besoin pour l’utiliser ! Oui, il n’y a pas de logiciel “serveur” à installer ni de service auquel se connecter.

Fonctionnalités utiles

Bien que SQLite soit une alternative légère à une base de données comme MySQL, il est très puissant. Voici quelques-unes de ses caractéristiques les plus surprenantes :

• Prise en charge complète des transactions, avec COMMIT, ROLLBACK et BEGIN.
• Prise en charge de 32 000 colonnes par table
• Prise en charge de JSON
• prise en charge des jointures à 64 voies
• Sous-requêtes, recherche en texte intégral, etc.
• Taille maximale de la base de données : 140 téraoctets !
• Taille maximale des lignes : 1 gigaoctet !
• 35% plus rapide que les E/S de fichiers

Quand utiliser SQLite ?

SQLite est une base de données extrêmement spécialisée qui se concentre sur une approche simple et directe. Si votre application est relativement simple et que vous ne souhaitez pas vous encombrer d’une base de données complète, SQLite est un candidat sérieux. Il est particulièrement intéressant pour les CMS et les applications de démonstration de petite ou moyenne taille.

Ne pas utiliser SQLite

Bien qu’impressionnant, SQLite ne couvre pas toutes les fonctionnalités de SQL standard ou de votre moteur de base de données préféré. Le clustering, les procédures stockées et les extensions de script sont absents. Il n’y a pas non plus de client pour se connecter, interroger et explorer la base de données. Enfin, au fur et à mesure que la taille de l’application augmente, les performances se dégradent.

Cassandra

Alors que beaucoup proclament que la fin de Java est proche, de temps en temps, la communauté lâche une bombe et fait taire les critiques. Cassandra en est un exemple.

Cassandra appartient à ce que l’on appelle la famille des bases de données “en colonnes”. L’abstraction de stockage dans Cassandra est une colonne plutôt qu’une ligne. L’idée est de stocker toutes les données d’une colonne physiquement ensemble sur le disque, ce qui minimise le temps de recherche.

Des caractéristiques uniques

Cassandra a été conçu pour répondre à un cas d’utilisation spécifique : la gestion de charges importantes en écriture et la tolérance zéro en matière de temps d’arrêt. Il s’agit là de ses principaux arguments de vente.

• Performances d’écriture extrêmement rapides. Cassandra est sans doute la base de données la plus rapide du marché lorsqu’il s’agit de gérer de lourdes charges d’écriture.
• Évolutivité linéaire. En d’autres termes, vous pouvez ajouter autant de nœuds que vous le souhaitez à une grappe et il n’y aura aucune augmentation de la complexité ou de la fragilité de la grappe.
• Tolérance de partition inégalée. Même si plusieurs nœuds d’un cluster Cassandra tombent en panne, la base de données est conçue pour continuer à fonctionner sans perte d’intégrité.
• Typage statique

Quand utiliser Cassandra ?

La journalisation et l’analyse sont deux des meilleurs cas d’utilisation de Cassandra. Mais ce n’est pas tout : le meilleur moment est celui où vous devez traiter de très grandes quantités de données (Apple a déployé Cassandra pour traiter 400 pétaoctets de données, tandis que Netflix traite 1 000 milliards de requêtes par jour) avec un temps d’arrêt littéralement nul. La haute disponibilité est l’une des caractéristiques de Cassandra.

Quand ne pas utiliser Cassandra

Le système de stockage en colonnes de Cassandra présente également des inconvénients. Le modèle de données est plutôt plat, et si vous avez besoin d’agrégations, Cassandra n’est pas à la hauteur. De plus, il atteint une haute disponibilité en sacrifiant la cohérence (rappelez-vous le théorème CAP pour les systèmes distribués), ce qui le rend moins approprié pour les systèmes où une grande précision de lecture est nécessaire.

Échelle de temps

Les nouveaux développements exigent de nouveaux types de bases de données, et l’internet des objets (IoT) est l’un de ces phénomènes. L’une des meilleures bases de données open source pour cela est Timescale.

Timescale est un type de base de données appelé “séries temporelles”. Elle se distingue d’une base de données traditionnelle par le fait que le temps est l’axe principal de préoccupation et que l’analyse et la visualisation d’ensembles de données massifs sont une priorité absolue. Les bases de données de séries temporelles voient rarement un changement dans les données existantes ; par exemple, les relevés de température envoyés par un capteur dans une serre – de nouvelles données s’accumulent chaque seconde, ce qui est intéressant pour l’analyse et la création de rapports.

Dans ce cas, pourquoi ne pas utiliser une base de données traditionnelle avec un champ d’horodatage ? Il y a deux raisons principales à cela :

• Les bases de données à usage général ne sont pas optimisées pour travailler avec des données temporelles. Pour les mêmes quantités de données, une base de données polyvalente sera beaucoup plus lente.
• La base de données doit gérer des quantités massives de données, car de nouvelles données continuent d’affluer, et il n’est pas possible de supprimer des données ou de modifier le schéma ultérieurement.

Fonctionnalités uniques

Timescale DB possède des caractéristiques intéressantes qui la distinguent des autres bases de données de la même catégorie :

• Elle est construite sur PostgreSQL, sans doute la meilleure base de données relationnelle open-source. Si votre projet utilise déjà PostgreSQL, Timescale s’y intégrera facilement.
• Les requêtes sont effectuées à l’aide de la syntaxe SQL familière, ce qui réduit la courbe d’apprentissage.
• Des vitesses d’écriture ridiculement rapides – des millions d’insertions par seconde ne sont pas à exclure.
• Des milliards de lignes ou des pétaoctets de données – ce n’est pas un problème pour Timescale.
• Une vraie flexibilité avec le schéma – choisissez entre relationnel ou sans schéma selon vos besoins.

Cela n’a pas beaucoup de sens de parler de quand utiliser ou ne pas utiliser Timescale DB. Si l’IoT est votre domaine, ou si vous recherchez des caractéristiques de base de données similaires, Timescale vaut le coup d’œil.

CouchDB

CouchDB est une petite solution de base de données soignée qui se tient tranquillement dans un coin et qui a un petit nombre d’adeptes dévoués. Elle a été créée pour résoudre les problèmes liés à la perte d’un réseau et à la résolution éventuelle des données, un problème si compliqué que les développeurs préfèrent changer d’emploi plutôt que de s’en occuper.

En gros, vous pouvez considérer un cluster CouchDB comme un ensemble distribué de nœuds, petits et grands, dont certains sont censés être hors ligne. Dès qu’un nœud est en ligne, il renvoie des données au cluster, qui sont lentement et soigneusement digérées, avant d’être mises à la disposition de l’ensemble du cluster.

Des caractéristiques uniques

CouchDB est en quelque sorte une race unique en matière de bases de données.

• Capacités de synchronisation des données hors ligne
• Versions spécialisées pour les navigateurs web et mobiles (PouchDB, CouchDB Lite, etc.)
• Fiabilité à toute épreuve, résistante aux pannes
• Clustering facile avec stockage redondant des données

Quand utiliser CouchDB ?

CouchDB a été conçu pour la tolérance hors ligne et reste inégalé à cet égard. Un cas d’utilisation typique est celui des applications mobiles où une partie de vos données réside dans une instance CouchDB sur le téléphone de l’utilisateur (parce que c’est là qu’elles ont été générées). Ce qui est intéressant, c’est que vous ne pouvez pas compter sur le fait que l’appareil de l’utilisateur soit connecté en permanence, ce qui signifie que la base de données doit être opportuniste et prête à résoudre les mises à jour conflictuelles ultérieurement. Pour ce faire, vous pouvez utiliser l’impressionnant protocole de réplication Couch.

Quand ne pas utiliser CouchDB

Si vous essayez d’utiliser CouchDB en dehors du cas d’utilisation prévu, vous risquez de vous retrouver dans une situation désastreuse. CouchDB utilise beaucoup plus d’espace de stockage que n’importe quel autre système, simplement parce qu’il doit maintenir des copies redondantes des données et des résultats de la résolution des conflits. Par conséquent, les vitesses d’écriture sont également terriblement lentes. Enfin, CouchDB ne convient pas en tant que moteur de schéma polyvalent, car il ne supporte pas bien les changements de schéma.

FerretDB

FerretDB est une plateforme Open Source innovante construite sur Postgres comme alternative à MongoDB. MongoDB est la base de données la plus facile à utiliser et la mieux supportée, permettant aux développeurs de créer des applications plus rapidement que les bases de données relationnelles.

Cependant, MongoDB a abandonné ses racines Open-Source, en modifiant la licence publique côté serveur et en la rendant inutilisable pour de nombreux projets Open Source et commerciaux ; c’est là que FerretDB entre en scène. Avec FerretDB, les utilisateurs peuvent exécuter les mêmes requêtes que celles du protocole MongoDB sans avoir à apprendre un nouveau langage ou une nouvelle commande.

FerretDB est une base de données documentaire open-source qui intègre la compatibilité MongoDB tout en permettant à PostgreSQL et à d’autres bases de données d’exécuter des charges de travail MongoDB ; cela vous permet d’utiliser la syntaxe et les commandes MongoDB existantes avec votre base de données stockée dans PostgreSQL.

PostgreSQL, sur lequel FerretDB est construit, est un système de gestion de base de données relationnelle (SGBDR) robuste et open-source. Il s’agit d’une option peu coûteuse pour créer des bases de données évolutives de qualité professionnelle. PostgreSQL possède toutes les capacités et les caractéristiques dont une base de données relationnelle a besoin. Il stocke les données sous forme d’objets structurés avec des lignes et des colonnes, ce qui est parfait pour les recherches et les transactions complexes et massives.

FerretDB est une base de données documentaire qui utilise des commandes, des pilotes et des outils similaires à MongoDB pour stocker les données.

Contrairement aux bases de données relationnelles, qui spécifient la structure de la base de données à l’aide de tableaux, de lignes et de colonnes, FerretDB enregistre les informations sous forme de documents JSON, ce qui permet une intégration transparente avec les applications en ligne et mobiles modernes.

La capacité de FerretDB à rechercher rapidement et efficacement d’énormes bases de données est l’une de ses caractéristiques les plus remarquables. De plus, la plateforme est très adaptable, ce qui vous permet de l’ajuster aux besoins de votre organisation.

Il s’agit d’une solution de base de données étonnante pour les professionnels comme pour les débutants. C’est un moteur de recherche d’applications blockchain complètement décentralisé.

Ferretdb est un outil d’administration de base de données robuste qui permet aux développeurs et aux administrateurs de base de données de rechercher, tester et déployer du code.

Conclusion

J’ai dû laisser de côté de nombreux candidats intéressants, comme Riak, et cette liste doit donc être considérée comme un guide plutôt que comme un commandement. J’espère avoir atteint mon objectif avec cet article – présenter non seulement une collection de recommandations de logiciels de bases de données, mais aussi discuter brièvement où et comment ils doivent être utilisés (et évités !).

Si vous êtes curieux d’apprendre les bases de données, jetez un coup d’œil à Udemy, qui propose de brillants cours en ligne.