Top Posts This Month
Upcoming Webinars

Modèle de stockage physique dans Cassandra : Détail sur le stockage physique dans C*

July 22, 2014

By 

Dans cet article, nous détaillons la façon dont le moteur de stockage organise les données sur disque et les différents types de colonnes que l’on trouve dans C*. Si vous avez raté le premier article d’introduction au modèle de données dans C*, c’est par ici.

Le type composite

Si le modèle de données de C* devait s’arrêter à la simple abstraction des Map imbriquées, on n’irait pas bien loin. En effet, les requêtes avec un tel modèle sont plutôt limitées. Heureusement pour nous, le type composite a été introduit et avec lui de nouvelles possibilités pour requêter les données.

Définition

L’idée du type composite est qu’au lieu d’avoir un seul type pour les #partition ou #col, on en définit plusieurs… Concrètement , il s’agit de stocker dans une clé (de partition ou de colonne) plusieurs composantes de type différent. Ainsi on aura :

Pour les composites de colonnes, les données seront triées dans l’ordre successif de leurs composantes. Si on a une composite de colonne de type DateType:UTF8Type:LongType par exemple, les #cols seront triées par date, puis par tri lexicographique et enfin par ordre naturel des entiers.

En théorie on peut mettre autant de composantes différentes que l’on veut, en pratique on s’arrêtera à 2 – 3 composantes pour les composites.

L’abstraction en structure de données correspondante est :

Exemple

Sans plus tarder, voyons en pratique comment fonctionnent les composites.

Supposons qu’on veuille stocker l’hygrométrie (température et humidité entre-autres) pour différentes villes en France et à différents moments. Naturellement, on choisira le nom de la ville comme #partition et la date comme #col. Sans les composites, on devrait logiquement stocker la température et l’humidité dans la cellule.

Ci-dessous le script de création de la table avec l’API Thrift :

Et les données :

On se rend bien compte qu’il faut arriver à stocker nos métriques de température et d’humidité dans une seule cellule pour chaque date. On peut soit tout stocker sous forme de String et faire le découpage à la main, soit stocker sous forme sérialisée en JSON ou bytes. Quoiqu’il en soit, cela n’est pas très pratique au final.

En ligne de commande, avec le client cassandra-cli, on verrait ceci :

Avec les composites, le problème sera résolu de manière plus élégante :

Ici la #col a deux composantes, la première de type LongType pour coder la date au formatYYYYMMdd et la deuxième de type UTF8Type pour coder le type de mesure (température ou humidité).

Les données seront stockées de la manière suivante :

Avec le client cassandra-cli :

L’utilisation des composites dans ce cas a permis de séparer, pour une date donnée, la température et l’humidité dans deux colonnes physiques distinctes.

On réserve une colonne physique pour chaque type de mesure, ici température et humidité. On notera également que la valeur de la date est dupliquée, une fois pour chaque type mesure :

Si l’on introduisait des types de mesure supplémentaires, temperature ressentie et humidite relative par exemple, on aurait eu en base :

Cette fois ci, la date est dupliquée 4 fois.

On voit bien que les composites permettent une plus grande facilité pour modéliser les données. Par contre, le prix à payer est une plus grande consommation en espace disque.

Abstraction et Requêtes

Pour l’exemple de la table d’hygrométrie ci-dessus, l’abstraction en structure de données correspondante est :

Avec une telle structure de données, les types de requêtes différentes que l’on peut faire sont :

  1. Pour une ville, donner toutes les mesures quelle que soit la date (requête coûteuse sans clause limit car on remonte toutes les colonnes sur la partition correspondante à une ville)
  2. Pour une ville et une date, donner la valeur de la température
  3. Pour une ville et une date, donner la valeur de l’humidité
  4. Pour une ville et une date entre 2 bornes, donner les mesures d’hygrométrie

Et c’est tout ! Le lecteur attentif se demandera s’il est possible, pour une ville et un type de mesure donné, de lister les valeurs à toutes les dates. Ce n’est simplement pas possible.

Pourquoi ?

Parce qu’en regardant la structure de données présentée plus tôt, pour accéder à la valeur d’hygrométrie, il faut d’abord donner la ville, puis la date, puis le type de mesure, précisément dans cet ordre là.

Pour pouvoir faire la requête demandée, il faudrait inverser le type de mesure et la date et créer une table comme suit :

Voir l’article complet ici: http://www.infoq.com/fr/articles/modele-stockage-physique-cassandra-details

Click to Deploy Apache Cassandra on Google Compute Engine

July 21, 2014

By 

