Bases de données : et si vous essayiez l’open source ?

Développement agile

Pour le bookmaker William Hill, qui a parié sur Cassandra pour sa nouvelle couche de recommandation, l'évolutivité et le développement agile étaient des facteurs déterminants.

« Il nous fallait une technologie capable de monter en charge facilement, explique Patrick Di Loreto, responsable de l'ingénierie des plateformes. NoSQL était donc un choix évident. Cassandra figure parmi les plus matures, et sa nature « Big Table » en fait une option idéale pour l'analyse de données chronologiques. Si nous avions suivi les procédures traditionnelles en matière d'achats informatiques, nous aurions dû élaborer une analyse de rentabilité pour justifier la dépense avant de nous lancer dans le développement. Mais ce processus, long et coûteux, ne laisse la place à aucune prise de risques et à aucune expérimentation. À présent que la base de données a été mise en production, les arguments économiques ne font aucun doute. Ils permettent même de justifier un investissement supplémentaire pour la soutenir. »

D'après Matt Aslett, de 451, si vous cherchez simplement un SGBDR peu coûteux pour remplacer Oracle ou SQL Server, outre MySQL (désormais pris en charge par Oracle), PostgreSQL, dont la tradition open source est plus établie, offre une solution de remplacement fiable ».

Postgres existe depuis plus de 20 ans et a été adoptée par des entreprises et solutions de renom, comme Skype. Aucune organisation commerciale ne dirige la communauté, toutefois plusieurs entreprises proposent une assistance de haut niveau pour ce produit.

Dave Page, architecte en chef pour EnterpriseDB, l'une de ces entreprises, est également membre du comité directeur de Postgres. Il confie : « Il y a vingt ans, c'était un projet d'amateurs. Mais aujourd'hui, les personnes qui, comme moi, ont été impliquées dès le début, se retrouvent à travailler pour des sociétés et à développer les fonctions que demandent les clients. Nous plaçons la sécurité et la fiabilité en tête de toutes les autres préoccupations. Il arrive que nos concurrents lancent de nouvelles fonctions avant nous, mais notre principal objectif est d'assurer notre solidité en termes de fiabilité. Notre produit est prêt à l'emploi et offre des fonctionnalités comparables à celles des trois grands acteurs du secteur. »

80 % d'économies

Selon EnterpriseDB, même en tenant compte des coûts de migration et de support, les entreprises qui adoptent une version commercialement prise en charge de PostgreSQL enregistreraient en moyenne 80 % d'économies sur trois ans.

Cela dit, il arrive de plus en plus souvent que le relationnel ne répondent plus aux exigences d'aujourd'hui. En effet, les entreprises font face à un double enjeu : stocker et interroger des volumes sans cesse croissants de données non structurées, par exemple des documents JSON et XML, et être capables de déployer et faire évoluer de nouvelles applications en un temps record, parfois même dans plusieurs datacenters. Ces nouvelles exigences ont favorisé la croissance des bases de données NoSQL.

Celles-ci doivent leur nouvelle popularité aux géants du Web tels que Google, Amazon et Facebook, qui avaient besoin d'une solution de remplacement hautement évolutive. Ces bases de données sont généralement open source et téléchargeables gratuitement. Pour peu que votre équipe informatique ne craigne pas de tester plusieurs systèmes à la recherche de celui qui répondra le mieux à vos besoins, elles valent la peine que l'on s'y intéresse.

PCA Predict vient de développer une nouvelle application d'analyse de l'expérience client, Triggar, qui s'appuie sur de gros volumes de données pour élaborer des modèles de comportements. La société a essayé toutes sortes de bases de données, y compris MongoDB, Cassandra, Elasticsearch, MySQL et Postgres.

« Elles ont toutes leurs limites, constate-t-il. Par exemple, avec MongoDB, le stockage des données n'était pas fiable et le modèle d'appel était médiocre. Cassandra exige de concevoir les schémas avec beaucoup de soin pour que les données obtenues soient pertinentes, et les possibilités de requêtes ponctuelles sont très limitées. Elasticsearch fournit un environnement de requêtes extrêmement riche, mais lorsqu'on y entre des données, il faut attendre une ou deux secondes avant qu'elles soient de nouveau lisibles. De plus, le langage de requête par défaut est vraiment horrible ».

« Postgres fonctionnait très bien, jusqu'à ce que nous réalisions, après avoir généré des écritures particulièrement nombreuses, que le programme écrivait chaque fois une nouvelle version de l'enregistrement plutôt que de le mettre à jour. Par conséquent, si la base de données est très active, elle finit par accumuler une grande quantité de déchets. Cassandra pose le même problème. MySQL offrait un modèle d'évolutivité médiocre et sa documentation donnait l'impression que le produit avait été « calqué » sur Oracle. Nous n'arrivions pas à le prendre en main et avons donc simplement laissé tomber ».

« D'autres produits ont attiré notre attention : VoltDB, une base de données In-Memory d'une rapidité étonnante, et Aerospike. Toutes deux s'orientent vers un matériel plus moderne et exploitent des technologies telles que les disques SSD, alors que cela n'est généralement pas possible sans entrer dans la couche matérielle. »

Langage de requête

Jamie Turner a finalement opté pour Elasticsearch, mais en utilisant un langage de requête semblable à SQL plutôt que le moteur par défaut. « Nous jouissons d'une bonne évolutivité et d'une récupération efficace en cas de défaillance d'un nœud. Ce produit est en outre relativement simple à déployer et offre des possibilités de requête très riches, précise-t-il. Mais le fait de devoir attendre une seconde pour voir les données apparaître après les avoir écrites n'en demeure pas moins un réel problème. C'est pourquoi nous étudions la possibilité d'y intégrer un autre produit. »

Le fait est que tous ces systèmes font des compromis. « Au moment de choisir, il faut raisonner en qualité d'ingénieur en se demandant quel est l'objectif à atteindre, et non quel est le produit idéal. J'adorerais voyager à bord d'un avion équipé de canapés et de surfaces en marbre, mais ce dont j'ai besoin pour aller de A à B, ce n'est rien de plus qu'un vol économique », ajoute Jamie Turner.

Matt Aslett, de 451, confirme que pour vérifier si l'une des nouvelles bases de données open source - NoSQL ou NewSQL - sera bien en mesure de répondre à vos besoins et à vos workloads, il n'y a qu'une solution : mettre les mains dans le cambouis.

« Il faut toutes les essayer, dit-il. Et comme la plupart sont open source, il vous suffit de les télécharger et de jouer avec pour évaluer leurs différences. »

Matt Aslett ajoute que si le nombre d'offres peut paraître insurmontable, la liste est en réalité assez restreinte si vous vous limitez aux produits haute qualité en termes de maturité, de viabilité et de prise en charge.

« Dans la catégorie NoSQL, MongoDB sort du lot des bases de données orientées documents, mais en ce qui concerne les magasins de données clé-valeur, envisagez plutôt Cassandra avec prise en charge de Datastax, ou Couchbase, ou Riak de Basho », précise-t-il.

« Pour les bases de données orientées graphes, c'est Neo4j qui s'impose. Enfin, si vous cherchez plutôt une base de données distribuée, tournez-vous vers ce qu'on appelle les bases de données NewSQL, comme MemSQL ou NuoDB. Il y en a d'autres, mais pas en nombre suffisant pour vous empêcher de les évaluer. »