![\"twitter\"](\"https:\/\/blog.capdata.fr\/wp-content\/plugins\/social-media-feather\/synved-social\/image\/social\/regular\/48x48\/twitter.png\" "\\"Share")
<\/a><\/a>![\"linkedin\"](\"https:\/\/blog.capdata.fr\/wp-content\/plugins\/social-media-feather\/synved-social\/image\/social\/regular\/48x48\/linkedin.png\" "\\"Share")
<\/a>![\"mail\"](\"https:\/\/blog.capdata.fr\/wp-content\/plugins\/social-media-feather\/synved-social\/image\/social\/regular\/48x48\/mail.png\" "\\"Share")
<\/a>Sybase Adaptive Server Enterprise<\/strong> autorise le partitionnement s\u00e9mantique des tables depuis la v15.0.<\/p>\n Le partitionnement consiste en un d\u00e9coupage logique des tables sans aucun impact sur la syntaxe des requ\u00eates SELECT, DELETE, INSERT et UPDATE. L’op\u00e9ration est transparente pour l’\u00e9criture des requ\u00eates.<\/p>\n Chaque partition est un sous-objet de la table et contient certaines de ses lignes de donn\u00e9es.<\/p>\n Les partitions ne sont pas consultables : aucune requ\u00eate ne peut les attaquer. Bien qu’une partition contienne une partie des lignes d’une table, il n’est pas possible de savoir lesquelles.<\/p>\n Lorsqu’une table n’est pas pas partitionn\u00e9e, ASE consid\u00e8re qu’elle contient une seule partition et lui attribue un nom qui commence par le nom de la table.<\/p>\n La proc\u00e9dure stock\u00e9e qui nous informe des partitions d’une table est Il y a 4 types de partitionnement (les 3 derniers sont les partitionnements s\u00e9mantiques)<\/p>\n Le partitionnement “by-range”\u00a0se montre tr\u00e8s performant sur les tables contenant \u00e9norm\u00e9ment de lignes, surtout si certaines lignes sont rarement consult\u00e9es.<\/p>\n Au moment du partitionnement, il est judicieux de d\u00e9couper sa table en 3 ou 4 morceaux. Prenons l’exemple d’une application sp\u00e9cialis\u00e9e dans la m\u00e9t\u00e9orologie : elle stocke toutes les donn\u00e9es m\u00e9t\u00e9o quotidiennes de toutes les villes du monde. La table en question va progressivement contenir beaucoup de lignes. Or, la plupart des requ\u00eates de lecture qui vont l’atteindre se cantonneront aux dates les plus r\u00e9centes : m\u00e9t\u00e9o d’aujourd’hui, d’hier, d’avant-hier. La table est donc encombr\u00e9e par son historique.<\/p>\n Parmi toutes les donn\u00e9es contenues sur la table, pour favoriser la lecture des dates r\u00e9centes, il est possible d’associer le partitionnement “by-range” et la segmentation.<\/p>\n En effet, il peut \u00eatre judicieux de\u00a0cr\u00e9er 3 segments dans la base : chacun reli\u00e9 \u00e0 un device diff\u00e9rent. Les devices peuvent \u00eatre eux-m\u00eame allou\u00e9s sur des supports physiques de performance et co\u00fbt diff\u00e9rents :<\/p>\n D\u00e8s lors, avec un d\u00e9coupage par date, les donn\u00e9es de plus d’un mois se retrouveront sur le premier device, les donn\u00e9es de moins d’un mois mais plus d’une semaine se retrouveront sur le deuxi\u00e8me disque et enfin, les donn\u00e9es de moins d’une semaine seront accessibles \u00e0 une rapidit\u00e9 in\u00e9gal\u00e9e gr\u00e2ce au SSD du 3\u00e8me device. Gr\u00e2ce au “partition pruning” (terme d’horticulture qui signifie la “taille”), lors de son tablescan, l’optimiseur va ignorer certaines partitions s’il est s\u00fbr \u00e0 100% que la donn\u00e9e qu’il cherche ne s’y trouve pas. ROOT:EMIT Operator<\/p>\n |SCAN Operator Durant les p\u00e9riodes creuses, par exemple, la nuit ou les week-end, il faudra syst\u00e9matiquement reconstruire la table afin de\u00a0rafra\u00eechir\u00a0ce partitionnement. Les partitions qui n’auront pas chang\u00e9 (typiquement, celle qui contient les donn\u00e9es les plus anciennes) ne seront pas reconstruites.<\/p>\n La limite de ce syst\u00e8me c’est la fa\u00e7on dont on recherche les donn\u00e9es ensuite : seules les recherches bas\u00e9es sur la date au sens chronologique b\u00e9n\u00e9ficieront de cette mise en place. Pour toute recherche du genre “m\u00e9t\u00e9o de tous les 1er Janvier de 1970 \u00e0 nos jours” ou encore “toutes les donn\u00e9es m\u00e9t\u00e9o de la ville de New York de 1970 \u00e0 nos jours”, le partitionnement sera sans effet et sera peut-\u00eatre m\u00eame pire qu’avant car les 3 disques seront sollicit\u00e9s y compris le plus lent. Pour surmonter ces cas-l\u00e0, on pourra faire intervenir la “d\u00e9normalisation”.<\/p>\n L’avantage du syst\u00e8me c’est sa compl\u00e8te transparence pour l’applicatif : rien n’est \u00e0 re-d\u00e9velopper c\u00f4t\u00e9 applicatif.<\/p>\n Passons \u00e0 la pratique. Il faut commencer par autoriser le partitionnement s\u00e9mantique (by-hash, by-list ou by-range) en passant la commande\u00a0 Ensuite il faut cr\u00e9er les n<\/em> devices correspondant aux n<\/em> supports de stockage. Ensuite, il faut attacher la base de donn\u00e9es aux n<\/em> devices : On peut aussi trouver ce genre de montage avec le partitionnement par liste (by-list) pour d’autres applications. Par exemple, on peut imaginer une table qui contient des donn\u00e9es consultables et des donn\u00e9es “supprim\u00e9es” au sens applicatif. En quelques sortes, des donn\u00e9es visibles et des donn\u00e9es cach\u00e9es mais qui restent dans la table pour des raisons de conservation historique.<\/p>\n Comme pr\u00e9c\u00e9demment, on va partitionner pour conserver les donn\u00e9es cach\u00e9es sur un disque physique peu co\u00fbteux et donc peu performant et les donn\u00e9es visibles sur un disque performant.<\/p>\n Mais il y a un gros inconv\u00e9nient chez le partitionnement par liste : lorsque la colonne responsable du partitionnement contient une valeur non pr\u00e9vue, l’INSERT tombe en erreur. L’application est donc tenue de g\u00e9rer correctement le contenu de la colonne d\u00e9cisive.<\/p>\n Exemple de mise en pratique : Sybase Adaptive Server Enterprise autorise le partitionnement s\u00e9mantique des tables depuis la v15.0. Le partitionnement consiste en un d\u00e9coupage logique des tables sans aucun impact sur la syntaxe des requ\u00eates SELECT, DELETE, INSERT et UPDATE. L’op\u00e9ration est transparente pour l’\u00e9criture… Continuer la lecture sp_helpartition<\/code> suivi ou non du nom d’une table.<\/p>\n\n
\n
A noter qu’il n’est pas obligatoire de disposer de disques de performances in\u00e9gales. On peut tr\u00e8s bien avoir 3 disques tout aussi rapides. C’est juste plus on\u00e9reux financi\u00e8rement mais ce n’est pas une limite technique.<\/div>\n
\n
\nThe type of query is SELECT.<\/code><\/p>\n
\n| FROM TABLE
\n| temperatures
\n| [ Eliminated Partitions : 1 2 ]<\/strong>
\n| Table Scan.
\n| Forward Scan.
\n| Positioning at start of table.
\n| Using I\/O Size 2 Kbytes for data pages.
\n| With LRU Buffer Replacement Strategy for data pages.<\/code><\/p>\nsp_configure 'enable semantic partitioning', 1<\/code>.<\/p>\n
\n
\ndisk init name='device_lent', physname='D:\/sybase\/meteo_data', size='1000M'
\ndisk init name='device_medium', physname='E:\/sybase\/meteo_data', size='100M'
\ndisk init name='device_rapide', physname='F:\/sybase\/meteo_data', size='50M'
\n<\/code><\/p>\n
\n
\ncreate database meteo on
\ndevice_lent=1000,
\ndevice_medium=100,
\ndevice_rapide=50
\n<\/code>
\nPuis il faut cr\u00e9er les n<\/em> segments correspondants :
\n
\nsp_addsegment segment_lent, meteo, device_lent
\nsp_addsegment segment_medium, meteo, device_medium
\nsp_addsegment segment_rapide, meteo, device_rapide
\n<\/code>
\nEnfin, vient le moment o\u00f9 on d\u00e9coupe la table en la r\u00e9partissant sur les n<\/em> segments :
\n
\nalter table temperatures partition by range (date)
\n(
\npartition_ancienne\u00a0values <= ('2013-01-01') on segment_lent,
\npartition_recente\u00a0values <= ('2013-02-15') on segment_medium,
\npartition_actuelle\u00a0values <= (MAX) on segment_rapide
\n)<\/code><\/p>\n
\n
\nalter table contrats partition by list (visibilite)
\n(
\npartition_cachee values (0) on segment_cachee,
\npartition_visible values (1) on segment_visible
\n)<\/code><\/p>\n<\/a><\/a><\/a>","protected":false},"excerpt":{"rendered":"