.: live transmission :.

Aller au contenu | Aller au menu | Aller à la recherche

jeudi 3 avril 2008

Linagora invite EnterpriseDB pour présenter Postgres Plus

Lingora, société spécialisée dans le support et la maintenance de solutions libres et la société américaine EnterpriseDB, éditrice d'une version propriétaire de PostgreSQL apportant une compatibilité avec Oracle, se sont réunies dans le cadre d'un partenariat pour proposer des licences de produits et surtout du support autour de PostgreSQL et l'offre propriétaire d'EntrepriseDB.

Après une brève introduction, Alexandre Zapolsky, PDG de Linagora, a passé la main à Andy Astor, CEO d'EnterpriseDB pour présenter la suite logicielle Postgres Plus et Postgres Plus Advanced Server.

Le SGBD PostgreSQL, ici en version 8.3, reste bien évidemment à la base de la pile Postgres Plus. Celle-ci se propose en premier lieu d'intégrer des outils et des extensions libres ou préalablement libérées par EnterpriseDB, évidemment sous la forme de paquets binaires ; ainsi, l'appropriation de PostgreSQL par un néophyte sera largement facilitée.

Parmi les fonctionnalités ou produits proposés pré-packagés, on trouvera :

  • tous les connecteurs vers PostgreSQL : JDBC, ODBC, .Net, etc.
  • l'extension de géomatique PostGIS ;
  • l'outil de réplication Slony-I ;
  • la contribution Pgcrypto se voit
  • un outil de migration de MySQL vers PostgreSQL ;
  • un gestionnaire de pool de connexion et un autre gestionnaire de cache mémoire distribué ;
  • Grid SQL, récemment acquis par EnterpriseDB, il s'agit d'un produit très adapté à la BI et au datawarehouse. Il permet de répartir les données sur les serveurs composant une grappe afin ensuite de paralléliser les requêtes sur tous les serveurs de celle-ci, augmentant ainsi très avantageusement les temps de réponse ;
  • le débugger PL/pgSQL, libéré courant 2007 par EnterpriseDB ;
  • ainsi que PgAdmin-III, Postgres Studio, la configuration automatique d'une instance, etc ;

Auparavant, la société d'Andy Astor proposait - et d'ailleurs propose toujours - EnterpriseDB Advanced Server qui était une évolution propriétaire de PostgreSQL, connue pour sa compatibilité avec Oracle, ce produit trouve sa continuation dans Postgres Plus Advanced Server. Bien évidemment, la différence ne s'arrête pas là, l'édition Advanced Server se trouve complétée par des fonctionnalités d'audit et de tuning avancées (DynaTune, Hints pour l'optimiseur), des outils de migration depuis d'autres bases de données, un outil de réplication propre à EDB. Enfin, et voilà qui devrait rassurer les décideurs, EnterpriseDB offre des garanties à l'instar de n'importe quel autre éditeur de bases de données, à condition évidemment que l'on se soit acquitté de la licence pour le produit.

Je souhaite grandement remercier Linagora pour m'avoir permis de rencontrer et de discuter longuement avec Andy et Jim ! Je remercie enfin Andy et Jim pour avoir eu la gentillesse de subir mon mauvais anglais sans broncher et pour les intéressantes discussions que nous avons eu.

dimanche 3 février 2008

Lectures

Semaine un peu chargée, du coup le schmilblick oldschool n'a pas beaucoup avancé et je préfère lever le pied ce week-end. C'est l'occasion de revenir sur quelques livres que j'ai lu récemment.

Lire la suite...

lundi 8 octobre 2007

PostgreSQL 8.3 approche à grand pas

La page de status des patchs en attente pour la 8.3 indique que l'ensemble des patchs attendus sont tous soit appliqués, soit en attente pour la 8.4, ou encore rejetés.

Au menu de cette prochaine version, quelques nouveautés intéressantes :

  • intégration de Tsearch2 au core, c'est à dire que l'extension de recherche de textes devrait être simple à mettre en oeuvre, sans patchs de partout ;
  • un gros morceau, HOT, à décortiquer ;
  • les transactions asynchrones, que l'on peut assimiler de loin aux tables en NOLOGGING sur Oracle ;
  • les curseurs que l'on peut mettre à jour ;
  • la gestion du tampon partagé améliorée, sans effet de bords suite à une lecture séquentielle importante ;
  • le support XML selon la norme SQL ;
  • évidemment, des améliorations de toute part pour aller toujours plus vite ;
  • etc.


Du boulot en perspective pour assimiler les nouveautés, d'autant plus que je suis resté sur la 7.4 pour certains aspects du moteur (merci Guillaume pour m'avoir mis à jour).

MAJ: et petite surprise que j'aime, possibilité de placer les WAL où on le souhaite, plus besoin de bidouiller avec des mv et des ln. L'option d'initdb qui va bien est -X (ou --xlogdir=), la seule contrainte étant que le répertoire accueillant les WALs soit vide.

MAJ: une variable de configuration temp_tablespaces a également fait son apparition. Les logiciels de réplication devraient également mieux s'intégrer au backend.

mercredi 5 septembre 2007

Fonction reverse en C avec PostgreSQL


Définition du besoin

Depuis la version 8i, Oracle implémente les index inversés. Voici une proposition d’implémentation équivalente pour PostgreSQL. Les index inversés permettent d’accélérer les recherches sur les motifs tels que « colonne LIKE '%chaîne' ». Dans un tel cas, PostgreSQL effectue un parcours séquentiel (ou « sequential scan ») de la table interrogée. Toutefois, il est possible d’émuler un index inverse au moyen d’une fonction de renversement de chaîne couplée à un index sur fonction.

