J'ai récemment étudié des options NOSQL. Mon scénario est le suivant:
Nous collectons et stockons des données à partir de matériel personnalisé aux emplacements distants du monde entier. Nous enregistrons des données de chaque site toutes les 15 minutes. Nous aimerions éventuellement passer à chaque minute. Chaque enregistrement compte entre 20 et 200 mesures. Une fois configuré les enregistrements matériels et signale les mêmes mesures à chaque fois.
Le plus gros problème auxquels nous sommes confrontés est que nous obtenons un ensemble de mesures différent de chaque projet. Nous mesurons environ 50-100 types de mesure différents, mais tout projet peut avoir un nombre quelconque de chaque type de mesure. Aucun ensemble prédéfini de colonnes pouvant accueillir les données. Pour cette raison, nous créons et créons chaque table de données de projets avec les colonnes exactes dont il a besoin, car nous configurons et configurez le projet sur le système.
Nous fournissons des outils pour aider à analyser les données. Cela inclut généralement plus de calculs et d'agrégation de données, dont nous stockons également.
Nous utilisons actuellement une base de données MySQL avec une table pour chaque client. Il n'y a pas de relations entre les tables.
NOSQL semble prometteur car nous pourrions stocker un projet_id, l'horodatage, puis le reste ne serait pas préréglé. Cela signifie une seule table, plus de relations dans les données, mais toujours la gestion de la variété des mesures.
est une solution «NOSQL» juste pour ce travail? Si oui, quels sont ceux?
J'ai été enquête mongodb et il semble prometteur ...
Exemple de clarification:
Projet 1 comporte 5 points de données enregistrés, les colonnes de table MySQL ressemblent: horodatage, temp, vitesse du vent, précipitations, irradiance, direction du vent
Project 2 a 3 points de données enregistrés Colonnes de table MySQL: horodatage, temp, irradiance, temp2
4 Réponses :
Je suppose que si vous avez beaucoup de clients, vous finirez par avoir beaucoup de tables. Je voudrais d'abord supprimer cette restriction et passer à un seul modèle de table ou avoir une table pour les clients et les données avec des relations appropriées. De cette façon, vous pouvez garder mysql. Ne supposez pas que MySQL est mauvais pour tout.
En termes de NOSQL Cela dépend de votre modèle de données et de vos habitudes d'utilisation, mais si vous avez beaucoup de clients et que vous préférez ce modèle, les vues CouchDB pourraient résoudre ce problème car CouchDB peut soutenir des milliers de vues. Vous pouvez stocker toutes les données dans une base de données dans CouchDB, mais vous avez une vue pour chaque client. Je n'ai aucune idée de la façon dont MongoDB pourrait résoudre ce problème.
Je devrais être plus précis. Nous utilisons une DB MySQL pour des données relationnelles et avons une multi-location. Étant donné que les points de données sont différents pour chaque client, ils disposent chacun de leur propre table de données qui stocke des données strictement de mesure avec chaque mesure ayant sa propre colonne.
Je ne pense pas que l'auteur dit nécessairement que MySQL est mauvais, mais plus se demandant s'il y a une meilleure option. Un magasin de clé / valeur semble être un excellent moyen d'accueillir différentes colonnes pour chaque table.
Vous avez mentionné que "nous utilisons actuellement une base de données MySQL avec une table pour chaque client" - qui semble stupide si vous avez beaucoup de clients. Peut-être que je ne comprends tout simplement pas l'exemple comme il semble toujours vraiment vague.
L'alternative serait de tout mettre dans une table avec éventuellement de plus de 500 colonnes dont la plupart seraient nuls pour chaque projet. Cela semble être une alternative pire pour moi. Malheureusement, chaque site enregistre un nombre différent de mesures. Il n'y a pas de cohérence ni qu'il n'est possible d'appliquer aucun.
Si vous pouvez représenter chaque client sous forme de numéro de 0 à 65k, vous n'avez besoin que d'une colonne de type Smallint pour pouvoir marquer un peu pour chaque client. Vous pouvez l'utiliser pour écrire SQL pour obtenir l'ensemble de clients ou tester un client unique pour un enregistrement de données.
Si vous envisagez vraiment de 500 colonnes pour les données personnalisées, Couchdb serait une solution meilleure de la manière dont vous pouvez conserver une base de données, mais avoir beaucoup de points de vue de ces données.
Votre dernier commentaire a été le plus utile. Je regarde les options NOSQL car les colonnes sont toujours différentes par client et nous permettraient de vous éloigner de la table 1 par configuration du client. La possibilité de stocker les deux choses dont nous aurions besoin (ID de projet / client, horodatage) (indexé) ainsi que toutes les différentes mesures (à nouveau varie complètement par projet).
OK, je pourrais être flambé de ne pas répondre directement à votre question, mais je vais le dire quand même parce que je pense que c'est quelque chose que vous devriez considérer. Je n'ai pas d'expérience avec les bases de données NOSQL, donc je ne peux pas en recommander une mais aussi loin que des bases de données relationnelles, il pourrait y avoir une meilleure conception pour votre situation.
Tout d'abord - déposez la 1 table par client. Au lieu de cela, j'entraînerais un grand nombre de schéma dans lequel il y aurait les tableaux suivants: p>
La table des clients contiendra des informations clientes et un champ CustomerId unique: P>
Customer | MeasurementBatch | MeasurementType | Timestamp | Value |
--------------------------------------------------------------------------------
1 | {GUID} | 'WIND_SPEED' | ... | ...
--------------------------------------------------------------------------------
| | | | |
Nous avons examiné quelque chose comme ça. Le problème que nous prévoyons serait la taille de la table des mesures. À notre taux de collecte de données de 15 minutes actuelle, nous toucherions 5,25 millions d'enregistrements par projet par an. Lorsque nous passons à un intervalle d'une minute, nous parlons de 78,8 millions d'enregistrements par an par projet. Puis, avec 100 projets, nous toucherions 7 milliards d'enregistrements par an. Est-ce que quelque chose mysql peut gérer?
Je ne suis pas sûr des limitations de MySQL en termes de n ° d'enregistrements par table, mais avec une conception de base de données minutieuse (partitionnement) Un produit tel que MS SQL Server ou Oracle ne devrait pas avoir de problème de traitement de quelques centaines de millions d'enregistrements dans une table. En particulier depuis Chaque enregistrement serait plutôt petit. Vous pouvez utiliser un identifiant entier pour la mesure de la mesure et utiliser un horodatage UNIX pour et un enregistrement passerait entre 32 et 44 octets en fonction du type de données que vous utilisez pour la valeur.
La réponse simple est qu'il n'y a pas de réponse simple à ce genre de problèmes, la seule façon de savoir ce qui fonctionne pour votre scénario est d'investir du temps R & D en elle.
La question est difficile de répondre parce que les exigences de performance ne sont pas précisés par l'OP. Il semble être des documents 75M / an sur un certain nombre de clients avec un taux d'écriture de num_customers * 1 minute (ce qui est faible), mais je ne dispose pas de chiffres pour la performance de lecture / requête requise.
En effet, vous avez déjà un base de données en utilisant fragmentées partitionnement horizontal parce que vous stockez chaque client dans une table séparée. Ce qui est bon et augmenter les performances. Cependant, vous ne l'avez pas encore établi que vous avez un problème de performance, de sorte que ce qui doit être mesuré et la taille du problème évalué avant de pouvoir le corriger.
Une base de données NoSQL est en effet une bonne façon de résoudre les problèmes de performance avec SGBDR traditionnels, mais il ne fournira pas scalabity automatique et n'est pas une solution générale. Vous devez trouver votre problème de performance fixe et la conception du modèle de données (NoSQL) pour fournir la solution.
En fonction de ce que vous essayez d'atteindre je regarde MongoDB , Apache Cassandra , Apache HBase ou Hibari .
Rappelez-vous que NoSQL est un terme vague qui englobe généralement
Ainsi, en premier lieu je voudrais voir si un SGBDR traditionnel peut atteindre les performances requises, en utilisant toutes les techniques disponibles, obtenir une copie de High Performance MySQL et lire MySQL Performance Blog .
À la lumière de vos commentaires, je pense qu'il est juste de dire que vous pouvez obtenir ce que vous voulez avec l'un des moteurs au-dessus NoSQL.
Ma principale recommandation serait d'obtenir votre modèle de données conçu et mis en œuvre, ce que vous utilisez en ce moment est pas vraiment droit.
Alors regardez modèle Entité-valeur d'attribut comme je le pense est tout à fait raison pour ce que vous avez besoin.
Vous devez obtenir votre modèle de données juste avant vous pouvez envisager la technologie à utiliser, étant des schémas de modification est honnête dynamiquement pas un modèle de données.
J'utiliser une base de données SQL traditionnelle pour valider et tester le nouveau modèle de données que les outils de gestion sont mieux et il est généralement plus facile de travailler avec les schémas que vous affinez le modèle de données.
L'une des plus grandes raisons que nous recherchons dans une option NOSQL est une plus grande flexibilité avec nos colonnes de base de données. Un projet pourrait avoir 5 colonnes, une autre pourrait avoir 150. Il est également possible de modifier les colonnes une fois qu'un projet est en direct. Nous appelons ce processus "reconstruisant la table" dans laquelle notre application redéfinit la structure de la table en ajoutant ou en supprimant des champs.
EAV sonne bien; Pour être honnête "reconstruire la table" est un moyen horrible de stocker des données, un indice que le schéma est faux. Que pensez-vous de EAV?
La reconstruction de la table est une approche horrible et c'est pourquoi nous cherchons à le changer. :) - EAV est la même approche Miky D recommandée ci-dessous. Avec deux recommandations, nous allons y regarder de plus près. Je pense que nous allons brancher dans quelques semaines et essayer à la fois une approche EAV et une monogodb. Je ne vais pas marquer ni répondre comme accepté en ce moment, mais mettra à jour cette question alors que nous allons avec nos conclusions de ce qui fonctionne mieux dans notre situation exacte. Merci pour la suggestion et les liens.
FWIW: Après un an et demi de travail et d'échelle du schéma EAV dans MySQL, nous avons eu le point où nos choix étaient:
Nous avons fini par choisir Cassandra et utiliser un schéma fortement influencé par le projet OpentsDB.
Cassandra est un choix très fort pour stocker des données de la série chronologique et répond bien nos exigences.
Combien de clients avez-vous?
150 Actuellement, à notre tarif actuel, nous ajoutons ~ 100 par an, mais nous attendons (espoir) qui montent. Il ne serait pas déraisonnable de s'attendre à ce que le système ait besoin de gérer quelques milliers de projets dans les prochaines années.