Introduction

A OCTO, nous suivons depuis quelques années déjà l’évolution de la base NoSQL Apache Cassandra. La sortie de la version 1.2 en janvier 2013 nous donne l’occasion de faire le tour d’horizon des évolutions récentes du produit. En résumé, on observe récemment une amélioration de l’expérience d’utilisation de Cassandra grâce à une simplification de la modélisation des données, du requêtage et de l’administration pour les opérationnels. Le tout en gardant les fondamentaux de la solution à savoir les performances, la disponibilité et la scalabilité.

(Lire la suite…)

Big data, dataviz, NoSQL, virtualisation de données, agile, appliance, selfservice BI… Finalement, cela en fait des buzzword associés à la Business Intelligence et à nos architectures décisionnelles !

Il est facile de comprendre la difficulté à se positionner dans ces environnements en tant que responsable du décisionnel dans une entreprise. (Lire la suite…)

Contexte

SQLFire est une base de données relationnelle « in memory », c’est-à-dire qu’à tout instant ses données sont disponibles en mémoire vive. Les performances attendues sont donc très élevées, mais ce choix impose une limite sur le volume de données que peut stocker efficacement une instance (hors overflow sur le disque).

Pour franchir cette limite, pour permettre un failover en cas de panne matérielle et pour pouvoir monter en puissance, les concepteurs de SQLFire ont choisi d’encourager les développeurs à partitionner et répliquer leurs données sur plusieurs machines, toutes connectées sur un réseau local.

L’architecture choisie est de type share nothing, ce qui a des conséquences intéressantes à la fois pour le développeur et pour les performances. Ce deuxième article va présenter le mécanisme de partitionnement de SQLFire, proposer une méthodologie pour adapter le modèle de données, et discuter les conséquences des choix d’architecture de la solution.

(Lire la suite…)

NewSQL. Beaucoup penseront à NoSQL. NewSQL est tiré du monde NoSQL mais reste différent. Comme NoSQL il s’agit d’une nouvelle architecture logicielle qui propose de repenser le stockage des données. Comme NoSQL elle tire partie des architectures distribuées, des progrès du matériel et des connaissances théoriques depuis 30 ans. Mais contrairement à NoSQL elle permet de conserver le modèle relationnel au coeur de notre SI. Est-ce seulement un moyen de plus pour surfer sur la vague NoSQL? Nous ne le pensons pas. Dans cette série d’articles nous allons étudier en profondeur cette architecture. Notre objectif est de vous montrer les innovations et leurs apports dans l’architecture de stockage d’un SI d’aujourd’hui. Cette étude a été étayée par la réalisation d’un POC tirée d’un cas réel pour vous faire partager également les difficultés de mise en oeuvre de tels produits.
(Lire la suite…)

Dans les SI traditionnels, les architectures de traitement de données structurées se sont généralement organisées en deux pôles distincts. Toutes les deux s’appuient certes sur une base de données relationnelle, mais avec des modèles et des contraintes propres

• D’un côté, le Transactional Processing (TP), à base de transactions ACID
• De l’autre la Business Intelligence (BI),  à base de tables de faits et de dimensions

Les Grands du Web ont mis en place à la fois de nouveaux outils et de nouvelles façons d’organiser les traitements pour répondre à ces deux besoins. La distribution du stockage et des traitements est notamment largement utilisée dans les deux cas.

(Lire la suite…)

Dans un précédent article, nous avons introduit quelques concepts à propos des graphes, et les avons illustrés par deux exemples en utilisant la base de données graphe Neo4j.
Au cours de ces dernières années, de nombreuses compagnies ont développé leur solution de base de données graphe, en tant qu’éditeur comme Neo Technology avec Neo4j, Objectivity avec InfiniteGraph ou encore Sparsity avec dex*, ou en développant leur propre solution pour l’intégrer à leur application, comme LinkedIn ou Twitter.
Il est donc assez difficile de s’y retrouver dans ce paysage riche, qui continue à évoluer très vite.
Dans ce nouvel article qui se focalise sur les bases de données graphes, nous donnerons les éléments nécessaires à la compréhension de leur positionnement dans leur écosystème, par rapport aux autres types de base de données et aux autres types d’outils dédiés au traitement de graphes.
Plus précisément, nous essaierons de répondre à une question importante, à savoir quand utiliser une base de données graphes et quand ne pas en utiliser, ce qui n’est pas forcément évident.

(Lire la suite…)

Dans le billet CQRS l’architecture aux deux visages (partie 1), nous vous avions présenté les bases d’une architecture CQRS. En effet une application combine des fonctionnalités de consultation d’une part (Read) et traitement métier d’autre part (Write). CQRS propose d’aborder ces deux groupes de fonctionnalités comme deux contextes d’utilisation distincts afin d’appliquer des stratégies de design adaptées à leurs besoins spécifiques.

Dans cet article, nous allons essayer d’apporter des réponses à la question laissée en suspens : comment construire une application satisfaisant aux exigences liées au contexte de restitution d’information d’une part, et au contexte de traitement de l’information d’autre part, tout en conservant un modèle explicite respectant les principes DDD évoqués dans l’article Domain Driven Design, des armes pour affronter la complexité  (« Domain-driven design is not a technology or a methodology. It is a way of thinking and a set of priorities, aimed at accelerating software projects that have to deal with complicated domains » ) .

(Lire la suite…)

Les solutions permettant de modéliser, stocker et parcourir de façon efficiente des graphes ont profité de plusieurs éléments qui les ont rendues populaires ces dernières années.

Le premier élément aidant à leur démocratisation est l’explosion des réseaux sociaux. Un cas d’usage évident, facile à comprendre même  si, étrangement, les solutions mises en œuvre ne sont pas forcément de « type graphe » (par exemple avec FlockDB chez Twitter).

Le second est lié au mouvement NoSQL qui a aidé à diffuser l’idée que la base relationnelle n’est pas la seule solution de stockage et de requêtage.

Enfin, et même si la théorie des graphes n’est pas neuve, les algorithmes sous-jacents et certaines implémentations ont atteint un niveau de maturité permettant la « commoditisation » de ces technologies, les aidant du même coup à sortir de zones très spécifiques.

Alors qu’est-ce qu’un graphe? A quoi cela peut-il bien servir? Et finalement comment travaille-t-on avec  en termes d’API et  de solution ?

A travers deux exemples simples, voici une introduction aux graphes, leur stockage et leur analyse, en utilisant Neo4j, une base de données graphe, et Gephi, un outil open-source de visualisation et d’analyse de graphe.

(Lire la suite…)

Le modèle relationnel est né à une époque où l’espace était rare, et fut donc conçu pour minimiser le niveau de redondance des données: il était plus économique de stocker une indirection vers une chaine de caractères que de stocker cette chaine deux fois.
Aujourd’hui, cette contrainte d’espace ne tient plus. On achète un Teraoctet pour 100 dollars, la RAM est abondante, et les disques flash aux performances élevées vont bientôt rejoindre le prix des disques durs rotatifs.

Deux limitations fondamentales du stockage ont donc disparu: le coût de la redondance et le coût de la non-localité pour le traitement de structures de données complexes. Il est maintenant possible de concevoir de nouvelles bases de données plus riches et plus sûres.

(Lire la suite…)

Jeudi 15 décembre, OCTO organisait un petit-déjeuner NoSQL : « l’Extreme Transaction Processing, devient une réalité ».

Aujourd’hui, la multiplication des systèmes connectés à Internet (smartphone, tablette, TV connectée, véhicule connecté) et l’émergence des nouveaux flux de données issus notamment du web social (Facebook commerce, mobile-to-mobile, etc) vont pousser un peu plus les Systèmes d’Information vers l’Extreme Transaction Processing (XTP).

(Pour plus d’informations sur le contenu, veuillez cliquer ici)

Grâce à la vidéo de l’évènement disponible sur You Tube, vous pouvez découvrir les divers points abordés lors de ce Petit-Déjeuner, à savoir :

• les concepts et les opportunités métiers autour de l’ »Extreme Transaction Processing« 
• les enjeux d’architecture et d’exploitation
• les fonctionnalités et l’implémentation faite par les solutions VMware Gemfire et SQLFire

Pour tout autre renseignement, contactez nous sur : contact@octo.com