NoSQL db ou SQL?

Question

Je n'ai pas d'expérience sur les bases de données No-SQL puisque je travaillais principalement sur SQL. Mais je pense que maintenant mon design pourrait bénéficier de ce que j'essaye d'accomplir. Je veux surveiller les prix de certains produits et les enregistrer dans un db. Au début, le nombre de produits sera limité (500) et je surveillerai leur prix une fois par jour (soit un maximum de 365 par an).

Pensée originale devait avoir une table price_history avec des colonnes comme id|date|price - donc pour un an, je vais avoir 365 jours * 500 produits nombre de lignes. Serait-ce bénéfique d'utiliser des bases de données No-SQL, où (si j'ai lu correctement) je peux utiliser un format de document (par exemple le style JSON) et qui rendra l'interrogation de l'histoire un seul produit plus rapide?

Pour cette quantité de données, peut-être SQL est ok, mais si:

• colonnes augmentent sur la table price_history
• Je veux enregistrer des données pendant des années, non seulement pour un an (il continuera de croître)
• produits augmentent

Alors, est-il en vaut la peine de lire à propos de No-SQL dbs dans mon paradigme ci-dessus?

Answer 1

Il vaut vraiment la peine de lire davantage sur NoSQL pour voir si cela convient à votre charge de travail. Plus d'informations est une bonne chose.

Cependant, rien sur le problème que vous avez décrit jusqu'à présent appelle NoSQL comme solution.

Vous avez étiqueté votre question avec mysql, donc je suppose que c'est la base de données SQL que vous envisagez. Il est certainement possible d'ajouter des colonnes à une table MySQL, même après qu'elle ait été remplie. Plus vous avez de données dans le tableau, plus cela prend de temps. Mais c'est possible.

Si vous avez besoin de continuer à interroger la table pendant qu'elle est restructurée de cette manière, un outil comme pt-online-schema-change peut vous aider.

Il semble que la valeur d'une année de données soit de 365 * 500 ou 182 500 lignes. Franchement, c'est une quantité assez modeste de données. Les administrateurs de base de données MySQL traitent souvent avec des bases de données beaucoup plus volumineuses.

Une table dans l'une des bases de données que je gère actuellement est d'environ 4,5 milliards de lignes, et elle augmente de 2 à 10 millions de lignes par jour. J'utilise une combinaison d'index et de partitionnement pour m'assurer que les requêtes fonctionnent aussi bien que possible. Je gère d'autres tables contenant plus de 100 millions de lignes de données chacune. Aucune base de données, SQL ou NoSQL, vous permet de continuer à croître indéfiniment. Toute stratégie d'évolutivité des données doit inclure une politique d'archivage ou de synthèse des anciennes données.

Un autre conseil que je donne est que le choix entre SQL et NoSQL est plus ou moins le même exercice que le choix entre SQL normalisé et SQL dénormalisé. En d'autres termes, vous choisissez le SGBD en fonction de sa capacité à optimiser les types de requêtes que vous exécuterez sur les données, et non la structure ou le volume de données à stocker.

Je suppose que vos données vont essentiellement être utilisées comme un entrepôt de données, et vos requêtes vont faire des calculs globaux ou des tendances informatiques et ainsi de suite. Pour cela, vous pouvez envisager une base de données de magasin de colonnes spécialisée.Il s'agit toujours d'une base de données SQL, mais elle stocke les données de manière à optimiser les requêtes OLAP.

Des exemples de bases de données en colonnes comprennent:

• http://infinidb.co/ (un moteur de stockage pour MySQL)
• https://aws.amazon.com/redshift/ (un service de nuage dérivé de PostgreSQL)
• http://greenplum.org/
• Autres énumérés à https://en.wikipedia.org/wiki/List_of_column-oriented_DBMSes