Actuellement, nous utilisons la base de données MySQL. La taille de la base de données est d'environ 45 Go et ne cesse de croître.
Nous envisageons de migrer vers la technologie NoSQL en utilisant couchbase. Je ne suis pas un expert en bases de données, j'ai quelques questions avant de pouvoir réfléchir plus loin
Merci
4 Réponses :
Les bases de données Nosql sont conçues pour répondre à votre première question en apportant une évolutivité horizontale qui vous permet de faire évoluer facilement et à moindre coût votre cluster de bases de données pour gérer de plus en plus de données. Cette évolutivité horizontale n'est pas gratuite car elle a généralement un impact sur la disponibilité ou la cohérence des données, et c'est en partie ce qui peut déterminer votre choix de la bonne solution.
Comment choisir la bonne base de données nosql dépendra de la contrainte de votre application. Les gens en général trouveront différentes solutions sur le triangle CAP (cohérence, disponibilité, tolérance de partition). Vous pouvez trouver la référence ici:
https://www.dataversity.net/choose-right -nosql-database-application / #
Vous pouvez voir ici que couchbase apporte disponibilité et tolérance de partition, mais n'est pas très bon en cohérence, contrairement au SGBDR classique qui apporte principalement des fonctionnalités de cohérence et de disponibilité.
Votre choix sera donc conditionné par cela et aussi par le type de la base de données nosql. Couchbase est orienté document, et vous avez également d'autres choix (valeur clé, colonne et graphique). Dans votre cas, le document ou la colonne conviendra probablement mieux.
J'espère que cela vous apporte des informations.
Employé de Couchbase ici,
1 - En termes de débit d'écriture, compte tenu de l'architecture de couchbase et de la manière dont les données sont automatiquement partagées / distribuées, ces performances peuvent être facilement atteintes. La taille des données ne devrait pas non plus être un problème étant donné le fait que la base de données peut évoluer jusqu'à des centaines de nœuds dans un seul cluster (1024 nœuds en théorie), mais même les plus gros clients ont des clusters avec moins de 100 nœuds.
Si vous obtenez des données par sa clé, CB fonctionnera comme un magasin clé-valeur, à la différence que les écritures sont asynchrones par défaut et qu'il a également un cache géré sur le dessus (vous pouvez même utiliser CB comme un managed cache btw), donc si vous devez lire les mêmes données encore et encore, ces données resteront automatiquement dans le cache.
Si vous avez besoin d'interroger beaucoup de données, vous pouvez simplement ajouter plus de nœuds d'index / requête à votre cluster et créer quelques index.
2 - À ce moment précis (pourrait changer dans un proche avenir), si vous avez besoin de mettre à jour plusieurs documents dans une seule transaction, les RDBM seraient toujours une meilleure solution pour vous. Cependant, les mises à jour de documents sont atomiques et vous n'aurez peut-être pas besoin de transactions du tout en raison de la façon dont vous modélisez les données dans un magasin de documents.
3 - Même si certains modules de CB sont écrits en erlang, nous n'avons pas encore de SDK Erlang https://docs.couchbase.com/server/6.0/sdk/overview.html . Cependant, comme CB lui-même est conçu pour être réactif, vous pouvez toujours utiliser node ou java pour écrire / lire de manière réactive si vous avez vraiment besoin d'obtenir le débit maximal possible.
Il y a quelques autres détails que je n'ai pas mentionnés ici, mais si vous avez d'autres questions, n'hésitez pas à m'envoyer un ping.
Mais actuellement, nous avons des déclencheurs et des fonctions spécifiques à mysql utilisées, comment pouvons-nous remplacer cela dans Couchbase?
Couchbase a un événement, qui est quelque chose de très similaire aux déclencheurs docs.couchbase.com /server/6.0/eventing/eventing-overview.htm l
Choisissez d'utiliser SQL vs NoSQL vs Graph ... c'est la première étape. Comment vos données sont-elles organisées en termes de relations entre les données. Si vous avez besoin de relations entre les objets, utilisez SQL / Graph DB, si vous n'avez besoin que d'un seul objet, utilisez NoSQL.
Si vous choisissez d'utiliser NoSQL, il existe de nombreuses options. Avec Erlang, j'ai utilisé CouchDB et Elastic Search, mais vous pouvez choisir MangoDB, Raik ou autre chose. Les éléments les plus importants à considérer sont la manière dont vous devez accéder aux données, la facilité de purger / supprimer de grands ensembles de données (CouchDB est interdit), avez-vous besoin d'ACID ou de cohérence éventuelle ...
Parfois, j'utilise MySQL et je stocke simplement json dans l'un des champs et cela fonctionne beaucoup mieux que d'avoir à tout stocker dans des champs ou d'utiliser deux bases de données, une pour les données associées et une autre pour json.
Erlang fonctionnera avec n'importe quelle base de données, déterminez simplement quelles sont vos exigences.
La question du PO concerne Couchbase, pas CouchDB (oui, les noms prêtent à confusion). Mais vous soulevez de bons points!
Pour Erlang, la meilleure base de données noSQL est Riak - définitivement! Mais, cela dépend du type de données, comme déjà dit ci-dessus!
Est-il judicieux de transférer vos données de production en direct dans une technologie de base de données avec laquelle vous n'avez aucune expérience? Indice: NON.
@BillKarwin: Nous ne sommes pas pressés, nous pourrions le faire à l'avenir, cela pourrait prendre même 2 ans à mettre en œuvre. D'ici là, nous pourrions avoir beaucoup d'expérience à ce sujet. Mais notre préoccupation est de savoir si le système fonctionne si nous nous soucions des performances et de la vitesse. Nous allons commencer dans notre serveur de développement qui est la réplique exacte de l'environnement en direct.