IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

MS SQL Server Discussion :

Table de taille importante


Sujet :

MS SQL Server

  1. #1
    Candidat au Club
    Homme Profil pro
    Développeur Full Stack
    Inscrit en
    mars 2012
    Messages
    3
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Full Stack

    Informations forums :
    Inscription : mars 2012
    Messages : 3
    Points : 3
    Points
    3
    Par défaut Table de taille importante
    Bonjour,

    A priori, je suis amené à stocker des données dans une table SQL Server (environ 14 champs). Le contenu de cette table devrait être d'environ 11 000 000 de lignes par an pour une durée de 15 ans. Comment estimer les ressources matérielles nécessaires ? et surtout les performances SQL Server, sachant que des recherches vont être réalisées sur cette table (sur des champs de type date et/ou varchar) ? Quelles solutions existent afin d'améliorer ou de s'assurer des performances à venir ? Est-ce préférable de prévoir une table sur un an glissant et une seconde pour le stockage longue durée ? Faut-il s'orienter vers une autre solution que SQL Server ?

    Merci d'avance pour vos retours ou vos pistes

  2. #2
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    7 262
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 7 262
    Points : 23 095
    Points
    23 095
    Billets dans le blog
    2
    Par défaut
    Bonsoir

    11 millions de lignes par an sur 15 ans, soit 165 millions ce n'est pas gigantesque, si les critères de recherche sont filtrants et sargables *, la réponse peut être quasi immédiate.
    Par contre, avec une telle volumétrie, le partitionnement est recommandé.

    14 Colonnes (les champs n'existent pas dans les tables relationnelles) ce n'est pas beaucoup, mais surtout, il faut savoir quel est le type et la longueur de ces colonnes.
    Certains types sont très couteux en stockage (BLOB notamment), d'autres très économiques (small, int et bigint).

    SQL server supportera sans aucun souci cette volumétrie

    * Sargable : Search Argument Able prédicat correspondant à un ou plusieurs index et éligible pour ces index

  3. #3
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    mai 2002
    Messages
    20 774
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 20 774
    Points : 49 211
    Points
    49 211
    Billets dans le blog
    1
    Par défaut
    Pas forcément besoin de partitionnement, mais je recommanderais que la table, si elle est unique soit mise en clustered columnstore, ce qui améliore considérablement les performances (en général division par 4 à 20 des temps de réponse par rapport aux index traditionnels).

    Voir cependant de quelle édition de SQL Server il s'agit. En effet, mieux vaut utiliser SQL Server 2019, mais l'édition Standard limite à 32 Go les index columnstore.... Bon, comme les index columstore sont naturellement compressés (3 à 10 fois moins volumineux), je pense que cette limitation avec une table de moins de 200 millions de ligne et 15 colonnes, ne sera jamais atteinte !

    Pour information, voici la différence pour une table de 1 250 000 lignes et 17 colonnes en version normale (clustered BTree) et clustered columnstore:
    Nom : table storage clustered vs columnstore.jpg
Affichages : 44
Taille : 142,7 Ko
    On y voit que le stockage occupe 42 Mo... au lieu de 251 soit un ratio de compression de 6...

    Avec 300 millions de ligne cette table occuperait moins de 12 Go (la compression n'étant pas linéaire, plus la table a de lignes, plus la compression est importante !). Donc loin de la limite des 32 Go...


    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  4. #4
    Candidat au Club
    Homme Profil pro
    Développeur Full Stack
    Inscrit en
    mars 2012
    Messages
    3
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Full Stack

    Informations forums :
    Inscription : mars 2012
    Messages : 3
    Points : 3
    Points
    3
    Par défaut
    Super, merci pour vos retours ! je vais étudier le partitionnement et le clustered columnstore.

    Je me demande aussi comment estimer les capacités serveur (CPU/RAM) ?

  5. #5
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    mai 2002
    Messages
    20 774
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 20 774
    Points : 49 211
    Points
    49 211
    Billets dans le blog
    1
    Par défaut
    Le CPU est plus fonction du nombre de users et de transactions.
    La Ram si base parfaitement modélisée 10%, modéle à chier 120 %

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

Discussions similaires

  1. Limitations d'une table (index & taille)
    Par joefou dans le forum SQL
    Réponses: 8
    Dernier message: 09/01/2008, 15h21
  2. Recherche Hébergement multiFTP de taille importante
    Par benco3333 dans le forum Hébergement
    Réponses: 5
    Dernier message: 12/03/2007, 18h22
  3. Réponses: 1
    Dernier message: 15/02/2007, 15h11
  4. Création de Table de taille fixe
    Par PierrotY dans le forum PostgreSQL
    Réponses: 9
    Dernier message: 12/07/2006, 14h33
  5. Taille importante de base de donnee liee
    Par therewillbealight dans le forum Access
    Réponses: 3
    Dernier message: 20/06/2006, 10h27

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo