SQLFire depuis les tranchées

Il y a plus d’un an nous vous avions présenté NewSQL et comment distribuer ses données avec l’une des implémentations de cette architecture SQLFire. 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. Nous vous partageons aujourd’hui deux articles (en anglais). Le premier détaille notre cas d’utilisation et la distribution des données dans ce cas. Le second livre les résultats chiffrés des tests de charge réalisés sur notre POC avec SQLFire.

Nouveautés de la base NoSQL Apache Cassandra 1.2

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

NewSQL: Comment distribuer ses données avec SQLFire

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

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

Les patterns des Grands du Web – TP versus BI : la nouvelle approche NoSQL

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

Bases de données graphes : un tour d’horizon

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

CQRS, l’architecture aux deux visages (partie 2)

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

Introduction aux graphes avec Neo4j et Gephi

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