.: live transmission :.

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

lundi 25 février 2013

Les bases de données relationnelles avec PHP

L'AFUP organise une soirée intitulée les bases de données relationnelles avec PHP. Je viendrai présenter PostgreSQL, son développement et sa communauté, ses principales fonctionnalités et quelques retours d'expérience.

Si vous ne connaissez pas PostgreSQL, c'est le moment de venir le découvrir à cette occasion, près de la Défense, à Paris.

Pour vous inscrire, ça se passe ici :

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.

mardi 5 février 2008

PostgreSQL 8.3 est enfin là !

La version majeure 8.3 de PostgreSQL est enfin sortie ! Le développement a duré bien plus longtemps que prévu, mais ça valait la peine d'attendre !

Bien que PostgreSQL soit déjà, à mon goût, un SGBD mature, l'équipe de développement a fait un pas de géant avec cette version. J'avais surtout retenu de la version précédente, la 8.2, une simplification de la configuration, et par là, du tuning, du moteur, bien sûr ce n'était pas tout, mais c'était l'atout majeur de cette version à mes yeux.

Maintenant, de part mes nouvelles fonctions (ah oui, je n'en ai pas encore parlé), cette nouvelle version me permettra de mettre PostgreSQL en avant grâce aux fonctionnalités XML, bien que ce soit ma bête noire, et la recherche plein-texte intégrée. Les Enums me semblent être un bon apport, mais j'ai peur de voir des Enums à toutes les sauces, notamment pour représenter un état à Yes ou No, comme cela est fait abondamment sur MySQL, alors qu'un type booléen suffit (et PHP supporte traite correctement les booléens avec PG ?).

En terme d'exploitation, mon ancien métier, je salue l'activation par défaut d'autovacuum. Bien sûr, l'améliorations de performances est également à mettre en avant, mais il serait intéressant de monter un petit bench.

Pour plus d'informations, lisez l'annonce sur PostgreSQLfr.

J'aimerai également saluer Guillaume qui est pour beaucoup dans la traduction du manuel de PostgreSQL 8.3, qui est d'ailleurs déjà disponible ! Merci Guillaume !

mercredi 19 décembre 2007

Installation de pgAdmin III et de PostgreSQL 8.3beta4

C'est tout bête, j'ai simplement suivi les indications données sur le site de pgAdmin III pour installer une version à jour sur ma Gutsy, c'est à dire la version 1.8 activement supportée par Guillaume. <pub>Guillaume, grâce à qui j'ai une envie terrible de me jeter sur la Ronde de nuit de Terry Pratchett.</pub>

Ensuite, j'ai installé PostgreSQL 8.3 beta 4 en prenant soin d'activer les fonctionnalités XML :

./configure --prefix=/home/tom/pgsql/v8.3.0/ --enable-nls --enable-thread-safety --with-libxml
make -j3
make check

Pour être gratifié d'un charmant message indiquant que tout s'est bien passé :

=======================
 All 114 tests passed. 
=======================

Et finir gaiement sur un :

make install

J'installe également les contributions, car il y a quelques petites choses intéressantes que je voudrais voir... En tout cas, la compilation raaaââââââaaaaame sur mon petit P3 de rien du tout !

Petite note à l'attention des testeurs sur distribution Red Hat Enterprise Linux: la libxml2 fournie jusqu'à la RHEL 4 n'est pas suffisante pour compiler un PostgreSQL 8.3 avec les fonctionnalités XML. En revanche, ça passe sous soucis, même sur RHEL 3 sans ces dites fonctionnalités.

Et sinon, il faut que ce soit dit, ma chérie a sauvé mon apéro en ouvrant la bouteille d'Amer Bière dont le bouchon était coincé par le sucre cristallisé sur le goulot.. Et figurez-vous, chers lecteurs, qu'elle n'a pas utilisé ses petits biscottos, mais sa puissance intellectuelle pour y arriver ! Un petit chiffon imbibé d'eau chaude a remédier à ça ! Alors je dis bravo ! Aaah, les femmes...

jeudi 29 novembre 2007

PostgreSQL vs MySQL

Le site PostgreSQLfr propose un excellent article de Greg Smith intitulé Pourquoi préférer PostgreSQL à MySQL.

J'en ai appris un peu plus sur les points négatifs que je trouvais à MySQL, et surtout l'existence du mode strict. Cependant, je ne suis toujours pas convaincu par MySQL, essentiellement parce qu'une telle base est difficilement exploitable. Ah oui, par exploitable, j'entends avoir une centaine de bases de données qui se laissent oublier, et j'aurai trop peur de laisser des MySQL dans la nature sans surveillance !

En attendant, je retourne sur mes problèmes PHP/Oracle, grmbl !

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.