Meilleure façon de stocker un grand nombre de datarow pour interroger

Quel est le meilleur moyen de stocker un grand nombre (plusieurs millions) d'enregistrements utilisés pour créer des rapports? La nature de l'application exige que chaque enregistrement correspondant à une recherche soit envoyé à l'application pour traitement, de sorte que la vitesse d'exécution de la requête et la vitesse de transfert de la requête sont des facteurs importants pour nous.Meilleure façon de stocker un grand nombre de datarow pour interroger

Actuellement, notre application stocke les enregistrements dans une table MSSQL droite fortement indexée pour les performances de requête. Est-ce que quelqu'un a d'autres idées de stockage ou est-ce qu'une base de données relationnelle convient bien à cela, même si nous ne pouvons stocker des enregistrements que dans un seul tableau puisque les données ne sont pas relationnelles en soi?

La solution SQL nous donne de très bonnes performances mais je suis intéressé s'il existe d'autres alternatives de backend, par exemple les bases de données NoSQL sont-elles une solution valable pour commencer à chercher?

Nos requêtes sont effectuées sur un petit nombre de colonnes mais les résultats peuvent varier en taille (nombre de lignes nécessaires pour chaque exécution en fonction de la période et d'autres paramètres).

Merci d'avance de m'avoir aidé à avoir de nouvelles perspectives à ce sujet.

Puisque nous sommes un magasin .NET, toutes les solutions/idées qui conviennent aux serveurs .NET et Windows sont un grand avantage pour nous, mais j'apprécie toutes les contributions que je peux obtenir à ce sujet. Et par les solutions, je veux dire un autre backend que MSSQL ou autre relation-dbs?

Source

2013-04-12 jmw

Ne pas suivre. "ne peut stocker des enregistrements que dans une seule colonne car les données ne sont pas relationnelles" "Nos requêtes sont faites sur un petit nombre de colonnes" Si les enregistrements sont dans une colonne, comment interrogez-vous plus de 1 colonne? – Paparazzi

Je suis vraiment désolé, il devrait dire "une table". Le message est maintenant modifié. Merci de l'avoir signalé. – jmw

L'efficacité de requête est basée sur la requête et les indices

Pour transférer les données au client:

Juste un DataReader tout droit est très efficace
Drapper est aussi rapide, mais je pas utilisé

J'ai eu une interprétation valide que les résultats de la requête doivent être enregistrés pour être réexécutés
La requête est exécutée une seule fois

Data 
int ID iden 
varchar Value1 
varchar Value2 

SavedQuery 
int ID iden 
varchar name 

SavedQueryResults 
int QueryID PK 
int DataID PK 

Select [Data].[Value1], [Data].[Value2] 
From [Data] 
Join [SavedQueryResults] 
    on [SavedQueryResults].[DataID] = [Data].[ID] 
and [SavedQueryResults].[QueryID] = x

Avec le PK sur SavedQueryResults cela devrait se traduire par un indice cherchent et ne peut pas faire mieux que cela.

Lorsque vous créez les SavedQueryResults utilisent l'ordre par DataID dans l'insert pour maintenir la fragmentation vers le bas

Source

2013-04-12 13:29:37 Paparazzi

Voir mise à jour ..... – Paparazzi

Ok, cela semble être une bonne solution, mais dans mon cas, quand un rapport est fait pour un ensemble de données, le résultat traité des données est sauvegardé dans l'application (en tant que résultat agrégé). la même requête n'est presque jamais exécutée plus d'une fois. Sinon, je pense que cela aurait été une bonne solution.Mais est-ce que je comprends que vous corrigez cela pour stocker les données dans une table mssql est une solution "valide" pour mon cas, même s'il existe des moyens d'accélérer la performance des requêtes avec des solutions comme celle que vous avez décrite? – jmw

Vous devriez mettre cela dans la question. Exécuter une fois est une optimisation totalement différente. Je lis les magasins d'applications "eux" comme le rapport. – Paparazzi

Pourquoi ne vous avoir deux ou trois tableaux de rapport, mis à jour avec des déclencheurs, il serait beaucoup plus efficace. Identique aux modèles de vue dans le monde CQRS.

Source

2013-04-12 16:27:13 Marco

Pouvez-vous élaborer sur vous répondre un peu? Pourquoi serait-ce une meilleure solution pour ce cas, je ne comprends pas le bénéfice? – jmw

Combien de tables devez-vous joindre pour obtenir les rapports? Et en fonction du verrou de table que vous utilisez, lorsque vous exécutez ces requêtes, vous risquez de réduire les performances de l'ensemble du système. Que faire si deux clients demandent le même rapport? Les modèles de vue fonctionnent comme des tables de mise en cache qui ont les données exactes dont le rapport a besoin, donc si le client le demande, il est juste là immédiatement. – Marco

Il n'y a que sur la table où se trouvent toutes les données du rapport. Et chaque rapport (requête) est presque toujours exécuté une seule fois, donc je ne pense pas qu'une approche de "mise en cache" soit juste pour nous. Puisque dans notre cas un enregistrement ne change jamais une fois qu'il est dans la table et que les lectures non répétables etc. ne sont pas un problème dans notre application, nous n'avons besoin d'utiliser aucune ligne ou table lors de la lecture (LIRE INCORRECT). – jmw

Meilleure façon de stocker un grand nombre de datarow pour interroger

Répondre

Questions connexes