Choix de base de données pour un volume de données important?

Question

Je suis sur le point de démarrer un nouveau projet qui devrait avoir une base de données plutôt volumineuse.

Le nombre de tables ne sera pas grand (< 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 ce tableau va augmenter de 500 000 enregistrements par jour , et nous devons en conserver au moins 1 an pour pouvoir faire divers rapports.

Il doit exister une base de données répliquée (en lecture seule) en tant que sauvegarde / reprise en ligne et éventuellement pour le déchargement des rapports en période de pointe.

Je ne connais pas très bien les bases de données volumineuses. Je demande donc à celles qui ont la meilleure base de données 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.

Answer 1

J'ai utilisé PostgreSQL dans un environnement dans lequel 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. Je ne peux donc pas parler de performances à long terme avec plus de ~ 100 millions de lignes.

J'ai constaté que les performances d'insertion étaient plutôt raisonnables, notamment si vous utilisiez la copie en bloc. Les performances des requêtes sont bonnes, bien que les choix du planificateur me posent parfois des problèmes. en particulier lorsque vous faites JOINS / EXISTS. Notre base de données nécessite un entretien régulier (VACUUM / ANALYZE) pour assurer son bon fonctionnement. Je pourrais éviter certaines de ces difficultés en optimisant plus soigneusement l'autovacuum et d'autres paramètres. Ce n'est pas vraiment un problème si vous ne faites pas beaucoup de DELETE. Dans l’ensemble, il ya des domaines dans lesquels il me semble plus difficile à configurer et à entretenir qu’il devrait être.

Je n'ai pas utilisé Oracle et MySQL uniquement pour de petits ensembles de données. Je ne peux donc pas comparer les performances. Mais PostgreSQL ™ fonctionne avec les grands ensembles de données.

Answer 2

Avez-vous une copie de " Le Data Warehouse Toolkit & Quot ;?

Nous vous suggérons de procéder comme suit.

1. Séparez les valeurs (mesurables, numériques) des dimensions qui qualifient ou organisent ces faits. Une grande table n'est pas vraiment la meilleure idée. Il s’agit d’une table de faits qui domine la conception, ainsi que d’un certain nombre de tables de petites dimensions permettant de & "Découper en tranches et découper en dés &"; les faits.

2. Conservez les faits dans de simples fichiers plats jusqu'à ce que vous souhaitiez créer des rapports de type SQL. Ne créez pas et ne sauvegardez pas une base de données. Créer et sauvegarder des fichiers; ne chargez une base de données que pour les rapports SQL à effectuer.

3. Dans la mesure du possible, créez un résumé ou des datamarts 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 votre conception de table, toutes les bases de données ont des outils de chargement en bloc qui peuvent renseigner et indexer les tables SQL à partir des fichiers.

Answer 3

La base de données BigTable de Google et Hadoop sont deux moteurs de base de données pouvant gérer une grande quantité de données.

Answer 4

La quantité de données (200 millions d’enregistrements par an) n’est pas très importante et devrait aller avec tout moteur de base de données standard.

L’affaire est encore plus simple si vous n’avez pas besoin de rapports en direct à ce sujet. Je mettrais en miroir et pré-agréger les données sur un autre serveur, par exemple. lot quotidien. Comme suggéré par S. Lott, vous voudrez peut-être vous renseigner sur l’entreposage de données.

Answer 5

Certains points intéressants concernant Google BigTable sont les suivants ...

Bigtable Vs DBMS

• Taux de requêtes rapides
• Pas de jointure, pas de support SQL , base de données orientée colonne
• Utilise une Bigtable au lieu d'avoir plusieurs tables normalisées
• n'est même pas dans 1NF dans une vue traditionnelle
• Conçu pour prendre en charge les requêtes historiques timestamp field = > à quoi ressemblait cette page Web hier?
• La compression des données est plus facile & # 8211; les lignes sont clairsemées

J'ai mis en surbrillance les jointures et l'absence de support SQL car vous avez dit que vous deviez 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 en cours d'exécution si vous voulez utiliser ceci.

Answer 6

Nous utilisons Firebird une très grande base de données (conservation des données depuis plus de 30 ans maintenant) et elle évolue très bien.

Le mieux, c'est que vous avez des propriétés à configurer, mais contrairement à Oracle, vous l'installez et cela fonctionne très bien sans qu'il soit nécessaire de commencer la configuration avant de pouvoir l'utiliser.