Top 11 des bases de données Open Source pour votre prochain projet

Les données sont tout. Et par extension, les bases de données le sont aussi. Voici quelques options open source fantastiques pour votre prochain projet kick-ass.


Pour un monde dominé si longtemps par des combinaisons de bases de données comme Oracle et SQL Server, il semble y avoir une multitude de solutions à présent. Une partie de la raison est l’innovation alimentée par l’Open Source – des développeurs vraiment talentueux qui veulent se gratter et créer quelque chose dans lequel ils peuvent se délecter.

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

Le résultat?

Plus de bases de données que l’on peut suivre. Il n’y a pas de statistiques officielles à ce sujet, mais je suis 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 à la pile aux projets peu populaires des universités.

Je sais, ça me fait aussi peur. 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 ce soit pour vous ou pour les autres..

Pas de MySQL

Remarque: cette liste ne contiendra pas MySQL, même si c’est sans doute la solution de base de données Open Source la plus populaire sur le marché..

Pourquoi? Tout simplement parce que MySQL est partout – c’est ce que tout le monde apprend en premier, il est pris en charge par pratiquement tous les CMS ou frameworks là-bas, et c’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”. ��

Cela dit, veuillez noter que les éléments suivants ne sont pas nécessairement des alternatives à MySQL. Dans certains cas, ils peuvent l’être, tandis que dans d’autres, ils constituent une solution complètement différente pour un besoin entièrement différent. Ne vous inquiétez pas, car je parlerai également de leurs utilisations.

Remarque 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 quelconque, ne prend en charge qu’un moteur de base de données particulier, vos choix sont à peu près traités.

Par exemple, si vous utilisez WordPress, cet article ne vous est d’aucune utilité. �� De même, ceux qui exécutent des sites statiques sur JAMStack ne gagneront rien en cherchant trop sérieusement des alternatives.

C’est à vous de déterminer l’équation de compatibilité. Cependant, si vous avez une ardoise vierge et que l’architecture dépend de vous, voici quelques recommandations intéressantes.

PostgreSQL

Si vous venez de la terre PHP (WordPress, Magento, Drupal, etc.), alors PostgreSQL vous semblera étranger. Cependant, cette solution de base de données relationnelle existe depuis 1997 et est le premier choix dans des communautés comme Ruby, Python, Go, etc..

En fait, de nombreux développeurs finissent par «passer» à PostgreSQL pour les fonctionnalités qu’il propose, ou simplement pour la stabilité. Il est difficile de convaincre quelqu’un dans une courte rédaction comme celle-ci, mais considérez PostgreSQL comme un produit bien pensé qui ne vous laisse jamais tomber.

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

Caractéristiques uniques

PostgreSQL possède plusieurs fonctionnalités fascinantes par rapport à d’autres bases de données relationnelles (en particulier MySQL), telles que:

  • Types de données intégrés pour Array, Range, UUID, Geolocation, 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
  • Scriptable en PL, Perl, Python et plus
  • Recherche en texte intégral

Mes favoris personnels sont le moteur de géolocalisation (qui enlève la douleur lorsque vous travaillez avec des applications basées sur la localisation – essayez de trouver tous les points à proximité manuellement, et vous comprendrez ce que je veux dire) et le support des tableaux (de nombreux projets MySQL sont annulés faute de tableaux, optant plutôt pour les fameuses chaînes séparées par des virgules).

Quand utiliser PostgreSQL

PostgreSQL est toujours un meilleur choix par rapport à tout autre moteur de base de données relationnelle. Autrement dit, si vous démarrez un nouveau projet et avez été mordu par MySQL auparavant, c’est le bon moment pour envisager PostgreSQL. J’ai des amis qui ont abandonné la lutte contre les mystérieux échecs de verrouillage transactionnels de MySQL et sont passés de façon permanente. Si vous en décidez de même, vous ne réagirez pas de manière excessive.

PostgreSQL a également un avantage évident si vous avez besoin de fonctionnalités partielles NoSQL pour un modèle de données hybride. Étant donné que le stockage de documents et de valeurs-clés est pris en charge en mode natif, vous n’avez pas besoin d’aller chercher, installer, apprendre et gérer une autre solution de base de données.

Quand ne pas utiliser PostgreSQL

