Les retours d’Infotel sur le Couchbase Live France 2015

Infotel continue d’approfondir son expertise Big Data en permettant à des collaborateurs de participer à des TechDays comme le Couchbase Live France 2015.


Couchbase Live France 2015


Quelques retours enrichissants …



Couchbase 4, les nouveautés


Lors du Couchbase Live France 2015, a été présentée la nouvelle version Couchbase server 4.0. Voici ses principales nouveautés :


N1ql
Couchbase frappe fort en créant une variante du SQL. Couchbase met en avant les forces qui ont fait le langage SQL, à savoir un langage qui permet de « décrire les données » que l’on veut sans avoir à définir le « comment récupérer ses données ». Dans la même optique, Cassandra a déjà sorti sa version de SQL, le CQL. Couchbase va plus loin, n1ql pour Non-first Normal Form Query Language (prononcé « nickel ») permet de « faire du SQL sur du JSON ». C’est à dire, faire du SQL sur des données dont le format n’a pas été prédéfini. Le N1ql permet de faire des projections (récupérer une partie du document) ainsi que des jointures (lier les documents). Couchbase a ainsi profité de ce nouveau langage pour sortir des drivers JDBC et ODBC. On peut ainsi brancher les outils de BI classiques comme Tableau directement sur Couchbase. A noter qu’il est possible de mettre à plat le JSON (UNNEST) de façon similaire à l’UNWIND de MongoDB. Il est ainsi possible de générer un result-set flatté.

Pour en savoir plus :

Global Secondary Indexing(GSI)
Couchbase inclut un nouveau service d’indexation permettant des recherches efficaces sur les champs secondaires (autre que la key). Ce service est délocalisé des données de façon à éviter les scatter/gather des views. Il ne remplace pas les views qui sont toujours présentes. A noter que les indexes GSI sont mis à jour en asynchrone pour ne pas perturber la stabilité des performances du service key/value. On note ici que Couchbase ajoute des fonctionnalités en veillant bien à ne pas perdre en performance.


ForestDB
Le WiredTiger de Couchbase ? Ce nouveau moteur a été implémenté par Couchbase et a été intégré dans le GSI. Il ne remplace pas le moteur de stockage principale key/value de Couchbase. On peut espérer de bonne performance pour ce moteur pour l’instant dédié aux index.


Multi dimension scaling
Derrière cette expression, Couchbase veut montrer que sa base est un modèle en termes de scalabilité. Avoir une scalabilité horizontale pour le moteur key/value est incontestée, cependant elle l’est moins concernant la recherche sur index. Couchbase reconnaît la faiblesse des views : il faut à chaque fois faire un scatter/gather qui implique tous les nœuds du cluster. Couchbase 4.0 permet d’activer un ou plusieurs des services data/index/query sur chacun des nœuds. On peut donc désormais s’offrir un énorme serveur pour l’indexation afin d’accélérer grandement les requêtes sans faire de compromis sur le service key/value.


Couchbase 4 VS MongoDB : Faut-il choisir entre les performances et les fonctionnalités ?


Les nouveautés proposées dans Couchbase Server 4.0 nous ont fortement incités à faire la comparaison avec MongoDB.
MongoDB a connu un franc succès grâce à sa facilité d’utilisation et sa richesse de fonctionnalités au sein de l’univers NoSQL. De son coté, en plus des performances et de la facilité d’administration, Couchbase peut désormais afficher des fonctionnalités plus étendues.


Performance : MongoDB a misé sur WiredTiger
MongoDB , en intégrant le moteur WiredTiger, essai de faire oublier les critiques de son moteur MMAP v1.
MongoDB 3.2 établi WiredTiger comme stockage par défaut, soit seulement 1 version après son intégration.

Couchbase, de son côté, a mis un point d’honneur à ne pas proposer une fonction recherche qui aurait pu mettre en péril les performances du moteur key/value. Couchbase livre donc le N1ql avec le multi dimension scaling.


Fonctionnalités : Couchbase Server 4.0 est une petite révolution
Force est de reconnaitre que MongoDB avait jusqu’alors une certaine avance en terme de fonctionnalités/agilité.
Avoir le maximum d’agilité sur une base NoSQL a depuis longtemps été la force de MongoDB :
Ce schéma qui met en évidence le rapport performance/Fonctionnalités nous a grandement rappelé celui présenté par MongoDB depuis plusieurs années:

A travers ce schéma, il faut comprendre que MongoDB souhaite avoir le maximum de fonctionnalités sans sacrifier la scalabilité.

Ravi Mayuram(SVP Products & Engineering) lors du Couchbase Live France 2015 dit :
« Couchbase 3 avait la scalability, couchbase 4 ajoute la flexibilité »


