Les données de notre SGBD relationnel deviennent volumineuses, est-il temps de passer à NoSQL?

Nous avons créé une application de réseau social à des fins d'apprentissage en ligne. C'est un projet expérimental que nous recherchons dans notre laboratoire. Il a été utilisé dans certaines études de cas pendant un certain temps et les données de notre SGBD relationnel (SQL Server 2008) deviennent volumineuses. Cela fait maintenant quelques gigaoctets et les tables sont très connectées les unes aux autres. Les performances sont toujours bonnes, mais quand devrions-nous envisager d'autres options? Est-ce une question de performance?

Quelques gigaoctets, ce n'est pas très " gros ". Cela ressemble plus à la taille normale d'une base de données d'entreprise. Tant que vous parcourez PK lors de la jonction de tables, cela devrait très bien fonctionner, même à l'avenir (tant que vous n'obtenez pas de TB de données par jour).

La plupart des professionnels travaillant dans un environnement de Big Data considèrent > ~ 5 To comme le début du terme Big Data. Mais même dans ce cas, ce n'est pas toujours le meilleur moyen d'installer simplement la prochaine meilleure base de données nosql. Vous devez toujours penser à la tâche que vous souhaitez archiver avec les données (agréger, lire, rechercher, extraire, ..) pour trouver les meilleurs outils pour votre problème.

c'est-à-dire que si vous faites beaucoup de recherches dans votre base de données, il serait probablement préférable d'exécuter une instance / cluster solr et de dénormaliser vos données à partir d'un SGBD comme Postgres ou votre SQL Server de temps en temps et de les mettre dans solr au lieu de simplement déplacer les données de sql à nosql en terme de persistance et de performance.

Pour répondre à cette question, vous devez répondre au type de compromis que vous pouvez vous permettre. RDBM implémente ACID . C'est cher en termes de ressources. Aucune solution NoSQL n'est ACID. Voir le théorème CAP pour approfondir ces idées.

Vous devez donc comprendre chaque compromis donné par chaque solution et choisir celui qui convient le mieux à votre problème.

Les mégadonnées ne sont en fait pas tellement sur le "combien il est".

Premièrement, quelques gigaoctets ne sont pas gros du tout, ce n'est presque rien. Alors ne vous embêtez pas, votre système continuera de fonctionner efficacement pendant un certain temps, je pense.

Ensuite, vous devez penser à la façon dont vous utilisez vos données.

• Approche SQL: toutes les données sont précieuses, bien collectées et sélectionnées, et l'accent est mis sur le stockage de données de grande valeur et bien structurées. Cela peut être coûteux, tout est interconnecté et c'est bon pour un système bien structuré et des données fonctionnelles.
• Approche Big Data: Dans le Big Data, vous stockez pratiquement tout, quelle que soit sa valeur, puis effectuez un processus d'analyse actif. Les choses ne sont pas liées, elles sont copiées. Par exemple, disons que j'ai une entrée de blog. Dans le Big Data, il n'y aura pas de lien vers son auteur, mais l'auteur sera intégré à l'entrée du blog. Beaucoup plus évolutif, mais nécessite une approche différente et plus complexe.

Si votre stockage de données "fonctionnelles" est utilisé par votre application, je vous propose de rester sur SQL. Si vous stockez des données afin de les rechercher plus tard ou de faire des rapports, et si cette quantité de données peut augmenter rapidement, je suggérerai le big data. À mon avis, les mégadonnées sont utiles lorsque vous traitez avec des données réelles qui doivent être collectées et analysées en continu.

J'ai posté une réponse assez détaillée sur stackoverflow sur le moment opportun pour utiliser la base de données relationnelle vs document (ou NoSQL), ici:

Motivations pour l'utilisation de la base de données relationnelle / ORM ou de la base de données documentaire / ODM

Sommaire:

• pour les petits trucs, allez avec les outils que vous connaissez

• quelques gigaoctets, c'est vraiment petit: il ne devient pas gros jusqu'à ce qu'il soit trop grand pour tenir dans un seul cluster MySQL avec un nombre raisonnable de nœuds (16-32), ce qui signifie peut-être 8-16 To de données et quelques millions de transactions par seconde (ou une base de données basée sur un disque dur plus conventionnelle avec jusqu'à 100 de données TB et quelques milliers de transactions par seconde).

• si vous êtes coincé avec une autre base de données (pas MySQL Cluster), tirez-en plus de profit en ajoutant du matériel FusionIO.

• une fois que vous avez des données supérieures à quelques To et plus rapides que des milliers de transactions par seconde, c'est le bon moment pour envisager de passer d'abord au partage logique dans le code d'application, puis à NoSQL.

• Cassandra :)

Est-il temps de passer à NoSQL? Cela dépend de 2 choses:

1. La nature / structure de vos données
2. Vos performances actuelles

Les bases de données SQL excellent lorsque les données sont bien structurées (par exemple, lorsqu'elles peuvent être modélisées sous forme de tableau, de feuille de calcul Excel ou d'un ensemble de lignes avec un nombre fixe de colonnes). Aussi bien lorsque vous avez besoin de faire beaucoup de jointures de table (ce qui ressemble à vous).

Les bases de données NoSQL excellent lorsque les données ne sont pas structurées au-delà des paires clé-valeur.

En termes de performances, vous devez vous poser une question: votre solution SQL actuelle est-elle lente ?

Sinon, optez pour le principe " IIABDFI ".