Conception de base de données pour les grandes tables

Question

J'ai essayé d'examiner des questions existantes semblables aux miennes, mais je n'ai pas réussi à trouver une réponse claire. Je travaille à une grande coorporation où nous avons un gros datawarehouse (des milliards de lignes), mais qui est super lent et pas vraiment adapté pour l'analytique ad hoc - nous regardons quelque chose de nouveau, mais l'horizon de temps est quelques années à partir de maintenant; que je (et mon département) ne peut pas vraiment attendre. Par conséquent, une nouvelle base de données SQL Server 2014 vide m'a été attribuée, dans laquelle je stockerai des informations de notre entrepôt de données que nous utiliserons souvent. Nous allons accéder à ces données principalement par le biais d'outils d'analyse tiers, qui ne mettent pas en cache les données, mais y accèdent directement chaque fois que vous cliquez ou ajoutez un nouveau graphique, etc .; Nous avons donc besoin de performances pour être aussi rapide que possible, car il est très frustrant d'attendre longtemps chaque fois que vous ajoutez une nouvelle dimension à un graphique.

Je me base sur les données de notre datawarehouse dont la structure/conception est habituellement assez bien; Cependant, certaines choses que je trouve ennuyeuses (par exemple le nom d'un client est stocké avec un ID-date, ce qui signifie que si vous regardez un client, vous verrez son nom changer au fil du temps - pour mes besoins analytiques cela n'a aucun sens. pour garder les noms (et les autres dimensions) constants remontant dans le temps

Actuellement, les données ne sont pas vraiment divisées en faits et en dimensions, mais plutôt quelque chose entre Je pense à restructurer les données en faits et dimensions Par exemple, le nom du client ne figure pas dans la table financière, mais plutôt dans un tableau de dimensions, ce qui fait que je reçois toujours le même nom

Ma question est la suivante: Diviser les données en faits et en dimensions ralentir la performance comp est d'avoir tout dans une grande table avec toutes les informations (colonnes) sur toutes les lignes? Les jointures vont-elles ralentir ma requête?

Je travaille avec des données mensuelles de 10-15 millions de lignes = 120-180 millions de lignes par an, pendant 3-6 ans = maximum d'environ 1 milliard de lignes (maximum absolu).

Cela avait-il un sens?

Merci.

/Steffen.

Answer 1

Il est préférable de modéliser en tant que faits et dimensions, ce qui aidera votre couche de reporting à interroger plus rapidement. Cela dit, il est très important sur la façon dont nous concevons les tables de dimension et les tables de faits. L'idée typique est d'avoir des types d'entiers comme clé dans la dimension et vous aurez la flexibilité de gérer le type I qui change lentement, le type II dans le futur.

faits Designing a aussi son importance, la majorité des problèmes sont dus à IO afin que vous puissiez envisager Indexes columnstore pour faits afin que vos données seront compressées et vous aurez des performances plus rapides, passer par ce lien pour une meilleure compréhension:

ColumnStore Index