none
table volumineuse RRS feed

  • Discussion générale

  • Salut tout le monde, 

    j'utilise une table qui commence à devenir lourde : 10.000.000 d'enregistrements ( 100.000 par mois ), et qui est consultée à longueur de journée par plusieurs utilisateurs (environ 150 utilisateurs). 

    Pour les recherches 'simples', çà ne pose pas encore de problème ; par contre, dès qu'il y a ajout ou suppression d'enregistrement, là çà commence à grincer, et toute requête un peu plus fine ( GROUP BY ) prend une éternité ... 

    Je me dis donc : pourquoi ne pas scinder cette table en plusieurs tables ? Je devrais y gagner en rapidité d'éxécution ! 
    Mais la gestion de ces tables à la place d'une seule me parait un poil plus compliquée ... 

    Qlq'un connait ce problème de volumétrie ? 
    Quels choix faire ?
    mardi 3 mai 2016 14:44

Toutes les réponses

  • Salut,

    Est ce que tu peux nous presenter la structure de ta table?

    Quels genres de requetes sont effectuées sur cette table?

    j'aurai surement d'autres questions par la suite ;)


    Please mark this reply as answer if it solved your issue or vote as helpful if it helped so that other forum members can benefit from it

    mardi 3 mai 2016 15:57
  • Bonjour, La bonne nouvelle c'est que vous pouvez effectuer des requêtes simples et que cela ne pose pas encore de problèmes.

    Cela veut dire que vos indexes sont pertinents pour ces requêtes. 

    Lors de l'ajout ou de modifications des enregistrement si cela est lent c'est surement parce que l'ajout ou la modification entraîne une modification de l'index et que c'est celui-ci qui est lent. 

    Votre réflexion sur le découpage de la table peut être un partitionnement. Cela permet d'être transparent du point de vue de vos requêtes et permet de stocker vos données dans différents fichiers en même temps (en laissant le moteur SQL s'en occuper). Par contre, comme le suggérait Remi, il faudra alors connaitre la structure exacte de votre table et les requêtes qui seront exécutées pour proposer une solution.

    Cordialement,  

    Kevin BEAUGRAND, Modis FRANCE
    Merci de bien vouloir "Marquer comme réponse", les réponses qui ont résolu votre problème.

    mardi 3 mai 2016 16:22
  • La structure du la table est 

    CREATE TABLE [dbo].[tra_tiers_details](
    	[DET_ID] [bigint] IDENTITY(1,1) NOT NULL,
    	[DET_TRA_ID] [bigint] NOT NULL,
    	[DET_LOT_ID] [bigint] NOT NULL,
    	[DET_QTE] [bigint] NULL,
    	[DET_QTE_OLD] [bigint] NULL,
    	[DET_QTE_MOV] [smallint] NULL,
    	[DET_REM] [decimal](12, 2) NULL,
    	[DET_ANU_ID] [int] NULL,
    	[DET_AGENT_ID] [int] NULL,
    	[DET_CREATED] [datetime] NOT NULL,
    	[DET_UPDATED] [datetime] NOT NULL,
     CONSTRAINT [tra_tiers_details_PRIMARY] PRIMARY KEY CLUSTERED 
    (
    	[DET_ID] ASC
    )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = ON, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 80) ON [PRIMARY]
    ) ON [PRIMARY]
    
    GO
    
    ALTER TABLE [dbo].[tra_tiers_details]  WITH CHECK ADD  CONSTRAINT [FK_DET_LOT_ID] FOREIGN KEY([DET_LOT_ID])
    REFERENCES [dbo].[stk_lots] ([LOT_ID])
    ON UPDATE CASCADE
    GO
    
    ALTER TABLE [dbo].[tra_tiers_details] CHECK CONSTRAINT [FK_DET_LOT_ID]
    GO
    
    ALTER TABLE [dbo].[tra_tiers_details]  WITH CHECK ADD  CONSTRAINT [FK_DET_TRA_ID] FOREIGN KEY([DET_TRA_ID])
    REFERENCES [dbo].[tra_tiers] ([TRA_ID])
    ON UPDATE CASCADE
    ON DELETE CASCADE
    GO
    
    ALTER TABLE [dbo].[tra_tiers_details] CHECK CONSTRAINT [FK_DET_TRA_ID]
    GO
    
    CREATE NONCLUSTERED INDEX [FK_DET_LOT_ID] ON [dbo].[tra_tiers_details]
    (
    	[DET_LOT_ID] ASC
    )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = ON, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 80) ON [PRIMARY]
    GO
    
    CREATE NONCLUSTERED INDEX [FK_DET_TRA_ID] ON [dbo].[tra_tiers_details]
    (
    	[DET_TRA_ID] ASC
    )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = ON, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 80) ON [PRIMARY]
    GO
    
    ALTER TABLE [dbo].[tra_tiers_details] ADD  CONSTRAINT [tra_tiers_details_PRIMARY] PRIMARY KEY CLUSTERED 
    (
    	[DET_ID] ASC
    )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = ON, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 80) ON [PRIMARY]
    GO
    
    
    

    on fait des requete select / insert / update / delete / en même temps avec plusieurs utilisateurs (minimum 20 utilisateurs on production). car cette table est du détails du facturation.

    cette table est on augmentation par plus 9000 ligne par jour. 



    • Modifié abdelhek mercredi 4 mai 2016 11:29
    mercredi 4 mai 2016 11:26
  • Re,

    Avec le temps qui passe, certaines lignes ne sont plus jamais interrogées.

    Si c'est une table de détails de facturation, tu dois surement pouvoir "archiver" certaines lignes afin d’alléger tes requêtes sur les données récentes.

    Pour tes requêtes de select, passe par une vue qui agrégera les données des 2 tables, celle contenant les données chaudes (tes données les plus recentes et les plus interrogées) et les données d'archives.

    A dispo si besoin


    Please mark this reply as answer if it solved your issue or vote as helpful if it helped so that other forum members can benefit from it

    mercredi 4 mai 2016 12:31
  • salut

    Tous les requête select passe par un Vue mais on ne peut pas archiver des lignes, car on a besoin de tous les lignes de la table dans notre traitement. 

    mercredi 4 mai 2016 14:47
  • Re,

    dans votre traitement?

    Tu entends quoi par la?


    Please mark this reply as answer if it solved your issue or vote as helpful if it helped so that other forum members can benefit from it

    mercredi 4 mai 2016 14:56
  • Re,

    dans le traitement de facturation on a besoin d'une facture d'achat globale ou détaillée selon la demande de client. et donc dans ce cas la on a besoin de toute la table

    mercredi 4 mai 2016 15:28
  • Oui, je suis d'accord avec toi.

    Cependant,

    combien de ligne dans ta table n'ont pas été mises a jour dans le dernier mois, dans le dernier semestre, dans la dernière année?

    Je pense que ça doit représenter un pourcentage non négligeables de lignes.

    Généralement les données chaudes sont les plus récentes, les détails de factures de l'années 2013 on moins de probabilité de se faire mettre à jour. :D

    Sinon il faut modifier ton modèle de données (comme tu le disais dans ton post originel) afin de faire une partition physique de tes données.

    Une table par mois, ou par année.



    Please mark this reply as answer if it solved your issue or vote as helpful if it helped so that other forum members can benefit from it

    mercredi 4 mai 2016 15:39
  • Re,

     Merci

    mais toute les lignes sont de l'année 2015  et 2016

    mercredi 4 mai 2016 16:09
  • Salut

    Quel est la solution optimal de notre problème????

    Merci!...

    jeudi 5 mai 2016 16:26
  • Pour moi je le ferai comme ça :

    1. Identifier/optimiser les requêtes qui interrogent le modèle de données

    2. Si ça ne marche pas, partitionner ta table en plusieurs petites tables afin de diminuer la pression exercée et donc augmenter ta vitesse de traitement.

    Ce n'est que mon avis. Il y a peut etre d'autres moyens de le faire, mais la comme ca, il n'y a que ca qui me vient en tete.

    En esperant que ca puisse t'aider


    Please mark this reply as answer if it solved your issue or vote as helpful if it helped so that other forum members can benefit from it

    vendredi 6 mai 2016 07:49
  • Bonjour, 

    Malheureusement, il sera difficile pour nous de vous trouver une solution comme cela via un forum. 

    L'optimisation de ce genre de traitement dépends de tellement de facteurs qu'il faut un temps assez significatif pour analyser tester et mettre en place une solution.

    Nous pouvons vous donner des pistes (que nous avons déjà donné), mais pas de solution exacte. Il appartient à vous d'analyser ces solution, de les comprendre et d'estimer laquelle est la plus pertinente.

    Voici en général la manière de travailler que j'ai pu remarquer dans l'ordre : 

    - Optimiser les indexes -> action rapide, avec peu d'impacts,

    - Optimiser les requêtes -> action assez rapide, mais risques de régressions,

    - Optimisation de l'infrastructure (Ajout de disque SSD, augmentation de la RAM, CPU, ...) -> Action assez rapide, coûteux mais n'élimine pas le problème de fond (s'il y en a un)

    - Optimisation du modèle de données (Partitionnement logique, Partitionnement  physique, ...) -> Action relativement longue, risque de régression, mais efficace dans le temps

    - Changement de stockage (Big Data, ...)

    Voila toutes les pistes que j'envisagerais, maintenant reste à vous d'estimer laquelle de ces solutions vous pourriez envisager. 

    P.S : pour ce genre de problème, n'hésitez pas non plus à faire appel à des experts qui sauront étudier le problème plus en profondeur et vous proposer une solution complète en fonction de vos contraintes. Même si cela a un coût, parfois cela dépanne. 

    Cordialement, 


    Kevin BEAUGRAND, Modis FRANCE
    Merci de bien vouloir "Marquer comme réponse", les réponses qui ont résolu votre problème.

    samedi 7 mai 2016 12:01
  • Merci BEAUGRAND Kevin 

    samedi 7 mai 2016 13:25