MongoDB ne semble pas souhaiter se faire dépasser sur ce terrain et dans la version 3.2, il ajoute la possibilité de faire des left outer join via le Framework d’agrégation.

Avec cette avancée significative, Couchbase a proposé le 18 novembre un Webinar sur la migration MongoDB vers Couchbase.http://www.couchbase.com/nosql-resources/webinar


De plus, Couchbase propose désormais des formations en ligne (dont certaines gratuites) afin de rendre sa base encore plus accessible à tous. http://training.couchbase.com/online


Faire un choix aujourd’hui
La concurrence est désormais clairement établie et nous autres utilisateurs ne pouvons que nous en réjouir.
Chacune de ses bases de données fait des efforts considérables pour combler ses faiblesses, mais nous conseillons encore de choisir :

  1. MongoDB lorsque l’agilité est un critère déterminant,
  2. Couchbase lorsque les performances key/value sont déterminantes.


Caching use cases


Au fil des présentations de la journée, l’un des points qui ressort est l’intérêt du « Managed cache » intégré à Couchbase Server. La présence d’un cache entre la couche applicative et la base de données permet de meilleures performances car la donnée est disponible en RAM et n’a pas besoin d’être lue depuis le disque. Il en va de même en écriture, la mise à jour dans la base pouvant se faire de manière asynchrone à partir du cache.

Une solution pour cela, notamment avec des bases de données SQL, est d’utiliser un cache distribué indépendant de la base, comme Memcached. Cette solution présente cependant plusieurs inconvénients :

  1. L’infrastructure est plus complexe,
  2. La gestion du cache et des transferts de données entre la base et le cache nécessite un effort supplémentaire,
  3. L’extension des capacités est plus délicate.


Le cache intégré à Couchbase Server est au cœur du système de gestion de base de données depuis sa création. Il permet de ne pas avoir de composant supplémentaire dans l’architecture de l’accès aux données. Il est géré en monitorant la lecture et l’écriture des documents par les clients. Les données les plus utilisés sont conservés en mémoire, les moins utilisés en sont éjectés pour laisser la place à d’autres. La persistance sur disque et la réplication sont effectuées de manière asynchrone, via des queues.

Couchbase nous a présenté au cours de cette journée plusieurs cas de migration d’une telle architecture vers un cluster Couchbase. Ont notamment été cités : PayPal, Tesco, Walmart, Experian et Sky. Le cas d’Amadeus, présenté comme le plus gros remplacement de Memcached à l’échelle mondiale, a été plus détaillé lors d’une présentation par Ludovic DUFRENOY, Software Development Manager. Amadeus est passé de 27 nœuds MySQL et 24 nœuds Memcached à une trentaine de nœuds Couchbase, et ils sont visiblement très satisfaits des performances de leur nouvelle infrastructure, avec un temps de réponse du cache inférieur à 0.5ms.

On retiendra donc que les retours clients mettent l’accent d’une part sur les performances, conservées malgré l’ajout de fonctionnalités, et d’autre part sur la simplification de l’infrastructure, avec la simplification d’augmentation des capacités et la réduction des coûts qui en découlent.

Communiqué de presse d’Amadeus en Français (14/11/2013)
http://www.amadeus.com/web/amadeus/fr_FR-FR/Page-daccueil-Amadeus-Home/Actualit%C3%A9s-et-%C3%A9v%C3%A9nements/Communiqu%C3%A9s-de-presse/2013-11-14-Amadeus-et-couchbase/1259071475442-Page-AMAD_DetailPpal?assetid=1319575273950&assettype=PressRelease_C


Couchbase mobile use cases


Couchbase Mobile se compose de trois éléments :

  1. Sync Gateway
  2. Couchbase Lite
  3. Couchbase Server

« Sync Gateway » est un serveur de synchronisation qui permet d’activer Couchbase Server et de gérer en temps réel les flux de collaboration sur tous types de supports, via la messagerie instantanée, le cloud ou encore les réseaux sociaux. Il a pour but de copier les données internes au système entre les serveurs Couchbase et Couchbase Lite. Il gère aussi :

  1. l’authentification
  2. le contrôle des données
  3. la validation des mises à jour
  4. la duplication des données avec Couchbase Server

« Couchbase lite » est une base de donnée NOSQL très légère, intégrée directement dans le périphérique. Les informations sont directement écrites en local, ce qui permet d’avoir une latence très faible lors des écritures et lectures en base. Couchbase Lite représente les données dans le format JSON, ce qui permet une grande souplesse et ne nécessite plus de définir une structure de donnée précise. Couchbase Lite se synchronise avec Couchbase Server dès que c’est possible et s’occupe de la résolution des conflits potentiels.

