Grande base de données 500 millions d'enregistrements

Question

Une solution de l'un de nos problèmes d'entreprise serait de stocker environ 500 millions d'enregistrements dans une base de données. Chaque enregistrement comporterait environ 40 à 50 colonnes.

J'ai un fichier texte contenant toutes ces données et il s'agit d'environ 150 GB. (un 3ème de mon disque dur)

Si je devais charger (en quelque sorte) toutes ces données dans un db (ORACLE?) Comment cela fonctionnerait-il? Un collègue à moi insiste sur le fait que ce serait absolument parfait. Et je pourrais même indexer toutes les colonnes de 40 à 50 et ensuite il faudra écrire quelques sql pour extraire les données.

a-t-il raison? ou est 500 millions d'enregistrements trop pour un db?

p.s. Ajout de plus d'informations en suivant de très bonnes réponses: Les colonnes 40 à 50 contiendront de petites chaînes et/ou des nombres. Pour les petites chaînes, j'entends quelque chose de plus petit que 64 caractères.

Answer 1

Sans aucune information sur le SGBDR que vous utilisez, sur la façon dont il est hébergé et sur le type de données qu'il contient (grand texte, petits nombres et autres), une réponse solide n'est pas facile. La quantité pure d'enregistrements ne devrait pas être un problème, presque tous les SGBDR modernes vont facilement faire face à 500 millions d'enregistrements et plus.

Cela va devenir plus intéressant comment les données sont stockées sur votre SGBDR, p.e. quel type de système de fichiers il utilise, combien d'espace disque est disponible pour la table, comment la table est étalée sur le (s) disque (s) dur (s) et autres, qui devraient tous être pris en compte. En règle générale, je recommande seulement d'indexer les colonnes qui sont vraiment nécessaires pour les applications et les requêtes pour lesquelles les données sont utilisées, sinon elles ralentissent simplement vos insertions, utilisent l'espace disque précieux et ne vous aident pas du tout .

Voici quelques liens qui pourraient vous SO aider encore:

• Just what is 'A big database'?
• What's TOO BIG for a database?
• How does database indexing work?

Answer 2

Votre collègue est un peu correct - 500M d'enregistrements dans la base de données, c'est bien, j'ai utilisé des DB avec des lignes 2G et c'était 10 ans en arrière. L'indexation de chaque colonne est un problème - les index ralentiront chaque nouvelle insertion d'enregistrement, et la construction des index prendra beaucoup de temps. Vous devez identifier le type de requêtes que vous exécuterez, puis les indexer de manière appropriée. Avec tant d'enregistrements, vous pouvez obtenir des avantages en normalisant les données - une structure plate est souvent plus rapide, mais si vous avez des champs de texte longs répétitifs, les remplacer par des recherches peut donner des avantages de stockage et d'indexation. Sans voir les données, il est difficile de donner des conseils plus précis.

BTW Si vous rencontrez des problèmes de performances, vous pouvez également partitionner les données en tables physiquement séparées, peut-être d'ici un an?

La prochaine étape (après avoir choisi votre plateforme DB et trouvé un serveur) consiste à charger les données et à voir leur fonctionnement. Je voudrais jeter un coup d'oeil à Bulk Chargement de vos données - Je suis un gars Sql Server Integration Services est la voie à suivre. Je m'assurerais que vous avez une seule clé unique et si ce n'est pas dans les données, ajoutez une colonne d'identité. Ensuite, vous êtes prêt à tester certains de cela. SqlExpress est gratuit, livré avec SSIS mais il ne peut gérer que des DB 10G - mais cela suffit pour se familiariser avec les problèmes.

Je charge régulièrement en vrac une table à 4 M avec plus de 50 colonnes et cela prend environ 2 minutes. Je suis heureux de prendre ce hors ligne si vous voulez plus d'un sur un conseil.