If you saw our post about Cassandra hitting 1 million writes per second on Google Compute Engine, then you know we’re getting serious about open source NoSQL. We’re making it easier to run the software you love at the scale you need with the reliability of Google Compute Platform. With over a dozen different virtual machine types, and the great price for performance of persistent disks, we think Google Compute Engine is a fantastic place forApache Cassandra.

Today, we’re making it even easier to launch a dedicated Apache Cassandra cluster on Google Compute Engine. All it takes is one click after some basic information such as the size of the cluster. In a matter of minutes, you get a complete Cassandra cluster deployed and configured.

Each node is automatically configured for the cloud including:

  • Configured with the GoogleCloudSnitch for Google Cloud Platform awareness
  • Writes tuned for Google Persistent Disk
  • JVM tuned to perform on Google Compute Engine instances

The complete set of tuning parameters can be found on the Click to Deploy help page.

So, get out and click to deploy your Cassandra cluster today!

Learn more about running Apache Cassandra on Google Compute Engine athttps://developers.google.com/cloud/cassandra.

-Posted by Brian Lynch, Solutions Architect

Cassandra, is registered trademarks of Apache, Inc. All other trademarks cited here are the property of their respective owners.

Click to Deploy Apache Cassandra on Google Compute Engine” was created by Brian Lynch, Solutions Architect at Google.

Womply uses Spark with Cassandra to Affordably Analyze Time Series Payment Data

July 18, 2014

By 

Womply 

 “Cassandra was a good fit with our product requirements; storing time series data is one of Cassandra’s sweet spots and is a core feature of our product.

- Brent Theisen, Lead Developer at Womply

David Leimbrock

 Brent Theisen Lead Developer at Womply

 

Womply

Womply is a next generation payments data company. We partner with merchant-facing companies including credit card processors and acquirers to analyze data for millions of merchants across the US.

My role at Womply is that of a lead developer who gets to work on a wide variety of technologies. On any given day I might be automating our VM provisioning with Chef, writing an ETL process in Java/Scala or implementing some new feature using Ruby on Rails.

 

Cassandra and Spark

We use Cassandra for dashboards that allow merchants to analyze their revenue and compare it against merchant aggregates in their area and/or vertical.

We evaluated HBase pretty heavily but found that the operational demands imposed by it were much greater than Cassandra.

We are currently using Cassandra 2.0.8 in combination with Apache Spark 1.0. The revenue data we collect gets stored directly in Cassandra. From there we use Apache Spark to precompute and persist to Cassandra several time series aggregates with partition keys like category, city/state and Screen Shot 2014-07-18 at 4.23.21 PMnearest merchants.

Our revenue data needs to be aggregated into several different kinds of time series which is an excellent fit for Cassandra.

 

Top Benefits

Cassandra was a good fit with our product requirements; storing time series data is one of Cassandra’s sweet spots and is a core feature of our product.

It’s also relatively easy to manage from an operations perspective. On top of that, having no single point of failure (SPOF) is great, and it is easy to scale up/down. The Chef cookbook support is also beneficial.

Lastly, Cassandra is very affordable.  Our cluster uses entirely open source software so there are no licensing fees to pay.

 

Deployment

We have one Cassandra data center that also runs Spark locally on each node. Spark allows you to set max core and RAM usage thresholds so we’ve set max cores to half of the virtual cores on each EC2 instance. This has allowed us to run Spark jobs on the same nodes that also serve real-time queries from our web application with minimal performance degradation.

 

Advice

If you need to run massive parallel processing jobs consider using Spark instead of map reduce. Spark will allow you to write jobs more quickly that will run much faster. Also getting it installed and integrated with Cassandra is much easier/cheaper than Hadoop.

 

Community

Our experience with the community has been really good. While setting up our initial proof of concept I found a bug in the Cassandra Hadoop input format. The patch I submitted was merged up to trunk within 24 hours and was included in a release a few days after that. We’ve also had similarly good experiences with other open source projects in the Cassandra orbit like Calliope and the Cassandra Chef cookbook.

Modèle de stockage physique dans Cassandra

July 14, 2014

By 

Voici le premier article d’une longue série sur la modélisation de données dans Apache Cassandra avec CQL3.

Qu’est ce que Cassandra ?

Avant d’entrer dans le vif du sujet, une petite présentation de la base de données Apache Cassandra s’impose pour ceux qui ne la connaissent pas.

Historique

Apache Cassandra est une base de données de la famille NoSQL très en vogue. Elle se classe parmi les bases orientées colonnes tout comme HBase, Apache Accumulo, Big Table. Cette base a été développée à l’origine par des ingénieurs de Facebook pour leurs besoins en interne avant d’être mise à la disposition du grand public en open-source.

