Choix de base de données pour un grand volume de données?
Je suis sur le point de démarrer un nouveau projet qui devrait avoir une base de données assez volumineuse.
Le nombre de tables ne sera pas important (<15), la majorité des données (99%) seront contenues dans une grande table, qui est presque insérée/en lecture seule (pas de mises à jour).
La quantité estimée de données dans cette table va croître à 500 000 enregistrements par jour, et nous devrions en conserver au moins 1 an pour pouvoir faire divers rapports .
Il doit y avoir (lecture seule) répliqué base de données comme sauvegarde/basculement, et peut-être pour décharger les rapports en période de pointe.
Je n'ai pas d'expérience de première main avec ces grandes bases de données, donc je demande à celles qui ont quelle base de données est le meilleur choix dans cette situation. Je sais que Oracle est la valeur sûre, mais je suis plus intéressé si quelqu'un a de l'expérience avec Postgresql ou Mysql avec une configuration similaire.
J'ai utilisé PostgreSQL dans un environnement où nous voyons 100 000 à 2 millions de nouvelles lignes par jour, la plupart ajoutées à une seule table. Cependant, ces lignes ont tendance à être réduites à des échantillons puis supprimées en quelques jours, donc je ne peux pas parler de performances à long terme avec plus de ~ 100 millions de lignes.
J'ai trouvé que les performances d'insertion sont tout à fait raisonnables, surtout si vous utilisez la copie en bloc. Les performances des requêtes sont correctes, bien que les choix du planificateur me rendent parfois perplexe; en particulier lors de la réalisation de JOIN/EXISTS. Notre base de données nécessite une maintenance assez régulière (VIDE/ANALYSE) pour assurer son bon fonctionnement. Je pourrais éviter une partie de cela en optimisant plus soigneusement l'autovacuum et d'autres paramètres, et ce n'est pas vraiment un problème si vous ne faites pas beaucoup de SUPPRESSION. Dans l'ensemble, il y a certains domaines où je pense qu'il est plus difficile à configurer et à maintenir qu'il ne devrait l'être.
Je n'ai pas utilisé Oracle et MySQL uniquement pour les petits ensembles de données, je ne peux donc pas comparer les performances. Mais PostgreSQL fait fonctionne très bien pour les grands ensembles de données.
Avez-vous une copie de " The Data Warehouse Toolkit "?
La suggestion est de faire ce qui suit.
Séparez les valeurs des faits (mesurables, numériques) des dimensions qui qualifient ou organisent ces faits. Une grande table n'est pas vraiment la meilleure idée. C'est une table de faits qui domine le design, plus un certain nombre de tables de petites dimensions pour permettre de "trancher et découper" les faits.
Conservez les faits dans de simples fichiers plats jusqu'à ce que vous souhaitiez créer des rapports de style SQL. Ne créez pas et ne sauvegardez pas une base de données. Créer et sauvegarder des fichiers; charger une base de données uniquement pour les rapports que vous devez faire à partir de SQL.
Dans la mesure du possible, créez un résumé ou des tableaux de données supplémentaires pour l'analyse. Dans certains cas, vous devrez peut-être charger le tout dans une base de données. Si vos fichiers reflètent la conception de votre table, toutes les bases de données disposent d'outils de chargement en masse qui peuvent remplir et indexer les tables SQL à partir des fichiers.
Voici quelques points intéressants concernant Google BigTable ...
Bigtable Vs DBMS
- Taux de requête rapide
- Pas de jointures, pas de support SQL, base de données orientée colonnes
- Utilise une Bigtable au lieu d'avoir plusieurs tables normalisées
- N'est même pas en 1NF dans une vue traditionnelle
- Conçu pour prendre en charge le champ d'horodatage des requêtes historiques => à quoi ressemblait cette page Web hier?
- La compression des données est plus facile - les lignes sont rares
J'ai mis en évidence les jointures et l'absence de prise en charge SQL, comme vous l'avez mentionné, vous devrez exécuter une série de rapports. Je ne sais pas combien (le cas échéant) ne pas avoir la capacité de le faire aura sur vous des rapports si vous utilisez cela.
La quantité de données (200 millions d'enregistrements par an) n'est pas vraiment importante et devrait aller avec n'importe quel moteur de base de données standard.
L'affaire est encore plus facile si vous n'avez pas besoin de rapports en direct à ce sujet. Je refléterais et pré-agrégerais les données sur un autre serveur, par exemple lot quotidien. Comme l'a suggéré S.Lott, vous aimerez peut-être vous renseigner sur l'entreposage de données.
base de données BigTable et Hadoop de Google sont deux moteurs de base de données qui peuvent gérer une grande quantité de données.
Nous utilisons Firebird pour une base de données vraiment énorme (conservant les données depuis plus de 30 ans maintenant) et elle évolue très bien.
Le mieux est que vous ayez des propriétés à configurer, mais contrairement à Oracle, vous l'installez et cela fonctionne très bien sans avoir besoin de commencer la configuration avant de pouvoir l'utiliser.