L'article précédent proposait l'implémentation d'un prototype en langage procédural PL/pgSQL, qui fait office ici de prototype.
Cette implémentation a pour principal défaut d'être lente, pénalisant ainsi gravement les performances en écriture (INSERT et UPDATE). Ainsi, à chaque mise à jour, il est nécessaire de faire appel à la fonction reverse pour mettre à jour l'index fonctionnel ; cela s'observe notamment à la création de l'index.
En revanche, il est possible de tirer partie des capacités de traitement des caractères multi-octets, que l'on rencontre notamment dans le cas d'une base de données encodée en UTF-8.

Ainsi, l'implémentation en langage C se doit d'être à la fois plus rapide et surtout se doit de supporter les jeux de caractères multi-octets. C'est à partir de ce minuscule cahier des charges que nous allons construire notre fonction reverse.

Lire la suite...

vendredi 24 août 2007

Index inversés: aller plus vite

Hubert "depesz" Lubaczewski a réalisé une implémentation d'index inversés sans que nous nous consultions.

La solution de depesz utilise une fonction écrite en PL/Perl et offre un gain de vitesse très appréciable par rapport à la version PL/pgSQL. On apprécie le petit test de performance des deux implémentations. Se référer à l'article indexable ” field like ‘%something’” pour plus de précisions.

Depuis, la version C de la fonction reverse a bien avancé et les gains sont encore plus significatifs. Ce sera très bientôt en ligne.

lundi 20 août 2007

Fonction reverse avec PostgreSQL (PL/pgSQL)

Voici un petit article technique que j'ai écrit dans le cadre du travail et dont on m'a autorisé la diffusion. Je remercie Guillaume Lelarge pour l'avoir posté sur le site de la communauté francophone des utilisateurs de PostgreSQL : Utiliser un index pour les recherches sur des motifs tels que « colonne LIKE '%chaîne' ».

Depuis la version 8i, Oracle implémente les index inversés. Voici une proposition d’implémentation équivalente pour PostgreSQL. Les index inversés permettent d’accélérer les recherches sur les motifs tels que « colonne LIKE '%chaîne' ». Dans un tel cas, PostgreSQL effectue un parcours séquentiel (ou « sequential scan ») de la table interrogée. Toutefois, il est possible d’émuler un index inverse au moyen d’une fonction de renversement de chaîne couplée à un index sur fonction.

Tout d’abord, il est nécessaire d’activer le support du langage procédural PL/pgSQL au sein de la base de données cible à l’aide de la commande Unix « createlang plpgsql BASECIBLE ».

La fonction appelée « reverse » prendra comme seul et unique argument une chaîne de type varchar et retournera une chaîne de type varchar.

CREATE OR REPLACE FUNCTION reverse(varchar) RETURNS varchar AS $PROC$
DECLARE
  str_in ALIAS FOR $1;
  str_out varchar;
  str_temp varchar;
  position integer;
BEGIN
  -- Initialisation de str_out, sinon sa valeur reste à NULL
  str_out := '';
  -- Suppression des espaces en début et fin de chaîne
  str_temp := trim(both ' ' from str_in);
  -- position initialisée a la longueur de la chaîne
  -- la chaîne est traitée a l’envers
  position := char_length(str_temp);
  -- Boucle: Inverse l'ordre des caractères d'une chaîne de caractères
  WHILE position > 0 LOOP
  -- la chaîne donnée en argument est parcourue
  -- à l’envers,
  -- et les caractères sont extraits individuellement au
  -- moyen de la fonction interne substring
    str_out := str_out || substring(str_temp, position, 1);
    position := position - 1;
  END LOOP;
  RETURN str_out;
END;
$PROC$ LANGUAGE plpgsql
IMMUTABLE;

La fonction reverse est structurée en trois partie :

  • La déclaration elle-même via l’ordre CREATE OR REPLACE FUNCTION
  • La déclaration des variables utilisées, sous le bloc DECLARE
  • Le corps de la fonction, entre BEGIN et END;

On notera que la fonction reverse est de catégorisée « IMMUTABLE », indiquant au SGBD que celle-ci ne modifie pas les données et garantie que la fonction retournera toujours le même résultat quand elle est appelée avec les mêmes arguments, condition indispensable à la création d’un index sur fonction. Voir la documentation PostgreSQL « Catégories de volatilité des fonctions » dans la partie « Etendre le SQL ».

Un essai de la procédure permet de s’assurer de son bon fonctionnement :

DPAR=# SELECT reverse('Chaîne à renverser');
      reverse

 resrevner à enîahC
(1 ligne)

Pour optimiser les recherches par suffixes, il est nécessaire de créer un index sur fonction, sans oublier une collecte des statistiques pour l’optimiseur:

CREATE INDEX reverse_index_prenom ON personnes (REVERSE(prenom) varchar_pattern_ops);
ANALYZE TABLE personnes;

Ensuite, au lieu d’écrire un prédicat du type « WHERE prenom LIKE ’%mas’», on écrira :

SELECT * FROM personnes
  WHERE reverse(prenom) LIKE reverse(’%mas’);

PostgreSQL utilisera alors l’index créé précédemment et répondra instantanément. Sur une base de test contenant 4 millions d’enregistrement, les temps de réponse sont passés de 10s à 33ms pour la requête.

La fonction « reverse » pourrait être améliorée, mais l’implémentation décrite a l’avantage de montrer une réalisation simple et donne un exemple d’écriture de fonction pour PostgreSQL. On notera que la fonction renvoie une chaîne vide lorsque la valeur NULL est donnée en entrée. Un autre axe d’amélioration de la vitesse d’exécution serait la réécriture de cette fonction sous forme de fonction native en C couplée au choix d’un algorithme de renversement efficace.