Pour la petite histoire, dans le code source de Cassandra, on retrouve encore des classes préfixées avec FB (comme Facebook) qui rappelle cette origine.

Origine du nom

Une petite anecdote veut que le nom de Cassandra ait été choisi par rapport à Oracle. D’après la mythologie grecque, Cassandra est un oracle maudit qui prédisait du malheur mais dont personne ne voulait croire les prédictions, jusqu’au jour où … C’était un clin d’oeil très explicite à la base de données Oracle, faite à l’époque par les ingénieurs de Facebook.

Cluster

Quand on parle de Cassandra, on parle souvent de cluster. Un cluster est un regroupement de plusieurs noeuds (serveur physique) qui communiquent entre eux pour la gestion de données.

Ci-dessus un exemple d’un cluster Cassandra à 5 noeuds. Les noeuds communiquent entre eux par un protocole peer-to-peer qu’on appelle le Gossip (bavardage).

Théorème CAP

Dans le monde des bases de données NoSQL, on entend souvent parler du Théorème CAP. Ce théorème établit 3 paramètres sur lesquels on peut jouer pour configurer une base de données distribuée :

  1. La cohérence ( C pour Consistency)
  2. La disponibilité ( A pour Availability)
  3. La tolérance aux pannes et aux coupures réseaux ( P pour Partition-tolerance)

Le théorème postule que pour toute base de données distribuée, on ne peut choisir que 2 de ces 3 paramètres, jamais les 3 en même temps. En théorie, on peut donc choisir les couples suivants :

a. Cohérence et disponibilité ( CA ) donc non résistante aux pannes ( P )
b. Cohérence et tolérance aux pannes ( CP ) donc non disponible à 100% ( A )
c. Disponibilité et tolérance aux pannes ( AP ) donc non cohérente à 100% ( C )

Ceci est la théorie. En pratique, on se rend compte que le paramètre P est plus ou moins imposé. En effet, les coupures réseaux cela arrive, c’est inévitable, même si on s’appelle Google… Du coup, le choix se résume en fin de compte à CP ou AP. Cassandra fait clairement le choix de AP pour une tolérance aux pannes et une disponibilité absolue. En contrepartie, Cassandra sacrifie la cohérence absolue (au sens ACID du terme) contre une cohérence finale, c’est à dire une cohérence forte obtenue après une convergence des données (garantie par un ensemble de mécanisme d’anti-entropie).

Architecture

L’architecture Cassandra (qu’on va appeler désormais en C* pour plus de concision) s’inspire énormément du papier de recherche Big Table de Google , ainsi que de l’architecture Dynamo d’Amazon. Le moteur de stockage de C* dérive directement de Big Table alors que sa couche de distribution de données s’inspire de l’architecture de Dynamo.

Sur le schéma ci-dessus, on distingue la présence de 3 couches métiers :

  • API, responsable de recevoir les requêtes venant des clients sous format Thrift (protocole RPC) ou dans le nouveau format binaire CQL3
  • Dynamo, responsable de la distribution des données entre différents noeuds et du protocole peer-to-peer
  • Base de données, responsable de la persistance des données sur disques

Désormais et jusqu’à la fin de cette série d’articles, on s’intéressera uniquement à la couche base de données, les autres couches techniques feront l’objet d’articles ultérieurs.

Voir l’article complet ici: http://www.infoq.com/fr/articles/modele-stockage-physique-cassandra

ZoneFox Presents at Apache Cassandra Meetup

July 11, 2014

By 

Recently, two members of the ZoneFox development team, Darren Hart and Adam Masters, presented to a Cassandra meetup hosted by Datastax.  They spoke about how we at ZoneFox are utilising the enormous potential of Apache Cassandra.

The talk was geared towards explaining why we chose a distributed database such as Cassandra, the technologies that we had come from and where Cassandra has allowed us to push the application. During the session we also spoke about the mistakes that we initially made with the new technology and shared some of our lessons learned and best practices with others who may find themselves in the same position we were in 12 months ago.

We looked into how we structure our data and how we use Cassandra to its fullest potential in combination with Hadoop, Elasticsearch, as well as our own technologies.  This combination of tools allows us to efficiently record, archive and analyze data against set rules to satisfy our clients’ needs for a robust cyber-security product.

We also discussed some of the new features that are expected in the next round of Cassandra upgrades and how we plan to use them to provide cutting edge solutions for our clients.

It was a great event, we really appreciated the questions and feedback from the attendees and are looking forward to the next Cassandra in Practice MeetUp!

ZoneFox Presents at Apache Cassandra Meetup was originally posted on the ZoneFox Blog

1 2 3 126