La bêta de PostgreSQL 9.4 arrive avec le "JSON binaire" JSONB. Ce nouveau format de stockage pour les données de type document est extrêmement performant et embarque l'indexation ainsi que les fonctions et opérateurs pour manipuler les données JSON.
Le type JSONB est la rencontre des deux projets HStore et JSON. JSONB contient tout ce que JSON a, mais est plus efficace en stockage grâce à sa représentation binaire et plus rapide grâce à l'indexation. À la longue, tous les utilisateurs actuels de HStore et JSON devraient migrer vers JSONB.
Pourquoi les fonctionnalités NoSQL sont importantes pour PostgreSQL alors que ses utilisateurs traditionnels sont des développeurs en besoin de solides capacités relationnelles ou venant de bases de données propriétaires telles que Oracle ? Josh Berkus, un des membres de l'équipe principale nous partage quelques reflexions :
Le marché d'Oracle, bien qu’important actuellement, n'est absolument pas en expansion. La population actuelle d'utilisateurs Oracle pouvant migrer vers PostgreSQL est encore plus faible. Peu importe le nombre de fonctionnalités que l'on peut ajouter, nous ne pourrons jamais être meilleurs qu'Oracle à être Oracle.
Les technologies innovantes réussissent parce qu'ils atteignent de nouveaux utilisateurs et font croître le marché.
D'autres commentaires sur le même fil de discussion indiquent aussi clairement qu'un nombre important de start-ups utilisant PostgreSQL avec des technologies telles que Node, Python, Go ou Ruby sont impatientes d'avoir accès à un support rapide du JSON.
Compte tenu de ces points, il est évident qu'un support de qualité et performant de JSON sans compromis sur ses atouts tels que la fiabilité peut aider PostgreSQL à gagner de nouveaux cas d'utilisation.
Il y a toujours des zones dans lesquelles les autres bases de données NoSQL peuvent être meilleures, par exemple, Bruce Momijan, Architecte base de données senior à EnterpriseDB, suggère :
Même si PistgreSQL gagne en fonctionnalité et capacité, il y a toujours quelques cas d'utilisation où une solution NoSQL peut être un meilleur choix. Cassandra, étant une base colonne, est pertinente pour des données non structurées avec beaucoup de duplications, comme les fichiers de log, et est forte à l'ajout de noeuds. Par contre, Postgres va rester un choix principal pour les applications qui peuvent bénéficier des fonctionnalités NoSQL tout en ayant des contraintes ACID.
Robert Hass, un contributeur et Architecte vase de données à EnterpriseDB ajoute :
Un exemple est si vous utilisez MapReduce pour exécuter des requêtes parallèles. Dans ce cas, vous allez certainement préférer quelque chose comme Hadoop. Un autre exemple est si vos données nécessitent un nombre important de petits changements sur des objets JSON importants. Certaines solutions NoSQL peuvent être capables de gérer ces cas plus efficacement.
À part certains cas d'utilisation spécifiques, pour les développeurs ayant besoin de flexibilité et d'un schéma relationnel pour différents types de données dans une même application ainsi que les garanties ACID, Postgres est en train de devenir une solution possible.
JSONB n'est pas l'unique fonctionnalité introduite dans la version 9.4 :
- Data Change Streaming API permet de décoder et de transformer les flux de réplications. Cela sera la base pour de nouveaux outils de réplication.
- Vues matérialisées avec "refresh concurrently".
- ALTER SYSTEM SET, permet de modifier prostgresql.conf via des requêtes SQL.
Et quelques autres fonctionnalités mineures :
- Tâches de fonds dynamiques
- Réplication
- Améliorations des écritures
- Améliorations de performances
- Nouvelles fonctions de manipulation des tableaux et des tables
- Standby temporisé
- Réduction du niveau des lock pour certaines commandes ALTER TABLE
- WITHIN GROUP
Vous pouvez consulter la liste complète des changements sur le site de PostgreSQL.