Discussion :

[soulriver]

Situation actuelle :

• Sybase 12.0.0.4
  Les applications appelent des vues (v1, v2...) qui tapent sur une table x.
  La table est composées de colonnes identifiantes, et de colonnes de valeur(col1, col2, col3....,coln).
  Les vues sont numérotées et en fonction de ces numéros, appelent les colonnes du même numéro (col id et coln) de la table x.
  Aujourd'hui la table x contient 750.000 lignes.

Nous devons intéger de nouvelles données. Malheureusement, le modèle actuel nous oblige a un subterfuge et engendre une augmentation importante du nombre de lignes dans la table x.
Elle devra contenir 4.500.000 lignes avec une progression constante annuelle de 700.000 ligne.

Nous risquons de nous heurter sérieusement à des problèmes de perf.

Il serait aussi possible en séparant ces données dans une table y de réduire le nombre de ligne à 8.000 (oui oui, vous avez bien lu, 8.000 lignes). Des vues seraient créer pour lire les données : vy1, vy2, etc... rapportant des colonnes identiques cod id, col1, col2...

Le problème, c'est qu'il est hors de question de modifier les applications existante pour orienter les requettes sur l'un ou sur l'autre type de vue.
La solution serait alors de faire une vue globale qui ferait un union sur les deux autres vues (vx1, vy1 par exemple, heu vous suivez ??? )
C'est là que se situe le problème : sybase 12 ne permet pas les union des les vues !!!! De plus on ne prevoit pas une migration vers sybase 12.5 avant quelques mois.

Comment faire ? J'avoue que je sèches...

[Fabien Celaia]

5 mio de lignes, c'est pas ingérable, dépendant de la largeur de la table...

Avec du Sybase, vous avez la possibilité de partitionner la table, ce qui vous amènera déjà pas mal d'air.

Ensuite, une possibilité à envisager serait de créer 2 tables avec 2 nouveaux noms, et une union de celles-ci avec une vue du nom de la table actuelle...

[soulriver]

5 mio de lignes, c'est pas ingérable, dépendant de la largeur de la table...

La table fait 205 colonnes dont 200 en int, 4 en smallint et 1 en datetime.
Sa taille actuelle est de 3.36Go (incluant les nouvelles lignes).

Avec du Sybase, vous avez la possibilité de partitionner la table, ce qui vous amènera déjà pas mal d'air.

Ensuite, une possibilité à envisager serait de créer 2 tables avec 2 nouveaux noms, et une union de celles-ci avec une vue du nom de la table actuelle...

Je suis d'accord avec tout ça, mais le problème est que le partitionnement n'est valable (AMHA) que sur la version 12.5 idem pour les unions dans les vues.
Il n'est pas encore question de migrer de version 12.0.0.4 => 12.5 (problèmes de budget).

[Fabien Celaia]

Non, je ne parle pas de clustering, je parle de partitionnement : c'est valable depuis belle lurette (dès la 11.0.3, mais efficace dès la 11.5, sauf erreur) sur Sybase, et dans le module de base via la commande

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

 ALTER TABLE ... PARTITON n

Pour n, choisissez selon

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

max(nobre d'engine pour ASE, Nombre de devices de data pour ladite base)

. ensuite, tentez d'influer sur max_parallel_degree et max_scan_parallel_degree.

[soulriver]

Meri, je vais essayer de tester ça rapidement.

Par contre je me demande où vont les nouvelles lignes lors des insertions. Dans le dernier partitionnement, là où il y a le plus de place ?
Quid des données triées en admettant que je créer une partition par année, que j'insère les anciennes lignes (triées) par bcp dans chaque partition ?
Je ne crois pas pouvoir diriger mon nouvel enregistrement vers telle ou telle partition.
Ce système de partitionnement nécéssite il une réorganisation régulière ? J'entends par bcp out/in de façon trié.

: : :

[Fabien Celaia]

Il n'y a pas de notion de clé de répartitions. Le découpage se fait suivant le type de table (hash ou cluster). Il va sans dire qu'une table clsuter ou il y aurait de nombreux inserts en suivant la clé cluster risquerait fortement de se trouver rapidement déséquilibrée. Du bon usage des indexes