root/traduc/trunk/slony/partitioning.xml

<?xml version="1.0" encoding="UTF-8"?>
<!-- DerniÚre modification
     le       $Date$
     par      $Author$
     révision $Revision$ -->

<sect1 id="partitioning">
<title>Support du partitionnement </title>
<indexterm><primary>partitionnement</primary></indexterm>

<para> &slony1; ne supporte pas directement la méthode de partitionnement
  par héritage de &postgres;, cependant il n'empêche pas non plus les
  utilisateur de répliquer de tels héritages et ainsi que les tables 
  qui y sont associées.</para>

<para> Un des tests du <xref linkend="testbed"/>, appelé 
<filename>testinherit</filename>, vérifie que &slony1; se comporte
comme prévu lors de la réplication de données partitionnées. Ce test
crée une table maître <envar>sales_data</envar> dont plusieurs tables filles héritent : </para>

<itemizedlist>
<listitem><para> <envar>us_east</envar></para> </listitem>
<listitem><para> <envar>us_west</envar></para> </listitem>
<listitem><para> <envar>canada</envar></para> </listitem>
</itemizedlist>

<para> Cet exemple est un peu simpliste car il fournit uniquement des rÚgles
  d'insertion dans les différentes partitions; il ne permet pas de migrer des 
  tuples d'une partition à une autre si ils sont modifiés via une commande 
  <command>UPDATE</command> statement.  D'un autre coté, à la différence de 
  de beaucoup de partitionnement, celui-ci permet à la table <quote>parente</quote>
  de contenir des tuples. </para>

<para> On peut remarquer quelques points intéressants :</para>

<itemizedlist>
<listitem><para> Chaque table de partition doit être ajoutée à la réplication individuellement. </para> </listitem>
<listitem><para> &slony1; n'est pas conscient des relations entre les tables de partition; il les considÚre comme
    une série de tables indépendantes. </para> </listitem>
</itemizedlist>


<sect2><title> Support de l'ajout dynamique de partition</title>

<para> Un <quote>cas d'utilisation</quote> fréquent de la réplication consiste 
  à partitionner de large ensemble de données selon un critÚre temporel : la semaine,
  le moins, le trimestre ou l'année, ce qui implique par conséquent l'ajout périodique
  d'une nouvelle partition. </para>

<para> L'approche traditionnelle pour effectuer cela avec &slony1; est la suivante : </para>

<itemizedlist>
<listitem><para> <xref linkend="stmtddlscript"/> pour ajouter la nouvelle table de partition sur chaque noeud</para> </listitem>
<listitem><para> <xref linkend="stmtcreateset"/> pour créer un ensemble de réplication temporaire </para> </listitem>
<listitem><para> <xref linkend="stmtsetaddtable"/> pour ajouter la table dans cet ensemble </para> </listitem>
<listitem><para> <xref linkend="stmtsubscribeset"/>, une fois pour chaque noeud abonné, afin de mettre en place
    la réplication sur chaque noeud </para> </listitem>
<listitem><para> <xref linkend="stmtmergeset"/>, une fois que la réplication fonctionne, afin de supprimer 
    l'ensemble de réplication temporaire </para> </listitem>
</itemizedlist>

<para> Sachant qu'il y a de fortes chances pour que la nouvelle partition soit vide,
  il existe un mécanisme alternatif qui évite de créer un ensemble de réplication
  supplémentaire et l'utilisation de multiples requêtes <xref linkend="stmtsubscribeset"/>
  Cette alternative est la suivante : on utilise le script  <xref
linkend="stmtddlscript"/>, pour effectuer le script DDL suivant : </para>

<itemizedlist>
<listitem><para> Ajouter la nouvelle partition sur chaque noeud </para> </listitem>
<listitem><para> Exécuter les fonction stockées pour inscrire la nouvelle partition dans l'ensemble de réplication.</para> 

<para> Sur le noeud d'origine, si la table de partitionnement contient des tuples,
 le script DDL s'arrêtera car le fait que la table soit vide est une condition qui ne 
 peut pas être violée. </para> 

<para> Sur les noeuds abonnés, on peut effectuer sans danger un <command>TRUNCATE</command> sur la nouvelle table. </para>
</listitem>
</itemizedlist>

<para> Il existe plusieurs fonctions qui prennent en charge cela :
  L'utilisateur peut utiliser celle qu'il préfÚre. La <quote> fonction de 
base </quote> est <function>add_empty_table_to_replication()</function>; les 
autres disposent d'arguments supplémentaires ou différents</para>

<itemizedlist>
<listitem><para> <function> add_empty_table_to_replication (set_id, tab_id, nspname, tabname, idxname, comment);</function> </para> 

<para> Ceci est la fonction de <quote>base</quote>; vous devez spécifier
  l'identifiant de l'ensemble (set_id), l'identifiant de la table (tab_id),
  l'espace de nom (nspname), le nom de la table(tabname), le nom de l'index (idxname) 
  et un commentaire (comment) . La table sera alors ajouté dans la réplication. </para>

<para> Notez que le nom d'index est optionnel; si la valeur est NULL, alors
  la fonction utilisera la clé primaire de la table, en supposant qu'il en existe une.
  La fonction échouera s'il n'existe pas de clé primaire. </para>

</listitem>

<listitem><para> <function> replicate_partition(tab_id, nspname, tabname, idxname, comment); </function> </para> 

<para> Si l'on sait que la table qui doit être répliquée hérite d'une table mÚre 
  répliquée elle-aussi, alors cette fonction peut récupérer les informations sur 
  l'ensemble de réplication et l'origine à partir de la table mÚre.
</para>
</listitem>
</itemizedlist>


<note><para> Comme il a été remarqué précédemment, &slony1; n'est pas conscient
    que les tables sont partitionnées. Ainsi, cette approche peut être utilisée
    pour ajouter une table vide dans la réplication. </para> </note>
</sect2>

</sect1>