Architecture d'une base de données avec beaucoup de dossiers

Je dois construire un service pour différents types de populations. Ce service contient un portail web et un service web (interrogé par smartphones) qui contiendra beaucoup d'enregistrements. Chaque population a son propre ensemble d'enregistrements, peu d'enregistrements sont partagés entre les populations. Chaque population aura ses événements, nouvelles, utilisateurs ... Beaucoup d'utilisateurs utiliseront ce service, les tables de base de données (qui contiendront ces événements, nouvelles et utilisateurs) se développeront rapidement. Il y aura 100 fois plus de sélections que d'insertions dans ce tableau. Enfin, j'ai prévu d'utiliser MySQL comme moteur de base de données.Architecture d'une base de données avec beaucoup de dossiers

Ma question est une question d'architecture:

Est-il préférable d'avoir des tables communes pour toutes les populations (une nouvelles de table unique, un événement de table unique ... pour toute la population) et une colonne permettant à filtrer ? Ou vaut-il mieux avoir une base de données unique par population (chaque population a son propre tableau d'événements, sa propre table de nouvelles ...)?
Comment traiter un objet partagé si une architecture de base de données par population est optimisée?

Merci pour vos conseils et recommandations!

kheraud

Source

2011-06-28 iwalktheline

Avez-vous étudié une base de données unique et des tables différentes pour différentes populations? C'est à dire. Event_Pop_A, Event_Pop_B ... News_Pop_A ... en fonction de votre scénario d'utilisation, cela peut aider dans les cas où vous devez faire des requêtes inter-population (en utilisant UNION par exemple) –

Non, je ne l'ai pas fait. Il semble très difficile à maintenir/administrer mais la solution pourrait fonctionner – iwalktheline

Cela dépend de la fréquence à laquelle vous créez une nouvelle population. Si c'est quelque chose que vous pouvez imaginer arriver beaucoup, alors ma suggestion n'est pas pratique. Si l'ensemble de la population est stable et qu'il y a peu ou pas de mouvement d'utilisateurs d'une population à l'autre, alors cela peut fonctionner –

Vous pouvez avoir une seule table pour chacune des nouvelles, des événements, etc., qui contiendra toute la population avec une colonne qui différenciera la population et vous pouvez appliquer une partition sur cette colonne. De cette façon, votre haute fréquence sélectionne sur la population accédera seulement à la partition correspondante et pas tous. Vous pouvez également opter pour l'indexation partitionnée.

vous pouvez vous référer à cette partition pour Mysql http://dev.mysql.com/doc/refman/5.1/en/partitioning-overview.html

À propos des colonnes partagées je suppose que si le pourcentage d'actions est moins vous pouvez dupliquer les lignes, sinon vous finirez par accéder à plus d'une partition pour une requête.

Source

2011-06-28 15:44:01

Architecture d'une base de données avec beaucoup de dossiers

Répondre

Questions connexes