PostgreSQL n’a aucun 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 Analytics, où de nouveaux rapports sont constamment créés à partir de données existantes. Ces systèmes sont lourds en lecture et souffrent lorsqu’un schéma strict leur est imposé. Bien sûr, PostgreSQL dispose d’un moteur de stockage de documents, mais les choses commencent à s’effondrer lorsque vous traitez avec de grands ensembles de données.

En d’autres termes, utilisez toujours PostgreSQL, sauf si vous savez à 100% ce que vous faites! ��

Regarde ça SQL & Cours PostgreSQL pour débutants si vous souhaitez en savoir plus.

MariaDB

MariaDB a été créé en remplacement de MySQL, par la même personne qui a développé MySQL.

Confus?

Eh bien, en fait, après le rachat de MySQL par Oracle en 2010 (en acquérant Sun Microsystems, qui est d’ailleurs 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 importent-ils, demandez-vous? C’est parce que MariaDB a été créée à partir de la même base de code que celle de MySQL (dans le monde open source, ceci est connu comme «forking» un projet existant). En conséquence, MariaDB est présenté comme un remplacement «drop-in» pour MySQL.

Autrement dit, si vous utilisez MySQL et que vous souhaitez migrer vers MariaDB, le processus est si simple que vous ne le croirez pas.

Malheureusement, une telle migration est à sens unique. Il n’est pas possible de revenir de MariaDB à MySQL, et si vous essayez d’utiliser la force, une corruption permanente de la base de données est assurée!

Caractéristiques uniques

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

  • Vraiment gratuit et ouvert: Puisqu’il n’y a pas une seule entité d’entreprise contrôlant MariaDB, vous pouvez vous libérer des licences d’éviction soudaines et d’autres soucis.
  • Plusieurs autres options de moteurs de stockage pour des besoins spécifiques: par exemple, le moteur Spider pour les transactions distribuées; ColumnStore pour un stockage de données massif; le moteur ColumnStore pour un stockage parallèle et distribué; et bien d’autres.
  • Améliorations de la vitesse par rapport à MySQL, en particulier grâce au moteur de stockage Aria pour les requêtes complexes.
  • Colonnes dynamiques pour différentes lignes d’un tableau.
  • Meilleures capacités de réplication (par exemple, réplication multi-source)
  • Plusieurs fonctions JSON
  • Colonnes virtuelles

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

Quand utiliser MariaDB

Vous devriez MariaDB si vous voulez un véritable remplacement de MySQL, voulez rester sur la courbe d’innovation et ne prévoyez pas 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, cela devient de moins en moins problématique car des projets comme WordPress, Joomla, Magento, etc., ont commencé à prendre en charge MariaDB. Mon conseil serait de ne pas utiliser MariaDB pour tromper un CMS qui ne le prend pas en charge, car il existe de nombreuses astuces spécifiques à la base de données qui planteront le système facilement.

CockroachDB

L’équipe derrière CockroachDB semble être composée de masochistes. Avec un nom de produit comme ça, ils veulent sûrement tourner toutes les chances contre eux et toujours gagner?

Eh bien, pas tout à fait.

L’idée derrière “cafard” est qu’il s’agit d’un insecte construit pour la survie. Peu importe ce qui se passe – prédateurs, inondations, ténèbres éternelles, nourriture en décomposition, bombardements, le cafard trouve un moyen de survivre et de se multiplier.

L’idée est que l’équipe derrière CockroachDB (composée d’anciens ingénieurs de Google) était frustrée par les limites des solutions SQL traditionnelles en ce qui concerne la grande échelle. En effet, historiquement, les solutions SQL étaient censées être hébergées sur une seule machine (les données n’étaient pas si grandes). Pendant longtemps, il n’y avait aucun moyen de construire un cluster de bases de données exécutant SQL, c’est pourquoi MongoDB a attiré autant d’attention.

Même lorsque la réplication et le clustering sont sortis dans MySQL, PostgreSQL et MariaDB, cela a été au mieux douloureux. CoackroachDB veut changer cela, en apportant un partage, un clustering et une haute disponibilité sans effort au 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 mijoté les capacités de mise à l’échelle de MongoDB, vous allez adorer CockroachDB. Vous pouvez désormais configurer rapidement un cluster, y lancer des requêtes et dormir paisiblement la nuit. ��

Quand ne pas utiliser CockroachDB

Mieux vaut le diable que vous connaissez que celui que vous ne connaissez pas. J’entends par là, si votre SGBDR existant fonctionne bien pour vous et que vous pensez que vous pouvez gérer les douleurs d’échelle qu’il apporte, respectez-le. Pour tout le génie impliqué, CockroachDB est un nouveau produit, et vous ne voulez pas vous battre plus tard. Une autre raison majeure est la compatibilité SQL – si vous faites des trucs SQL exotiques et que vous vous y fiez pour des choses critiques, CockroachDB présentera trop de cas limites à votre goût.

À partir de maintenant, nous envisagerons des solutions de base de données non SQL (ou NoSQL, comme on l’appelle) pour des besoins hautement spécialisés.

Neo4j

L’une des évolutions les plus importantes de la dernière décennie concerne les données connectées. Le monde qui nous entoure n’est pas divisé en tables et rangées et boîtes – c’est un gâchis géant avec tout ce qui 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 bases de données SQL ou même documentaires est un cauchemar.

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

L’exemple ci-dessus est tiré directement du site Web Neo4j et montre comment les étudiants universitaires sont connectés à leurs départements et 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.

Caractéristiques uniques

Les bases de données graphiques sont uniques en elles-mêmes, et Neo4j est à peu près la seule option pour travailler avec des graphiques. En conséquence, toutes les fonctionnalités qu’il possède sont uniques. ��

  • Prise en charge des applications transactionnelles et des analyses de graphiques.
  • 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 graphique
  • Fonctions de visualisation et de découverte

C’est un point discutable pour savoir quand utiliser Neo4j et quand non. Si vous avez besoin de relations basées sur des graphiques entre vos données, vous avez besoin de Neo4j. ��

MongoDB

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

Contrairement aux bases de données relationnelles, MongoDB est une «base de données de documents», ce qui signifie qu’il stocke les données dans des blocs, avec les données associées regroupées dans le même bloc. Ceci est mieux compris en imaginant une agrégation de structures JSON comme celle-ci:

Ici, contrairement à une structure basée sur une table, les coordonnées et les niveaux d’accès d’un utilisateur résident à l’intérieur du même objet. La récupération de l’objet utilisateur récupère automatiquement les données associées, et il n’y a pas de concept de jointure. Voici une introduction plus détaillée à MongoDB.

Caractéristiques uniques

MongoDB a des fonctionnalités sérieuses (je veux presque écrire “kick-ass” pour transmettre l’impact, mais ce ne serait peut-être pas approprié sur un site Web public, peut-être) des fonctionnalités qui ont fait que plusieurs architectes chevronnés abandonnent le terrain relationnel pour toujours:

  • Un schéma flexible pour des cas d’utilisation spécialisés / imprévisibles.
  • Partage et regroupement ridiculement simples. Il vous suffit de configurer la configuration d’un cluster et de l’oublier.
  • L’ajout ou la suppression d’un nœud d’un cluster est extrêmement simple.
  • Verrous transactionnels distribués. Cette fonctionnalité manquait dans les versions précédentes mais a finalement été introduite.
  • Il est optimisé pour des écritures très rapides, ce qui le rend parfaitement adapté aux données d’analyse en tant que système de mise en cache.

Si je parle comme un porte-parole de MongoDB, je m’excuse, mais il est difficile de survendre les avantages de MongoDB. Bien sûr, la modélisation des données NoSQL est bizarre au début, et certains n’y arrivent jamais, mais pour de nombreux architectes, elle l’emporte presque toujours sur un schéma basé sur une table.

Quand utiliser MongoDB

MongoDB est un excellent pont croisé entre le monde structuré et strict de SQL et le monde amorphe, presque déroutant de NoSQL. Il excelle dans le développement de prototypes, car il n’y a tout simplement pas de schéma à craindre et quand vous avez vraiment besoin de faire évoluer. Oui, vous pouvez utiliser un service cloud SQL 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 où les solutions basées sur SQL ne suffiront tout simplement pas. Par exemple, si vous créez un produit comme Canva, où l’utilisateur peut créer des conceptions arbitrairement complexes et pouvoir les modifier plus tard, bonne chance avec une base de données relationnelle!

Quand ne pas utiliser MongoDB

L’absence totale de schéma fourni par MongoDB peut fonctionner comme une fosse de goudron pour ceux qui ne savent pas ce qu’ils font. Inadéquation des données, données mortes, champs vides qui ne devraient pas être vides – tout cela et bien plus encore est possible. MongoDB est essentiellement un magasin de données «stupide», et si vous le choisissez, le code d’application doit assumer une grande part de responsabilité pour maintenir l’intégrité des données.

Si vous êtes développeur, vous trouverez c’est utile.

RethinkDB

Comme son nom l’indique, RethinkDB «Repense» l’idée et les capacités d’une base de données en ce qui concerne les 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 acceptée consiste à ce que l’application déclenche une notification dès qu’il y a une mise à jour, qui est poussée au front-end via un pont complexe (PHP -> Redis -> Nœud -> Socket.io en est un exemple).

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

Oui, c’est la promesse de RethinkDB. Donc, si vous voulez créer une véritable application en temps réel (jeu, marché, analyse, etc.), Rethink DB vaut le détour.

Redis

En ce qui concerne les bases de données, il est presque trop facile d’ignorer l’existence de Redis. En effet, Redis est une base de données en mémoire et est principalement utilisée dans les fonctions de support telles que la mise en cache.

Apprendre cette base de données est un travail de dix minutes (littéralement!), et c’est un simple magasin de valeurs-clés qui stocke les chaînes avec un délai d’expiration (qui peut être réglé à l’infini, bien sûr). Ce que Redis perd en fonctionnalités, il le compense en utilité et en performances. Puisqu’il vit entièrement en RAM, les lectures et les écritures sont incroyablement rapides (quelques centaines de milliers d’opérations par seconde ne sont pas inconnues).

Redis possède également un système pub-sub, ce 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 a des composants distribués, Redis est le premier choix.

SQLite

Oui, j’ai promis qu’on en avait 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 dans cette base de données vit 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, aucun logiciel «serveur» à installer et aucun service auquel se connecter.

Fonctionnalités utiles

Même si SQLite est une alternative légère à une base de données comme MySQL, il a du punch. Certaines de ses caractéristiques choquantes sont:

  • Prise en charge complète des transactions, avec COMMIT, ROLLBACK et BEGIN.
  • Prise en charge de 32 000 colonnes par table
  • Prise en charge JSON
  • Prise en charge de JOIN à 64 voies
  • Sous-requêtes, recherche plein texte, etc..
  • Taille maximale de la base de données de 140 téraoctets!
  • Taille de ligne maximale de 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 sans fioritures et get-shit-done. Si votre application est relativement simple et que vous ne voulez pas les tracas d’une base de données complète, SQLite est un candidat sérieux. Il est particulièrement judicieux pour les CMS de petite à moyenne taille et les applications de démonstration.

Quand 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 manquants. De plus, il n’y a pas de client pour se connecter, interroger et explorer la base de données. Enfin, à mesure que la taille de l’application augmente, les performances se dégradent.

Cassandra

Alors que beaucoup proclament que Java est proche de la fin, 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 de bases de données «en colonnes». L’abstraction de stockage dans Cassandra est une colonne plutôt qu’une ligne. L’idée ici est de stocker toutes les données dans une colonne physiquement ensemble sur le disque, minimisant le temps de recherche.

Caractéristiques uniques

Cassandra a été conçue avec un cas d’utilisation spécifique à l’esprit – traitant des charges lourdes en écriture et de la tolérance zéro pour les temps d’arrêt. Ceux-ci deviennent ses arguments de vente uniques.

  • Performances d’écriture extrêmement rapides. Cassandra est sans doute la base de données la plus rapide pour gérer de lourdes charges d’écriture.
  • Évolutivité linéaire. Autrement dit, vous pouvez continuer à ajouter autant de nœuds à un cluster que vous le souhaitez, et il y aura une augmentation nulle de la complexité ou de la fragilité du cluster.
  • Tolérance de partition inégalée. Autrement dit, 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 pour Cassandra. Mais ce n’est pas tout – le point idéal est lorsque vous devez gérer de très grandes tailles de données (Apple a un déploiement Cassandra qui gère plus de 400 pétaoctets de données tandis que chez Netflix, il gère 1 billion de demandes par jour) avec littéralement aucun temps d’arrêt. La haute disponibilité est l’une des caractéristiques de Cassandra.

Quand ne pas utiliser Cassandra

Le système de stockage sur colonne de Cassandra a également ses inconvénients. Le modèle de données est plutôt plat, et si vous avez besoin d’agrégations, alors Cassandra échoue. 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 adapté aux systèmes où une grande précision de lecture est nécessaire.

Calendrier

Les nouveaux développements nécessitent 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 Calendrier.

L’échelle de temps est un type de ce qu’on appelle une base de données de «séries chronologiques». C’est différent d’une base de données traditionnelle en ce temps-là est le principal axe de préoccupation, et l’analyse et la visualisation d’ensembles de données massifs est une priorité absolue. Les bases de données de séries chronologiques voient rarement un changement dans les données existantes; un exemple est les lectures de température envoyées par un capteur dans une serre – de nouvelles données s’accumulent chaque seconde, ce qui est intéressant pour l’analyse et les rapports.

Pourquoi ne pas utiliser uniquement une base de données traditionnelle avec un champ d’horodatage? Eh bien, il y a deux raisons principales à cela:

  • Les bases de données à usage général ne sont pas optimisées pour fonctionner avec des données temporelles. Pour les mêmes quantités de données, une base de données à usage général sera beaucoup plus lente.
  • La base de données doit gérer d’énormes quantités de données à mesure que de nouvelles données continuent d’affluer et de supprimer des données ou de modifier le schéma; plus tard, n’est pas une option.

Caractéristiques uniques

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

  • Il est construit sur PostgreSQL, sans doute la meilleure base de données relationnelle open source sur le marché. Si votre projet exécute déjà PostgreSQL, Timescale glissera directement dans.
  • L’interrogation s’effectue via la syntaxe SQL familière, ce qui réduit la courbe d’apprentissage.
  • Vitesses d’écriture ridiculement rapides – des millions d’inserts par seconde ne sont pas inconnus.
  • Des milliards de lignes ou de pétaoctets de données – ce n’est pas grave pour Timescale.
  • Véritable flexibilité avec schéma – choisissez entre relationnel ou sans schéma selon vos besoins.

Il n’est pas très logique de parler du moment d’utiliser ou de 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 mérite le détour.

CouchDB

CouchDB est une petite solution de base de données soignée qui se trouve tranquillement dans un coin et a un petit mais dédié suivant. Il a été créé pour faire face aux problèmes de perte de réseau et de résolution éventuelle des données, ce qui s’avère être un problème si compliqué que les développeurs préfèrent changer de travail plutôt que de le gérer..

Essentiellement, vous pouvez considérer un cluster CouchDB comme une collection distribuée de nœuds petits et grands, dont certains devraient être hors ligne. Dès qu’un nœud est mis en ligne, il renvoie des données au cluster, qui est lentement et soigneusement digéré, devenant éventuellement disponible pour l’ensemble du cluster.

Caractéristiques uniques

CouchDB est quelque chose d’une race unique en ce qui concerne les bases de données.

  • Capacités de synchronisation des données hors ligne
  • Versions spécialisées pour navigateurs mobiles et web (PouchDB, CouchDB Lite, etc.)
  • Fiabilité résistante aux chocs et éprouvée au combat
  • Mise en cluster facile avec stockage de données redondant

Quand utiliser CouchDB

CouchDB a été conçu pour une tolérance hors ligne et reste inégalé à cet égard. Un cas d’utilisation typique est celui des applications mobiles dans lesquelles une partie de vos données réside sur une instance CouchDB sur le téléphone de l’utilisateur (car c’est là où elles ont été générées). Ce qui est intéressant, c’est que vous ne pouvez pas compter sur l’appareil de l’utilisateur pour être connecté tout le temps, ce qui signifie que la base de données doit être opportuniste et être prête à résoudre les mises à jour conflictuelles plus tard. Ceci est réalisé en utilisant l’impressionnant Protocole de réplication de canapé.

Quand ne pas utiliser CouchDB

Essayer d’utiliser CouchDB en dehors de son cas d’utilisation prévu entraînera un désastre. Il utilise beaucoup plus de stockage qu’autre chose, simplement parce qu’il doit conserver des copies redondantes des données et des résultats de résolution des conflits. En conséquence, les vitesses d’écriture sont également douloureusement lentes. Enfin, CouchDB ne convient pas comme moteur de schéma à usage général, car il ne fonctionne pas bien avec les modifications de schéma.

Conclusion

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

Si vous êtes curieux d’apprendre la base de données, consultez Udemy pour certains des brillants cours en ligne.

MOTS CLÉS:

  • Base de données

  • Open source

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map