Je travaille sur un projet qui doit stocker de très grands ensembles de données et des données de référence associées. Je n'ai jamais rencontré un projet qui nécessitait des tables assez importantes. J'ai prouvé que au moins un environnement de développement ne peut pas faire face au niveau de la base de données avec le traitement requis par les requêtes complexes contre des vues que la couche d'application génère (vues avec plusieurs jointures internes et externes, regroupement, résumant et moyennant des tables avec 90 millions de rangées. ).
Les RDBM que j'ai testés contre sont DB2 sur AIX. L'environnement DEV qui a échoué a été chargé avec 1/20 du volume qui sera traité en production. Je suis assuré que le matériel de production est supérieur à Dev et au matériel de mise en scène, mais je ne crois tout simplement pas qu'il va faire face au volume de données et de complexité des requêtes.
Avant que l'environnement de développement a échoué, il prenait plus de 5 minutes pour rendre un petit jeu de données (plusieurs centaines de lignes) produites par une requête complexe (de nombreuses jointures, beaucoup de regroupement, de sommation et de moyennes) contre les grandes tables. .
Mon sentiment d'intestin est que l'architecture de la DB doit modifier de manière à ce que les agrégations actuellement fournies par les vues soient effectuées dans le cadre d'un processus de lot hors pics.
Maintenant pour ma question. Je suis assuré par des personnes qui prétendent avoir une expérience de ce genre de chose (que je ne fais pas) que mes peurs ne sont pas fondées. Sont-ils? Un RDBM moderne (SQL Server 2008, Oracle, DB2) peut-il faire face au volume et à la complexité que j'ai décrits (étant donné une quantité appropriée de matériel) ou sommes-nous dans le domaine des technologies comme la bigtable de Google?
J'espère que des réponses des gens qui ont effectivement dû travailler avec ce type de volume à un niveau non théorique.
La nature des données est des transactions financières (dates, montants, emplacements géographiques, entreprises), presque tous les types de données sont représentés. Toutes les données de référence sont normalisées, d'où les multiples jointures.
5 Réponses :
Si ce n'est que 1/20 de vos données, vous devez presque certainement rechercher des solutions plus évolutives et plus efficaces, telles que la grande table de Google. Jetez un coup d'œil à NOSQL
Je pense personnellement que MongoDB est un impressionnant entre NOSQL et TDR. Ce n'est pas relationnel, mais cela fournit beaucoup plus de fonctionnalités qu'un simple magasin de documents.
NOSQL n'est pas plus "évolutif" que les RDBMSES, peu importe ce que disent les holouses Digg.
"Beaucoup de jointures, beaucoup de regroupement, de sommation et de moyenne de la moyenne" <- Hmm .. Je ne pense pas que les solutions NOSQL fournissent de telles fonctionnalités.
@Billy, des conceptions relationnelles bien connues ne fonctionneront pas dans une base de données non relationnelle. C'est comme la planification de s'attaquer à un grand projet Java tout en disant «Je vais écrire cette ligne pour la ligne comme la présente mise en œuvre de la référence COBOL», cela ne va pas fonctionner. Il aurait besoin d'une refonte de la manière dont les données sont stockées et comment il l'accède.
@Earlz: Oui. Je voulais juste signaler que Sure, NOSQL peut vous donner des performances plus élevées que SQL Can. Mais si vous avez besoin des types de fonctionnalités de reporting comme celui-ci que vous ne ferez que vous ne ferez que décaler le goulot d'étranglement du serveur SQL dans votre application, ce qui n'est aucune aide. Il n'y a pas de balle d'argent. NOSQL est excellent pour les sites Web tels que Digg, qui ne capitalisent pas sur la puissance de rapport de SQL, peut-être 80-90% des sites Web. Mais pour l'application, les besoins de l'OP, NOSQL serait une erreur.
@Brilly la plupart du temps, une application peut être plus facile à réduire qu'une base de données peut être. Par exemple, une application Web, vous devez simplement ajouter un autre serveur pour gérer les demandes, trivial à l'échelle.
@Earlz: Pour 80-90% des sites Web, je suis d'accord. Mais NOSQL serait toujours une erreur pour la demande de l'OP comme décrit.
"Par exemple, une application Web, vous devez simplement ajouter un autre serveur à la gestion des demandes" - et où ce serveur obtient-il ses données de? Il reste encore une façon pour tous ces serveurs de partager des données et éventuellement de l'État. Si vous allez prétendre que "NOSQL" - qui n'est rien de plus qu'un terme parapluie pour une gamme disparate de bases de données non relationnelles open-source - est d'une manière ou d'une autre solution à l'échelle qu'un SGBR haut de gamme très coûteux (DB2 ), alors vous auriez au mieux avoir des preuves pour remonter ainsi. La plupart des RDBMSE peuvent facilement être mis à l'échelle en jetant simplement plus de matériel au problème.
@AAR, si l'application Web doit avoir tellement d'état que vous ne pouvez pas simplement utiliser une table dans la base de données, alors vous le faites mal. En outre, si vous pouvez trouver des points de repère complets entre les deux, je voudrais les voir .. J'ai du mal à trouver quelque chose de prouver ou de réfuter.
@Earlz: Exactement. Vous avez besoin d'une base de données pour stocker l'état / les données. Ajouter plus de serveurs Web ne change pas cela. NOSQL ne devient qu'une solution intéressante en termes d'évolutivité lors de la mise à l'échelle en ajoutant plus de serveurs devient moins chère et plus facile que de se mettre à l'échelle en ajoutant plus de mémoire / cpus / disques. Cela pourrait être vrai pour Google et Digg, mais ils sont l'exception, pas la règle. En ce qui concerne les points de repère, vous avez raison, ce n'est pas vrai, c'est exactement pourquoi vous devriez être méfiant des revendications d'évolutivité supérieure.
Et en ce qui concerne les "conceptions relationnelles de bien sûr ne travaillera pas dans une base de données non relationnelle" - Construire une application commerciale majeure sans une base de données relationnelle n'est pas une entreprise triviale. Il est vaguement comme construire un entrepôt de données massif; Vous devez mettre en œuvre manuellement chaque requête et agrégat.
Dans les modèles dimensionnels (méthodologie KIMBALL) dans notre entrepôt de données sur SQL Server 2005, nous avons régulièrement des tables de faits avec de nombreuses lignes juste en une seule partie de la partition mensuelle.
Certaines choses sont instantanées et certaines choses prennent un certain temps, cela dépend de l'opération et du nombre d'étoiles combinées et de ce qui se passe.
Les mêmes modèles fonctionnent mal sur Teradata, mais c'est ce que je crois comprendre que si nous rétrostiquions dans 3NF, la parallélisation Teradata fonctionnera beaucoup mieux. L'installation TERADATA est plusieurs fois plus chère que l'installation SQL Server. Il va donc montrer la quantité de modélisation de différence et correspondant à vos données et à vos processus au jeu de fonctions sous-jacentes.
Sans en savoir plus sur vos données et comment il est actuellement modélisé et quels choix d'indexation que vous avez rendus est difficile de dire quelque chose de plus.
Merci. Il y a définitivement une place d'amélioration de notre modèle et cette tâche tombera à une personne ayant une expérience dans cette arène. Ce qui est important pour moi, c'est qu'il existe des exemples d'autres personnes utilisant un SGBBR commercial aux volumes d'entrepôt de données similaires à la nôtre. J'apprécie la réponse.
Je travaille avec quelques bases de données SQL Server 2008 contenant des tables avec la numérotation des lignes dans les milliards. Les seuls problèmes réels que nous avons rencontrés étaient ceux d'espace disque, de temps de sauvegarde, etc. Les requêtes étaient (et sont toujours) toujours rapides, généralement dans la plage <1 sec, jamais plus de 15-30 secondes, même avec des jointures lourdes, des agrégations et Donc sur.
Les systèmes de base de données relationnels peuvent certainement gérer ce type de charge, et si un serveur ou un disque commence à la souche, la plupart des bases de données haut de gamme ont des solutions de partitionnement.
Vous n'avez rien mentionné dans votre question sur la manière dont les données sont indexées et 9 fois sur 10, lorsque j'entends des plaintes sur les performances SQL, l'indexation inadéquate / inexistante s'avère être le problème.
La toute première chose que vous devriez toujours faire quand vous voyez une requête lente, tracez le plan d'exécution. Si vous voyez des analyses d'indice / de table complètes, des recherches de ligne, etc., indiquant une indexation inadéquate pour votre requête ou une requête qui est écrite afin de pouvoir profiter des index de couverture. Des jointures inefficaces (principalement des boucles imbriquées) ont tendance à être le deuxième coupable le plus répandu et il est souvent possible de fixer cela avec une réécriture de requête. Mais sans pouvoir voir le plan, tout cela ne fait que spéculation.
La réponse de base à votre question est Oui, les systèmes de base de données relationnels sont entièrement capables de manipuler cette échelle , mais si vous voulez quelque chose de plus détaillé / utile, vous voudrez peut-être poster un exemple de schéma / Script de test, ou au moins un plan d'exécution pour que nous examinons.
Merci. C'est exactement le genre de réponse que je cherchais. La confiance réelle mondiale de l'expérience pratique. Cela me donne de l'espoir.
On dirait que vous calculez les mêmes données encore et encore des données normalisées. Un moyen d'accélérer le traitement dans des cas comme celui-ci est de garder SQL avec ses belles rapports et des relations et une consistance, ainsi que d'utiliser un OLAP Cube calculé toutes les minutes de minutes. Fondamentalement, vous construisez une grande table de données dénormalisées sur une base régulière qui permet une recherche rapide. Les données relationnelles sont traitées comme le maître, mais le cube permet de récupérer des valeurs précises rapides de la base de données à un moment donné.
90 millions de lignes devraient être d'environ 90 Go, ainsi que votre goulot d'étranglement est disque. Si vous avez besoin de ces questions rarement, courez-les comme.
Si vous avez souvent besoin de ces questions, vous devez diviser vos données et précalcomputer votre résumé de goupage et la moyenne de la moyenne de la part de vos données qui ne changent pas (ni ne change depuis la dernière fois).
Par exemple, si vous traitez des données historiques pour les dernières années jusqu'à aujourd'hui, vous pouvez le traiter un mois (ou une semaine, une journée) à la fois et stocker les totaux et les moyennes quelque part. Ensuite, à la requête, il vous suffit de retraiter la période qui inclut aujourd'hui.
Certains RDBMS vous permettent de contrôler lorsque les vues sont mises à jour (sur Sélectionner, à la source de la source, hors ligne), si votre résumé de regroupement complexe et la moyenne est en fait assez simple pour que la base de données se comprenne correctement, elle pourrait, en théorie, Mettez à jour quelques lignes en vue de chaque insertion / mise à jour / Supprimer dans vos tables source à un délai raisonnable.