COMPTE-RENDU Journée du 21 avril 2015 PGDAY PARIS Oxalide 25 boulevard de Strasbourg 75010 Paris France 01 75 77 16 66
Préambule A travers ce support, nous évoquerons les différentes thématiques de cette journée en y incluant de l histoire et du contexte technique, importants prérequis pour comprendre l écosystème PostgreSQL. Puis en matière technique pure, l objectif est de confronter le contexte industriel de déploiement et développement qui était au coeur des échanges de la journée, avec des environnements de production web très haute dispo, tel que nous les connaissons chez Oxalide. Les sujets sont donc liés mais parfois traités de façon indépendante aux conférences, si vous souhaitez consulter les slides de chacune d entre elle http://www.pgday.paris Topics Pourquoi cette journée? Avec qui? Un cas d usage pour le groupe ADEO ToroDB, une approche NoSQL moderne pour pgsql Le pomm-project, une alternative aux ORMs dans le dev web. L avenir de pgsql et discussion autour du développement Remerciements ;-) Un peu plus de lecture
Pourquoi cette journée? Un peu d histoire et un état des lieux, Ingres la base de données dont la première mouture commerciale est apparue en 1980 a donné lieu plus tard à un fork par le même fondateur/créateur qu il nommera Post-GRES, puis renommera le projet PostgreSQL dans les années 1990. PostgreSQL est à ce jour, la base de données orientée SQL, la plus élaborée, entièrement opensource et maintenue par une communauté très active. En dehors des conférences plus ou moins techniques au programme de la journée, c est dans une démarche plus interactive que celles-ci se déroulaient avec l auditoire. L idée étant le partage d expériences entre les participants à l issu de chaque conférence en mode table ronde. Aucune conférence orientée produit/commerciale au programme. Avec qui? Pour que la journée existe, des sponsors tels que 2ndQuadrant, LeBoncoin, Violin memory, Dalibo, Loxodata. Tous dans l écosystème pgsql comme contributeurs, utilisateurs ou consultants en développement. Violion memory - solution de stockage flash haute densité Quelques chiffres représentatifs des participants sur une centaine de personnes : Une population de 95% de DBA et développeurs pour seulement 5% d architectes/sysops. Une large majorité de personnes issues de l industrie et grands groupes. Très peu de participants issus du milieu web.
Un cas d usage pour le groupe ADEO Plus connu sous le nom de ses grandes enseignes de bricolage, entre autre Leroy Merlin. ADEO a fait une présentation de l évolution de ses architectures de base de données dans un contexte dit industriel, même si après discussion avec eux il s avère qu ils utilisent pgsql également pour leurs sites d ecommerce. Un héritage important, historiquement ADEO utilisait entre autre Ingres, aujourd hui son infrastructure regroupant les activités magasins, catalogue, logistique... se répartit principalement sur deux produits de bases de données, à savoir Oracle et PostgreSQL. Les développements récents mis en œuvre chez ADEO se reposent sur PostgreSQL, le groupe a choisi cette direction produit, mais maintient un existant Oracle, MSSQL également, pour des applicatifs considérés comme en fin de vie ou dont le coût de portage n est pas intéressant comparé au coût de licence. Car c est le premier argument, la réduction du coût de licence, le coût d exploitation également. Une 30aine de personnes pour administrer 200 instances Oracle Moitié moins pour administrer près de 800 instances PostgreSQL. Deuxième constat intéressant fait en production sur plusieurs périodes, le nombre d incidents liés aux bases Oracle est proportionnellement nettement supérieur à celui des bases pgsql. D un point de vue plus global, pgsql a connu une large adoption dans l industrie car : Première vraie alternative avancée en moteur RDBMS opensource Respecte les préceptes d une base de données durable, transactionnelle et ACID Existait bien avant MySQL, ce dernier n avait pas la même maturité en 1995.
Au tour du milieu web de l adopter plus massivement? pgsql offre un moteur solide mais a longtemps souffert de manques de features annexes que nous allons aborder, le retard a été comblé largement depuis quelques années. MySQL a très vite évolué grâce aux besoins liés au web. Ces aspects démontrent la disparité et l usage contextuel pour chaque RDBMS. ToroDB, une approche NoSQL moderne pour pgsql Qu est-ce que ToroDB? Une première remarque sur les bases de données NoSQL telle que MongoDB, c est l argument schemaless : Il n y a pas réellement de schemaless, dans une collection mongodb si nous disposons de documents construits différemment, avec plus ou moins de champs. Pourquoi? Le schéma existe bel et bien, il est simplement attaché à chaque fois à chacun de nos documents NoSQL. Un des arguments de ToroDB vise à réduire cet overhead, en proposant un middleware qui vient se reposer sur une base pgsql pour le datastore et accepte les connexions clientes. L objectif est qu un soft utilisant un connecteur MongoDB et des queries json based va pouvoir communiquer avec ToroDB comme avec une instance MongoDB. ToroDB est full compatible avec le/les clients, connecteurs mongodb et son query langage.
Les graphes ci-dessous expriment la problématique de l overhead par document, qui n est pas forcément significative sur des datasets moins importants mais très révélateur sur des volumes supérieurs. source : 8kdata.com ToroDB optimise donc le stockage de documents JSON en se reposant sur : Des tables pgsql contenant les méta données liées aux schémas. Des tables pgsql contenant les données JSON brutes Pour n documents au schéma identique, on ne le stocke qu une seule fois. Pourquoi et à qui s adresse ToroDB? Aux utilisateurs de MongoDB qui souhaite manipuler des collections dans un dataset très large. Tout en souhaitant bénéficier d une durabilité des données garantie par PostgreSQL. Qui souhaitent interroger en mode relationnel les données JSON, pas seulement comme data field contenant le document au format blob. Bénéficier d une scalabilité horizontale en ajoutant des instances pgsql.
ToroDB répond donc aux besoins liés aux concepts NoSQL sur un socle de stockage éprouvé comme pgsql et se propose de résoudre la problématique de fiabilité du datastore. Pour aller plus loin, il faut suivre l évolution prise par chacun indépendamment dans leur développement : Quelques chiffres récents pour comparaisons dans ce benchmark : http://www.aptuz.com/blog/is-postgres-nosql-database-better-thanmongodb/ Un écart de performance qui se creuse avec l arrivée de MongoDB 3.x qui dépasse les limitations de la branche 2.6 En résumé un projet à suivre, même si un moteur comme ElasticSearch répond quasiment aux mêmes besoins fonctionnels et de scalabilité, ToroDB ne bénéficie pas de la même force de frappe avec une communauté d utilisateurs moins développé.
Le pomm-project, une alternative aux ORMs dans le dev web Grégoire HUBERT à l initiative du pomm project : - Yet another object relationnal mapping?! - NOPE Quelques arguments sur les ORMs pour mieux comprendre le leitmotiv de cette conférence : Points forts : La plupart des frameworks modernes embarquent un ORM ( ex: Symfony+Doctrine ) Supporte de multiples RDBMS ( et moteurs NoSQL! ) Les développeurs ne manipulent plus que des objets dans le code, nul besoin de connaître le langage SQL. Points faibles : De moins en moins de développeurs savent écrire des requêtes SQL. Sur des projets complexes l ORM sera moins performant et générera soit trop de requêtes et/ou pénalisera les performances en production par la complexité des requêtes générées. N utilisera pas souvent les fonctionnalités du moteur ( PL/SQL / procédures stockées, fonctions. )
Deux poids de mesure dans l usage des ORMs : Dans le cas des frameworks, sans parler des CMS dans le présent article, les modèles de données simples et légers en nombre de rows SQL moyen par table, suffisent à manipuler les données en base et à satisfaire une besoin de web perf moyennant quelques dispositions de caching applicatif (Redis, memcached) pour améliorer l expérience utilisateur. Dans le même contexte applicatif avec un volume de données élevé, sans forcément avoir un trafic utilisateur important, cela suffit à dégrader fortement les performances en impactant l instance de base de données en backend. Les dispositifs de caching cités précédemment doivent suffire à fluidifier l expérience utilisateur et à rendre le nombre de QPS (Query per second) en base de données, relativement faible. Sur un contexte temps réel comme on peut l avoir dans l industrie chez ADEO qui gèrent ses caisses avec des serveurs pgsql par magasin, ou certaines applications web du même acabit, le caching applicatif n est d aucune utilité, toutes les variables sont amenés à changer de manière aléatoire (Changement de prix, opérations spéciales, réductions immédiates en caisse, etc...) Comment répondre à une problématique de temps réel dans l industrie? (et dans le web!) Ne pas mettre l intelligence dans le code, se reposer sur les procédures PL/SQL PostgreSQL permet l écriture de code embarqué dans de multiples langages (C, Perl, Python ) Utiliser les bonnes pratiques d un RDBMS (indexes, tuning de configuration système) Dès lors que l on produit de la business intelligence, il est primordial de positionner cela en périphérie du code en priorité, JAMAIS dans le code de base, ou le moins possible. Une procédure SQL dans postgres sera TOUJOURS plus performante qu un SELECT * suivi d une concaténation d événements/opérations dans du code côté front applicatif.
On doit pouvoir également déporter certaines de ces tâches via du message queuing en mode asynchrone, lorsque le besoin de traitement temps réel n est pas primordial. Un exemple simple et parlant selon cet énoncé si on retire les leçons de la conférence, nous enregistrons l achat d un produit par un client, on doit à la fois extraire de son ticket de caisse pour consigner l événement et faire de la BI : Le calcul du panier moyen Lui ajouter les points de fidélités sur sa carte Lui envoyer des spa^hmails liés à ses achats pour du ciblage marketing Lui envoyer sa facture par mail Envoyer au final le message aux équipes logistiques pour préparer sa commande Une triggered procedure suffit à effectuer l ensemble des opérations côté RDBMS avec une seule connexion. Si on mettait l intelligence côté code, on devrait faire plusieurs appels de classes donc plusieurs connexions pour au final le même résultat avec un traitement plus long et beaucoup plus de ressources consommées côté front applicatif.
L avenir de pgsql et discussion autour du développement Le requêtage Bien des améliorations viennent se greffer à chaque release de pgsql, si on regarde la preview de la version 9.5-dev, le moteur accueille de nouvelles possibilités de requêtage (UPSERT entre autre = INSERT on conflic update) pour l instant à l état de patch et présent dans le core de la future version du RDBMS. Les outils d administration On note également l intégration d un autre outil disponible pour l instant en 3rd party tools à savoir pg_rewind, qui smplifiera grandement la resynchro de base de données sans devoir resynchroniser l ensemble du datadir par une copie brute. C est actuellement la seule façon de gérer le cas dans un cluster, qui a dû subir un failover suite à un incident ou une bascule manuelle d instance primaire. La réplication C est seulement en 2008 que les features de réplication sont intégrées dans le core de pgsql. Les développeurs n estimaient pas que cela était une priorité car il y avait encore une fois des outils développés par la communauté, ainsi le projet Slony toujours actif, permettait déjà la mise en cluster et réplication de données via du log shipping entre les instances. Retard rattrapé avec l arrivée du hotstandby et la streaming replication qui offre un moyen sûr d avoir des instances secondaires synchronisées avec le moins de latence possible.
Deux nouveaux modes de réplication arrivent en 9.5-dev : BDR et UDR, pour bidirectionnal et unidirectionnal replication Il s agit de deux technos intégrées dans le même projet mené par 2ndQuadrant Changement du mode de réplication, traditionnelement pgsql utilise du block replication niveau filesystem, le process de réplication n est pas conscient du requêtage lui même. Passage à la réplication row based qui offrent des avantages et inconvénients éventuels sur la performance du processus. Rend le multi master possible, la réplication bidirectionnelle doit pouvoir résoudre un conflit d écriture, d où la nécessité de changer le mode de fonctionnement et inspecter les requêtes. Cette feature existe t elle? Le modèle de développement de pgsql et le discours de la core team va dans le sens suivant, si vous avez besoin d une feature, concevez une extension si votre besoin est lié au moteur SQL, ou un patch si votre besoin est orienté système/clustering/administration globale. Quand un besoin est identifié par la communauté d utilisateurs, les différentes contributions de ce genre sont toujours à terme intégrées dans le core du projet. Dans les features attendues dans un avenir plus lointain, deux choses cruciales sont identifiées: Les parallels queries, concept venant du monde Oracle, permettant de distribuer via un coordinateur de requêtes la charge et le traitement sur plusieurs serveurs, il ne s agit pas d un load balancer mais d un moyen de diviser une requête en plusieurs sous requêtes executables en parallèle sur n noeuds, ce qui améliore grandement le temps de calcul. Comme nous le disions auparavant, les dba venant du monde Oracle et utilisant pgsql apprécieraient cette fonctionnalité dans une future release, le sujet est toujours considéré par la core team à échelle deux ans pour les prémisses d une telle technologie.
L auto sharding, il n existe aucun moyen à ce jour de faire du sharding automatique avec pgsql, ce qui ne rend pas le produit scalable de manière horizontal nativement. Il existe néanmoins des possibilités : Axer le développement pour le scaling horizontal en partitionnant selon le schema utilisé. Ce n est pas de l auto sharding mais c est une solution d architecture logicielle. S orienter vers un fork de pgsql proposant la dite feature, on peut citer postgrexl ou encore CitusDB qui offre le pg_shard répondant au besoin. Enfin, le meilleur moyen de suivre les fonctionnalités à venir dans le trunk pgsql reste la lecture du site https://planet.postgresql.org/ Remerciements ;-) Merci aux conférenciers et au temps qu ils ont pris en off, pour se prêter aux questions et également au maître de conférence, Dimitri FONTAINE de 2ndQuadrant. and long life to pgsql!
Un peu plus de lecture Evènements : https://www.pgcon.org/2015/ La grand-messe au Canada http://www.pgday.paris Cet événement lié au présent support de lecture Ressources techniques: http://wiki.postgresql.org La bible technique indispensable http://planet.postresql.org La source d information ultime pour suivre le développement http://bdr-project.org/docs/stable/overview.html Le BDR de 2ndQuadrant https://github.com/2ndquadrant Les divers projets à suivre dans l écosystème pgsql http://www.citusdata.com Une fork de pgsql enrichi en features avec un support commercial http://www.entreprisedb.com Idem. http://docs.oracle.com/cd/e11882_01/server.112/e25523/parallel002.htm Les parallels queries chez Oracle. Sujets conférenciers : http://www.pomm-project.org/ Le POMM project de Grégore HUBERT pour se réconcilier avec les ORMs https://wiki.postgresql.org/images/6/63/adeo_pgday.pdf Une autre conférence de ADEO cette fois sur la partie web de leur activité liée à pgsql http://www.8kdata.com/torodb/ Le projet ToroDB avec le slideshare de la conférence inclu