Discussion :

[LEK]

Bonsoir,
je suis en train de découvrir Oracle et je me pose certaines questions sur les partitions :
- Si je possède une appli web multi-clients pour laquelle je n'ai qu'une seule base (par design je suis obligé de n'avoir qu'1 seul schéma) : sachant que je peux supporter au maximum 200 clients, est il possible de créer une table avec une partition par client ? (Dites le moi si c'est ridicule comme question ;-))
- Existe-t-il un concept de sous-partition ?

Merci.

[dariyoosh]

Bonjour,

sachant que je peux supporter au maximum 200 clients, est il possible de créer une table avec une partition par client ?

Je pense qu'il faudrait peut-être détailler un peu plus et dire ce que vous entendez exactement par le mot partition dans ce contexte.
(au niveau de quelle(s) table(s) et pour quoi faire exactement ?)

Le problème, tel que vous le présentez me semble être un problème de charge et performance et d'après ce que vous dites votre applications ne peut supporter plus que 200 clients. Ne serait pas plutôt un compteur qu'il faudra mettre au niveau du serveur d'application qui compte le nombre des utilisateurs connectés?

Existe-t-il un concept de sous-partition ?

Pour ma part, ce que je connais côté partition en oracle, c'est partitionner une table.

http://docs.oracle.com/cd/B28359_01/.../partition.htm

Je vous ai donné le lien à titre indicatif, mais je ne pense pas que ça soit la solution à votre problème, à moins que vous ne souhaitiez vraiment partitionner vos tables en fonction des critère par exemple sur certains rangs de données (ce qui peut être intéressant dans le cadre d'amélioration de la performance des requêtes sur des tables ayant une très grande volumétrie de données).


Cordialement,

[LEK]

Merci de votre réponse.
Effectivement les questions que je me posent concernent entre autres les performances : en fait c'est une appli web multiclient (multitenant si vous préférez) avec pour persistance une base oracle 10g dans un schéma unique. L'ensemble des clients utilisent donc la même base mais les données sont actuellement cloisonnées de manières applicatives pour que chacun ne puisse altérer les données du voisin (Je sais qu'il aurait été possible d'utiliser plusieurs schéma identiques ou reposer sur les virtual private database pour arriver à ce résultat).
Cette appli est accessible à des clients grands comptes particuliers et seul 200 peuvent en bénéficier (c'est plus commercial que technique! )
En base de données les champs discriminants les données de chaque client sont indexés. Et le fait est que ceux-ci effectuent des imports/exports massifs de leur données régulièrement en fin et début d'année.
Je me demandais donc pourquoi le ne pas utiliser le concept des partitions pour en créer une par client :
- du coup je me dis que les performances liés à l'indexation seraient améliorées
- et j'imagine que pour ce qui est des exports/imports en masse la ségrégation par partition doit aider...

Voilà... Je parlais donc bien de partitions oracle (comme lorsque l'on historise les données par années)...
Je me doutais que mes questions pouvaient paraître assez larges et ingénues mais au stade des lectures et tests que j'ai pu faire, je suis encore un grand newbie dans le domaine.

[dariyoosh]

... Cette appli est accessible à des clients grands comptes particuliers et seul 200 peuvent en bénéficier (c'est plus commercial que technique! ) ...

Vous souhaitez créer 200 partitions sur une table ordinaire??
Non, je pense que votre problème est un problème des partitions logiques (je dis logique au sens de la logique de votre applications et les périmètres fonctionnels qu'elle définis) et pas vraiment au niveau physique (c'est à dire au niveau des tables oracle). Pour moi ça passe par des développements PL/SQL ainsi que les éléments de sécurité oracle (GRANT, création de rôle si nécessaire, etc.).

http://docs.oracle.com/cd/E11882_01/...s.htm#CHDFEBAB


Cordialement,

[pachot]

Bonjour,
Oui, c'est une très bonne idée de partitionner pour cette problématique à condition d'être en Entreprise Edition bien sûr car l'option partitioning n'est pas en Standard Edition.

D'une part c'est mieux que plusieurs schemas pour des raisons de performances car lancer des requêtes identiques (même texte SQL) sur 200 schemas différents va amener une contention en shared pool.

Par contre, le partitionnement n'amènera qu'une isolation physique. Si on veut sécuriser pour qu'un client n'accède qu'à ses données il faut passer par des vues ou par une virtual Private Database.

Mais je confirme ces 2 points:

- du coup je me dis que les performances liés à l'indexation seraient améliorées

Oui car les index seront définis comme index LOCAL, c'est à dire qu'ils seront aussi partitionnées comme la table. Ils seront donc plus petits.

- et j'imagine que pour ce qui est des exports/imports en masse la ségrégation par partition doit aider...

Oui, car un full table scan pourra ne lire qu'une seule partition.

il y a un autre gain de performance très important: les jointures peuvent se faire partition par partition, nécessitant de travailler sur moins de données à la fois.

Il y a aussi un autre gain: la répartition/volume de données est peut-être très différent pour chaque client. Du coup, le partitionnement va permettre d'avoir des statistiques (utilisables par l'optimiseur) plus précises.

Et il y a le gain en terme de maintenance. s'il y a une opération de maintenance à faire (genre bouger une table vers un autre tablespace) elle peut se faire client par client. C'est un avantage s'ils ont des fenêtres de maintenance différents.

Ce qu'il faut pour tout ça, c'est avoir dans chaque table une colonne qui discrimine le client. Ce n'est pas toujours nécessaire en 11g car on peut partitionner une table fille à travers de la contrainte d'intégrité référentielle, mâme si le discriminant n'est que dans la table fille et pas dans la table mère.

Existe-t-il un concept de sous-partition ?

Oui. Ce qui permet par exemple d'avoir une table partitionnée par client et par date. Chaque partition contiendra par exemple une plage de date pour un client.

Cordialement,
Franck.

[mnitu]

Bonjour,
Oui, c'est une très bonne idée de partitionner pour cette problématique ...

Pas forcement. Ca dépende aussi de la volumétrie des données.

[pachot]

Bonjour,

Pas forcement. Ca dépende aussi de la volumétrie des données.

Sur des faibles volumétries, on ne verra peut-être pas la différence sur temps de réponse. Mais c'est toujours bien d'avoir un design scalable. Un jour, il y aura peut-être beaoucp plus de données. Un jour, il y aura peut-être 2000 clients au lieu de 200...
Cordialement,
Franck Pachot

[LEK]

Merci à vous pour ces réponses.
La volumétrie actuelle approche le giga entre autres car il y a de nombreuses données historisées (modèle bitopemporel pour se la péter).
Je n'avais pas vu par contre le fait qu'il fallait changer de licence (!).

Merci encore de votre aide et bonne soirée,
Lek.

[LEK]

Pacho merci pour tes réponses... et pour les articles traduits sur ton blog : intéressant!

[mnitu]

@pachot
Telle que vous le dit tous les tables devraient être partionnnées juste au cas où ! Or le partitionnement comme toute autre fonctionnalité apporte des améliorations en certaines cases et empire les choses dans les autres.

[pachot]

@pachot
Telle que vous le dit tous les tables devraient être partionnnées juste au cas où ! Or le partitionnement comme toute autre fonctionnalité apporte des améliorations en certaines cases et empire les choses dans les autres.

Ah non, je n'ai jamais dit ça ! Au contraire, je crois avoir essayé de mettre les principales raison liées à ce contexte, pour que LEK puisse valider que j'ai bien compris son contexte.

Ici, il s'agit de données appartenant à des contextes séparées (pour 200 'clients'), interrogées et manipulées pour chaque contexte, mais ayant le même modèle de données. Ce n'est pas un conseil 'au cas où', mais pour ce cas précis !

[Drizzt [Drone38]]

Merci à vous pour ces réponses.
La volumétrie actuelle approche le giga entre autres car il y a de nombreuses données historisées (modèle bitopemporel pour se la péter).
Je n'avais pas vu par contre le fait qu'il fallait changer de licence (!).

Merci encore de votre aide et bonne soirée,
Lek.

C'est tout petit une volumétrie de l'ordre du giga...
Si c'est bien indexé comme il faut tu ne devrais pas avoir de problèmes de perfs.

Faire 200 partitions pour une telle volumétrie me parait un peu démesuré...