Ryanair, qui a présenté ce use case, faisait face à plusieurs problèmes avec son application mobile de réservation de vol. Les plus importants étaient la lenteur de l’application et la nécessité d’avoir une bonne connexion internet pour pouvoir réserver un vol en un temps acceptable et de n’ importe où (aéroport, en vol, pays étranger).

Couchbase Mobile permet donc à Ryanair d’améliorer grandement la latence, pour réserver un vol il ne faut que 2 minutes contre 5 minutes auparavant et un accès hors-ligne aux données sur les vols. Les clients peuvent donc réserver un vol même sans avoir une connexion internet. Cela est très important pour eux car leurs voyageurs n’ont pas accès aux données mobiles en dehors de leur pays ou dans l’avion et la plus part du temps les connexions wifi gratuites sont très lentes.

La mise en place de Couchbase Lite et de Sync Gateway étant simple, ils ont pu mettre en place la nouvelle application en une semaine avec l’aide des techniciens de Couchbase et grâce à la communauté de développeurs très active.

Voir la présentation complète Ryanair Couchbase Live : http://docslide.us/travel/how-ryanair-reduced-booking-time-from-5-to-less-than-2-minutes-couchbase-connect-2015.html



Infotel, fier d’être partenaire technologique de Datastax

Pourquoi ce partenariat ?

1. Infotel a récemment lancé son plan stratégique appelé « Plan Performance 2016 » dans lequel le Groupe a pour objectif d’accompagner ses clients dans leur stratégie Big Data. Ce partenariat permet à Infotel de compléter son expertise dans la gestion des grandes bases de données et élargir sa maîtrise de l’écosystème Big Data dans lequel Datastax joue un rôle majeur.


2. Pour Datastax, ce partenariat met à disposition de ses clients l’expérience d’intégrateur d’Infotel déjà impliqué dans de nombreux développements autour des systèmes distribués et des grandes bases de données. Infotel participe à la migration des grands comptes vers le NoSQL, en France comme à l’international.


Quelle est la valeur ajoutée pour les clients d’Infotel ?

Infotel fournit à ses clients un support adapté à leurs besoins pour intégrer les nouveaux outils du NoSQL, comme Cassandra, dans leur SI. Les capacités de Cassandra pour l’écriture rapide de quantités massives d’informations en font en effet une des bases de données majeures de la tendance NoSQL. Distribuée par Datastax, elle représente un outil de choix lorsque l’on cherche une base de données scalable sans single point of failure. Appartenant à la famille des bases de données colonnes, elle constitue une véritable alternative face à d’autres systèmes de stockage structurés.

Interface OpsCenter permettant la supervision de clusters Cassandra


Infotel complète son panel de technologies mises en œuvre sur ses plateaux et vous accompagne grâce à ce partenariat. Avec Infotel, vous pouvez fournir à vos équipes projet le support Datastax dont elles ont besoin pendant les cycles de développement et jusqu’à la mise en production de vos applications.


Vous souhaitez en savoir plus ?

N’hésitez pas à nous contacter : ingenierie.technique@infotel.com



SAP HANA (sur Amazon Web Services), l’in-memory pour booster l’analytique.

Nous vous proposons de parcourir les caractéristiques de HANA la base in-memory colonne développée par SAP, et vous inviter à connaître la solution au travers de l’offre de Amazon Web Services qui offre un terrain de jeu parfait pour un POC.

HANA : Une base colonne en mémoire

Avec l’avènement des nouvelles architectures matérielles vers 2005 ( CPU plus nombreux et plus rapides, RAM dépassant le TB ), les bases colonnes ont trouvé un support leur permettant de se développer industriellement. A ce jour, outre HANA, on peut citer Vertica ( HP ) ou Oracle ( option in-memory ) comme alternatives sur une machine Unix/Linux. Mais plus généralement, tous les grands éditeurs possèdent une option colonne dans leur catalogue et il est frappant d’observer qu’il n’existe pas (encore ?) de bases colonnes open source disponibles du type Cassandra ou Couchbase !

Les bases in-memory colonnes ont pour but d’optimiser l’OLAP, c’est-à-dire l’analytique en direct. Pour ce faire, elles se reposent sur les principales caractéristiques suivantes :

  • Un taux de compression de 10 ou plus sur les colonnes :

    En effet, l’entropie est beaucoup plus faible sur une colonne que sur une ligne, les données se « ressemblant » plus. Ainsi, des algorithmes de compression moins consommateurs en CPU ( RLE, bit-vector, dictionnary, … ) ont pu être mis en oeuvre pour profiter de cette faible entropie.
  • Une nouvelle localisation des données :

    Au démarrage de l’instance, les données sont chargées en RAM. Puis, la vectorisation des colonnes permet à ces dernières de résider dans les caches du processeur, d’où une accélération supplémentaire en terme d’accès à la donnée.
  • Une parallélisation accrue :

    Au niveau des processeurs, la technologie SIMD ( SingleInstructionMultipleData ) permet d’effectuer des opérations binaires entre les vecteurs.

