DB Stratégie d'insertion dans une table de lecture haute (SQL Server)

Question

Si vous recherchez des stratégies pour une très grande table avec des données conservées à des fins de reporting et historiques, un très petit sous-ensemble de ces données est utilisé dans les opérations quotidiennes.

Contexte:

Nous avons des tables des visiteurs et des visites qui sont continuellement mis à jour par notre site face à la consommation. Ces tableaux contiennent des informations sur chaque visite et visiteur, y compris les bots et crawlers, le trafic direct qui n'aboutit pas à une conversion, etc.

Notre site dorsal permet la gestion du (s) site (s) du visiteur à partir du site frontal. La plupart de la gestion se produit sur un petit sous-ensemble de nos visiteurs (visiteurs qui deviennent des prospects). La grande majorité des données de nos tables de visiteurs et de visites est conservée uniquement pour un sous-ensemble beaucoup plus petit d'activité de l'utilisateur (essentiellement la fonctionnalité de type de rapport). Ce n'est pas un problème d'indexation, nous avons fait tout notre possible en indexant et en gardant nos index propres, petits et non fragmentés.

ps: Nous n'avons pas actuellement le budget ou l'expertise pour un entrepôt de données.

Le problème:

Nous aimerions que le système soit plus sensible à nos utilisateurs finaux quand ils s'interrogent, par exemple, la liste de leurs prospects assignés. Actuellement, la requête est contre un énorme ensemble de données de données principalement non pertinentes.

Je réfléchis à quelques idées. L'un implique de nouvelles tables et une ré-architecture assez importante, je ne demande pas d'aide à ce sujet. L'autre consiste à créer des données redondantes, (par exemple une table Visitor_Archive et une table Visitor_Small) où les tables de visiteurs et de visites les plus volumineuses existent pour les insertions et l'historique/rapports, la table visitor1 plus petite existe pour gérer les leads, envoyer un mail nombre, besoin de ma liste de prospects, etc ..

la raison pour laquelle je tends la main est que j'aimerais avis sur la meilleure façon de garder le Visitor_Archive et les tables Visitor_Small synchronisés ...

réplication? Puis-je utiliser la réplication pour répliquer uniquement les données avec une certaine valeur de colonne (FooID = x)

Toutes les autres stratégies?

Answer 1

Il semble que votre table soit un candidat idéal pour le partitionnement. Puisque vous ne l'avez pas mentionné, je vais le décrire brièvement, et vous donner quelques liens, au cas où vous ne le sauriez pas.

Vous pouvez diviser les lignes d'une table/index sur plusieurs périphériques physiques ou logiques, et est spécifiquement destiné à améliorer les performances des ensembles de données où vous pouvez avoir besoin d'un sous-ensemble de données à tout moment.Partitionner une table vous permet toujours d'interagir avec une table unique (vous n'avez pas besoin de référencer des partitions ou quoi que ce soit dans vos requêtes), mais SQL Server peut effectuer plusieurs optimisations sur des requêtes qui impliquent seulement une partition des données. En fait, dans Designing Partitions to Manage Subsets of Data, les exemples AdventureWorks correspondent à peu près à votre scénario exact.

Je ferais un peu de recherche, en commençant ici et en descendant: Partitioned Tables and Indexes.

Answer 2

Solution simple: créer une table séparée, dénormalisée, avec tous les champs qu'elle contient. Créer une procédure stockée, qui mettra à jour cette table sur votre calendrier. Créez un travail SQl Agent pour appeler le SP.

Indexez le tableau comme vous le voyez dans la requête.

Si vous devez purger l'historique, créez un autre tableau pour le contenir et un autre SP pour le remplir et nettoyer la table de rapport principal.

Vous pouvez vous retrouver avec plusieurs tables de rapports - c'est OK - l'espace est bon marché ces jours-ci.