HANA propose d’aller plus loin en se positionnant comme une base pouvant également gérer l’OLTP, un choix différent d’Oracle qui propose le mode colonne en complément du mode ligne.

Pour ce faire, SAP a introduit un concept de merge delta permettant de gérer les mises à jour unitaires et en masse. Pour les mises à jour unitaires, la zone delta est en mode ligne. Les données sont ensuite déversées dans la zone réservée aux mises à jour de masse, zone en mode colonne non optimisée. Enfin, les données rejoignent la zone principale de manière asynchrone. Sur ce point, l’éditeur doit encore faire ses preuves, la plupart des cas d’utilisation publiés étant relatifs à la BI.

Quel impact sur le développement ?

Le développement des requêtes se fait en SQL et les procédures stockées sont écrites en SQL Script. La grammaire SQL est déjà bien étoffée ( lien : http://help.sap.com/hana_appliance => SAP HANA SQL and System Views Reference). En revanche, le langa
ge SQL Script (SAP HANA SQLScript Reference ) est principalement dédié au traitement OLAP, en particulier les fonctions qui ne sont utilisables que pour les lectures afin de les paralléliser au mieux. Les procédures, quant à elles, permettent d’encapsuler les requêtes SQL de toute nature, mais il est encore pénalisant de gérer les transactions ( commit & rollback non autorisés ) au sein d’elles.


De plus, SAP met en avant un modèle analytique basé sur des attribute view ( dimensions ), des analytical view ( tables de fait ) et des calculation views ( calculs sur les tables de fait ) permettant de concevoir un modèle en étoile dans un contexte colonne. Les calculation views se basent sur des CE-Build In fonctions ou des requêtes SQL de lecture. Il existe aussi un outil de conception entièrement graphique qui permet de mettre en oeuvre ce modèle analytique.


Lancer son instance HANA dans AWS


Afin de promouvoir HANA, SAP propose de s’initier à ce produit via Amazon Web Services (AWS). L’instance HANA peut être déployée à Francfort ou en Virginie du Nord. Petite limite observée à ce jour, Il est préférable de déployer sur l’instance des Etats-Unis, pour surmonter des problèmes de disponibilité (machine non réservée perte de contexte à chaque arrêt / démarrage ). Elle repose sur une machine Linux Suse de type m2.4xlarge ( 8 vcpu, > 60 GB RAM ).


En termes de coût, l’instance HANA est gratuite et l’infrastructure mise à disposition par AWS payante (Remarque : le coût de possession sur ses propres infrastructures n’est pas sur ce modèle). A titre d’exemple, le coût peut être déchiffré de la manière suivante :

$1.080 par heure d’exécution ;
$0.05 par GB au-delà de 30 GB par mois ;
$0.05 pour un million d’IO au-delà de 2 millions d’IO par mois ;
$0.095 par GB ( snapshot ) au-delà de 1 GB par mois ;
Taxes (20 %).


opérationnel en 2 heures

En termes technique, la procédure est décrite à cette adresse : http://scn.sap.com/docs/DOC-28294 et permet d’être opérationnel en 2-3 jours, le temps d’initialiser le compte AWS. Si ce dernier existe déjà, l’installation est faite en quelques heures, le temps de se familiariser avec la version cloud d’HANA.
Bien que relativement simple d’appréhension, la création de l’instance HANA peut vous conduire à recevoir des erreurs délivrées par les web services d’AWS.

Exemple : lors de la configuration du compte AWS, vous pouvez tomber sur cette page:

Dans ce cas, contacter le support disponible sous AWS ; il est très réactif.
Une fois l’installation effectuée, l’instance se pilote via le site HANA Enterprise Cloud/Cloud Appliance Library :
HANA Enterprise Cloud

HANA STUDIO, client basé sur Eclipse, permet de développer, d’administrer et de monitorer l’instance HANA.
HANA Studio

Pour étudier cette solution, j’ai créé quelques tables en mode colonne ( nombre de colonnes variant entre 10 et 50, nombre de lignes variant entre quelques dizaines de milliers et 1 million ). Mon objectif n’était pas de tester des grandes tables ( plus de 1 GB en mode compressé ), mais de vérifier l’efficacité de la compression en mode colonne. Sur ce point, j’ai bien retrouvé des facteurs de 10 ou plus sur les colonnes non uniques.


D’autre part, je souhaitais étudier le SQL Script et ses limites pour la mise à jour. Je vous ai déjà parlé de la non gestion des transactions, mais il faut aussi savoir qu’il ne dispose pas de bulk collect. Si vous souhaitez l’équivalent, il vous faudra par exemple utiliser le mode batch de la couche JDBC. Comme alternative payante, vous pouvez utiliser SLT, un outil de réplication ou Data Services, un outil de chargement des données. Pour le chargement des fichiers, vous disposez aussi d’une commande import gratuite et optimisée ( thread, batch size ).


Enfin, je me suis intéressé à l’optimiseur colonne de HANA afin de mieux comprendre comment il fonctionne en terme de gestion des jointures ( jointure à 1 ou n colonnes ), d’utilisation des colonnes, de calculs d’agrégat. Pour ce faire, un outil indispensable : SAP HANA Plan Viz. Pour information, Hana dispose aussi d’un optimiseur ligne pour les tables en mode ligne et d’un optimiseur en mode OLAP pour le modèle analytique.

Changer de technologie c’est changer de paradigme

Avant de se lancer dans le grand bain, il faut appréhender ce nouveau type de solution en changeant de paradigme : le mode ligne n’est plus applicable ; il faut comprendre comment les opérations de lecture et d’écriture sont repensées et construire son modèle de données selon ces particularités. Un simple exemple très explicite: les index sont la plupart du temps inutiles en mode colonne.
Enfin, je vous conseille de lire ce post : http://scn.sap.com/community/hana-in-memory/blog/2013/12/29/6-golden-rules-for-new-sap-hana-developers.

Pour en savoir plus sur les bases colonnes et HANA :

  • Column-Oriented Database Systems : S.Harizopoulos, D.Abadi, P.Boncz [ VLDB 2009 Tutorial ];
  • The Design and Implementation of Modern Column-Oriented Database Systems: D.Abadi, P.Boncz, S.Harizopoulos, S.Idreos [ Foundations and Trends in Databases, 2012 ];
  • Building Advanced Data Model with SAP HANA: W.Steyn [ 2011 ];
  • Best-practices-for-sap hana data load: http://scn.sap.com/community/hana-in-memory/blog/2013/04/08/best-practices-for-sap-hana-data-load.

    • Stéphane NOTTER, Expert Architecture des données.



Relationnel vs NoSQL : l’écosystème de la base de données à l’heure du « BigData » (2/2)

A la recherche de la performance

Si les systèmes critiques ont longtemps été concentrés dans mes infrastructures informatiques des grands groupes (Industriels, Bancaires, ….), les ordres de grandeurs portés par internet ont bousculé les pratiques de gestion de la performance.

Dans le cas de systèmes fermés (clients et serveurs en interne) la performance est majoritairement prise en compte a posteriori : validation par des tests de charge, optimisations des structures, dénormalisation éventuelle, utilisation de mécanismes spécifiques (index bitmap…). L’intervention ponctuelle d’un expert est requise pour tenter de comprendre un problème de performance lors d’un pic inexpliqué ou lors d’un changement brusque et imprévu de la nature des données (calcul des statistiques obsolète) ou encore lors d’une augmentation de la volumétrie suite à des nouvelles fonctionnalités.
Pour les acteurs du Web ouverts à la diversité et aux volumes astronomiques de données, la performance et la continuité de service font partie des enjeux vitaux de l’entreprise.
Elles doivent faire face à une augmentation exponentielle des accès concurrents en base couplée à une explosion de la volumétrie. De plus, cette volumétrie regroupe désormais tous types de données (texte, image, vidéo, … ) et ce phénomène n’est pas prêt de s’essouffler avec le mobile …
Pour faire face à ces nouveaux défis, les architectures ont du devenir ‘hyper-scalables’, avec des impacts sur chaque élément du système d’information qui doit être aligné sur cet enjeu. Il s’agit de créer une ‘composition’ technique intégrant les critères suivants :

  • La capacité du système à monter en charge pour pouvoir gérer toutes les demandes client lors des pics d’activité ;
  • La capacité d’un nœud à pouvoir paralléliser les traitements ;
  • La capacité à « pousser » les IO au plus près de la CPU ;
  • La capacité du système à dépasser les limites d’un réseau classique (TCP/IP) ;
  • La capacité du système à masquer les limites des disques classiques (disques magnétiques).

Une architecture « scalable » repose sur un ensemble de nœuds, le nombre de nœuds pouvant être augmenté au fil du temps. De plus, la clusterisation d’un système permet de supporter un grand nombre d’accès concurrent de manière continue. Cette haute disponibilité permet de faire face à la défaillance d’un nœud via du failover. Ce type d’architecture peut être « shared nothing » (partitionnement des données sur plusieurs disques, chaque nœud ayant accès à un seul disque ) ou « shared everything » (données stockées sur un système de stockage commun à chaque nœud ).

Une architecture de type «shared nothing» est par exemple implémentée par Teradata. Elle s’adapte bien pour des applications de type datawarehouse car la « scalabilité » est linéaire. En revanche, la gestion d’un nœud défaillant est moins transparente (les données non partagées doivent être réappropriées par les autres noeuds) et le load-balancing est impossible. Enfin, l’ajout d’un nouveau nœud nécessite de redéfinir l’architecture en particulier au niveau de la distribution des données.
Une architecture de type « shared everything » est par exemple mise en œuvre par Oracle (option RAC). Elle est intéressante pour les applications de type OLTP notamment en terme de cohérence des données. Elle assure un load-balancing de grande qualité, un failover performant pour la lecture et s’améliorant à chaque nouvelle version pour la mise à jour. Cependant, la scalabilité est moindre du fait notamment de la cohérence des données à assurer au niveau des caches de chaque nœud via un gestionnaire distribué de verrous ce qui induit un trafic réseau plus important entre chaque nœud. L’addition d’un nœud, quant à elle, peut être faite en mode « online ».

Les architectures de type big data reposent sur le concept de sharding. Il consiste en un partitionnement des données sur plusieurs machines. Il a été introduit par Google afin de disposer d’un modèle plus « scalable » que les solutions de type cluster proposées par les grands éditeurs tout en restant le moins onéreux possible au fur-et-à-mesure de l’ajout des machines. Ce partitionnement est géré automatiquement par le système via des tables de hachage distribuée (DHT). Suivant la nature de la distribution (maître ou non), cette table se trouve sur un nœud ou sur plusieurs nœuds. Elle peut être aussi partitionnée sur plusieurs nœuds.

Pour illustrer le concept de sharding, considérons l’architecture de MongoDB, une des solutions les plus utilisées dans le big data avec Cassandra. Le choix de la répartition se fait par collection. Les documents de cette collection (format BSON ) sont distribués le mieux possible entre les différents nœuds, au plus 1 000 en théorie, afin d’équilibrer les traitements. A chaque opération, il faut identifier le nœud qui contient les données. Ce rôle est assuré par un processus dédié qui reçoit les requêtes et les reroute sur le bon nœud. De plus, la continuité de service est assurée par un mécanisme de réplication de type maître-esclave à l’intérieur de chaque nœud, ce dernier pouvant définir un groupe de réplicas avec basculement automatique.

Perf
Mémoire, CPU, Disque… : La performance traquée sous toutes ses formes

Sur les architectures modernes, une partition sur un châssis peut disposer de plusieurs cœurs, chaque cœur pouvant traiter plusieurs threads. Cette nouvelle donne peut être utilisée par les moteurs de base de données quels qu’ils soient afin de paralléliser au maximum les traitements.

L’arrivée de nouvelles bases mémoire est en train de changer la localisation des données au niveau des bases. Jusqu’à maintenant, les données les plus usitées sont chargées dans des « buffer cache » en RAM. Désormais, des solutions comme MonetDB ou Hana de SAP sont capables de charger directement les données compressées non plus en RAM, mais dans le cache CPU. Il en découle une accélération des traitements car les accès RAM sont minimisés comme auparavant les accès disque : l’accès à la RAM est de l’ordre de 60-100 ns, l’accès au cache CPU de l’ordre de quelques ns suivant le niveau du cache.

Les systèmes critiques souffrent parfois de problèmes de latence au niveau réseau lors de l’utilisation du protocole TCP/IP. Pour dépasser ce type de limite, le réseau Infiniband a été créé ce qui permet aux différents éditeurs de proposer des protocoles plus performants, par exemple le protocole RDS. Il a pour but d’optimiser le transfert des données entre le système de stockage, par exemple une baie de disque et l’instance traitant ces données sur un serveur. Il utilise un bus bi-directionnel qui se caractérise par une latence faible (environ 1 microseconde) et des débits de plusieurs dizaines de Gbits/s.

Enfin, les serveurs de stockage permettent de filtrer les données récupérées sur les disques flash ou magnétiques. L’objectif est de diminuer au maximum le trafic réseau entre le système de stockage et le serveur de bases de données. Par exemple, Oracle dans son appliance Exadata a introduit un serveur de storage et une technologie appelée « smart scan » qui permettent de réduire la bande passante dans le cas des full scan table. Si la requête contient une condition, elle est prise en compte en amont au niveau du serveur de storage ce qui permet de ne retourner que quelques MB de données au lieu de quelques GB au serveur de bases de données.


Nous poursuivrons cette série par quelques fiches techniques sur les technologies ExaLytics, ExaData, MongoDB , Sap HANA… restez connectés.

Cet article a été rédigé par Stéphane NOTTER, Expert architecture et performance des données à Infotel.



Stéphane anime des Brown Bag Lunch (ou pique nique technique) sur les technologies liées au bases de données sous toutes leur formes:

  • « MongoDB vu par un expert Oracle »
  • « NoSQL vs SQL : l’écosystème de la base de données à l’heure du BigData »

Contactez-Nous !



Relationnel vs NoSQL : l’écosystème de la base de données à l’heure du « BigData » (1/2)

Au début des années 2000, le domaine de la gestion des données était dominé par les SGBDR commerciaux (DB2, Oracle, Sybase) et libres (PostegreSQL, MySQL). Ce type de système était capable de gérer quelques TB de données en transactionnel (OLTP) ou en analyse de données ( datawarehouse ).

En mode transactionnel, les SGBDR commerciaux étaient capables de gérer simultanément quelques milliers de transactions. Pour ce faire, ils avaient introduit la notion de cluster d’instances (option RAC pour Oracle), ce qui leur permettait de monter en charge via un ensemble de nœuds, au maximum 30 à 40. De plus, ils pouvaient offrir une vraie solution en termes de haute disponibilité en gérant de mieux en mieux le failover et le load-balancing.

En mode analytique, ils étaient capables de gérer des datamarts de quelques TB en se basant sur un modèle à étoiles ou à flocon. L’apport des index bitmap et des vues matérialisées permettaient d’optimiser ces modèles. De plus, le langage SQL était étendu par des fonctions analytiques afin de pouvoir couvrir au mieux les besoins.

Cependant, le modèle relationnel commençait à montrer ses limites dans le domaine de l’analytique. En effet, le langage SQL dédié au ROLAP est complexe et ne répond pas à tous les types d’analyses de données structurées. La création d’un datamart en relationnel est un processus relativement lent à mettre en œuvre et cette phase de conception n’est pas toujours compatible avec la réactivité demandée par le client.

Une première tentative de solution a alors été apportée avec la montée en puissance des moteurs multi-dimensionnels (Essbase). Le MOLAP repose sur le calcul d’un certain nombre de valeurs, chaque groupe de valeurs étant au cœur d’un système à plusieurs dimensions. Une dimension peut contenir plusieurs niveaux ce qui permet d’effectuer des calculs d’agrégat.

Mais ce modèle est très complexe à mettre en œuvre. En particulier, il est difficile de concevoir et de maintenir des systèmes à plus de 5 dimensions. Devant les limites des solutions ROLAP et MOLAP en terme d’analyse des données, le big data propose des bases de type colonne permettant d’optimiser la compression des données et la parallélisation des traitements. Un autre facteur d’accélération de ces bases est leur mise en mémoire. A titre d’exemple, on peut citer Hana de SAP , MonetDB ou Sybase IQ.


Par ailleurs, le big data permet enfin de traiter les données non structurées et non pas de se contenter de les stocker pour les restituer ultérieurement. En se basant sur le concept Map-Reduce d’Hadoop, il permet à travers diverses solutions comme MongoDB ou Cassandra de récolter et filtrer les données non structurées afin d’alimenter les systèmes existants et ainsi de leur fournir de nouveaux axes d’analyse.

Donnée structurée vs Non Structurée : quelle technologie pour quel besoin métier.

Nous allons plonger plus en détail dans les solutions qui s’imposent dans les différents types de traitement de la donnée. En voici un rapide panorama :

Pour traiter ce sujet, nous allons suivre comme fil conducteur le cycle général de vie de la donnée.

1
Alimenter la base cible.

En mode batch, on dispose de vrais ateliers de conception permettant de définir graphiquement les flux d’alimentation de la base. A l’image de Talend, ces derniers sont désormais des produits matures et sur les nouvelles applications, il est de plus en plus rare d’écrire des scripts d’alimentation de la base.

En mode « temps réel », la solution à base de webservices est devenu un standard de fait. De nombreuses équipes développent des services de ce type afin d’interconnecter les applicatifs entre eux. Cette solution propriétaire peut être normalisée et industrialisée au sein d’un EAI (Jeebop) ou d’un ESB (Tibco, solution IBM). De plus, ces middlewares nouvelle génération proposent tout type de connecteur afin de relier les anciens applicatifs aux nouvelles architectures.

Habituellement, les données sont stockées initialement dans une base relationnelle pour des raisons historiques mais aussi car ce modèle se prête bien à l’acquisition des données (respect des critères ACID, bonne montée en charge pour les mises à jour).

2
OLTP vers OLAP : « Refroidir » la
donnée.

Considérons un ensemble de données décrivant une opération à un instant t (opération bancaire, réservation d’un billet, achat d’un objet). Une fois l’opération validée, les données sont insérées immédiatement dans un ensemble de tables normalisées au préalable lors de la phase de conception (formes NF). Si ces données sont très volumineuses, de l’ordre de quelques dizaines de GB dans un intervalle de temps donné, un partitionnement est défini afin d’optimiser les performances en lecture. Ce type de donnée dit « hot » au début, puis « cold » par la suite est transmis en partie au système OLAP, puis soit purgé, soit historisé sur des supports physiques moins coûteux (disques magnétiques) si on dispose de mémoire flash.

L’autre grand type de donnée plus pérenne dans le temps est constitué par les données liées au référentiel de la base (caractéristiques du client, du produit). La mise à jour de ces données est moins fréquente et effectuée la plupart du temps via des batchs de nuit. Cette partie de la base est complètement normalisée, d’où l’utilisation de nombreuses contraintes ( contraintes sur la valeur des colonnes des tables, clés primaires et étrangères ) assurant une forte intégrité des données. Par ailleurs, ce type de donnée va ultérieurement constituer une grande partie des axes d’analyse des datawarehouses.

Une fois ces données transmises au système OLAP, il est alors temps de se poser la question du type de système utilisé. Pour ce faire, on peut considérer les trois critères suivants :

  • La nature de la donnée, structurée ou non ;
  • La volumétrie ;
  • La complexité et la richesse du système d’interrogation.

Si les données sont structurées, la volumétrie raisonnable (quelques dizaines de TB) et les requêtes prédéfinies, le modèle relationnel étendu au datawarehouse (ROLAP) continuera à répondre aux attentes. En termes de conception, on opte pour un modèle à étoile ou à flocon. Pour optimiser le modèle, on utilise des index bitmap, voir des index bitmap join et des vues matérialisées pour cacher des pré-calculs. Le langage SQL est étendu afin de pouvoir traiter un certain nombre d’interrogations (fonctions ROLLUP, CUBE, GROUPING en Oracle ).

Ce modèle ne traite pas les données non structurées, il montre ses limites au-delà d’une certaine volumétrie et surtout, il n’offre aucune souplesse au niveau de son système d’interrogation. En effet, il va falloir écrire de nouvelles requêtes complexes pour chaque nouveau besoin exprimé par le client.

3
Démultiplier l’analyse avec les hypercubes.

Si les données sont structurées, la volumétrie raisonnable (quelques dizaines de TB) et les données prédéfinies, le modèle multi-dimensionnel ( MOLAP ) apporte une réponse plus étoffée. Il repose sur un ensemble d’hypercubes multidimensionnels. Les données sont représentées sous forme d’un croisement de n dimensions. Les valeurs des dimensions peuvent être hiérarchisées en niveaux ce qui permet une grande richesse de calculs d’agrégat. De plus, les hypercubes occupent moins de place que les tables s’ils sont peu denses, ce qui est souvent le cas.

Ce modèle offre une grande richesse en termes d’interrogation, car l’hypercube permet de récupérer immédiatement un nouveau calcul d’agrégat, sans avoir à réécrire le moindre de code. Cependant, il devient complexe à comprendre et à maintenir à plus de 5 dimensions et on évite de dépasser 10 dimensions pour des raisons de performance. De plus, le processus de création des hypercubes est délicat à mettre en œuvre. Enfin, il ne traite pas les données non structurées.

4
ouveaux ordres de grandeurs == nouveaux paradigmes : BigData.

Vu les limites des deux modèles précédents, le monde du big data est susceptible de fournir des améliorations afin d’analyser les données à des échelles plus grandes. Le premier apport est sa capacité à analyser des données non structurées grâce à son mécanisme map/reduce (Hadoop). Ce dernier reposant son calcul sur un très grand nombre de nœuds (probablement plusieurs dizaines de milliers chez Google), il distribue la puissance nécessaire à l’exploitation de la donnée libre. Cela permet d’injecter de nouvelles informations non traitées dans les systèmes actuels.

Dans un autre registre, la sphère big data a remis au goût du jour les bases mémoire (Redis, Hana de SAP) ce qui va permettre d’aller au-delà des précédentes solutions (ISAM, Timesten d’Oracle). Cette avancée constitue un facteur d’accélération considérable pour analyser les données, phénomène facilité par la possibilité de pouvoir charger plusieurs TB de données en RAM.

Enfin, le modèle à colonnes commence à s’imposer dans les entreprises. Ce modèle est très intéressant car exécuté en mémoire, voir dans le cache des CPU, il peut être parallélisé sur plusieurs CPU et prend très peu de place du fait de sa grande capacité à être compressé (les données se « ressemblent » plus par colonnes que par lignes).

à suivre …… A la recherche de la performance