En travaillant avec Datastax DSE pour les besoins d'un projet d'identification de patients éligibles à des essais cliniques, nous avons profité pour stocker toutes nos données dans Cassandra.
L'idée étant d'évaluer la pertinence à utiliser Cassandra pour ce type de use cases: stocker des données structurées et non structurées dans une base noSQL scalable, robuste etc.
Très vite le problème de la modélisation des données se pose. Avec Cassandra nous sommes dans un monde NoSQL très éloignés des bases relationnelles classiques du type MS SQL SERVER, Oracle ou MySQL.
L'article publié par Tyler HOBBES de chez DATASTAX est fort intéressant. J'en fait une rapide synthèse en français pour les lecteurs non anglophones
Source: http://www.datastax.com/dev/blog/basic-rules-of-cassandra-data-modeling
Synthèse:
Définir le bon modèle de données est probablement la partie la plus difficile avec Cassandra.
Pour bon nombre de développeurs ou de DBAs, ils sont tentés de reproduire les réflexes acquis sur les bases relationnelles. Même si le langage CQL de Cassandra semble proche du SQL, la modélisation à appliquer est fort différente.
Le but de cette article est donc d'expliquer à travers un court exemple les règles basiques à garder en tête pour modéliser correctement dans Cassandra et ainsi garantir que la base conservera des performances prévisibles et linéaires au fur et à mesure des besoins et de l'ajout de "nodes".
Afin d'obtenir les lectures les plus efficaces, vous aurez souvent besoin de dupliquer les données.
En outre, Cassandra ne connait pas les jointures et vous ne voudrez certainement pas utiliser celles-ci dans une architecture distribuée.
Répartir les données Spread data uniformément dans le cluster
Minimiser le nombre de partitions à lire
Ne modéliser pas en tenant compte des relations entre entités, tables etc.
1/ déterminer quelles requêtes la base doit supporter
2/ essayer de créer une table permettant à votre requête de lire une seule partition. En pratique cela se traduit par la lecture d'une table par type de requête. Si vous avez besoin de plusieurs types de requêtes, vous avez certainement besoin de plus d'une table. Dit autrement, chaque table devrait pré-construire la réponse à une requête de haut niveau. Si on a besoin de différentes réponses, on a besoin de différentes tables. C'est ainsi que Cassandra permet d'optimiser les lectures.
Je vous invite à lire l'article original en anglais pour un exemple pratique.
Plus d'infos:
https://www.youtube.com/watch?v=jxGRbOpPql4
L'idée étant d'évaluer la pertinence à utiliser Cassandra pour ce type de use cases: stocker des données structurées et non structurées dans une base noSQL scalable, robuste etc.
Très vite le problème de la modélisation des données se pose. Avec Cassandra nous sommes dans un monde NoSQL très éloignés des bases relationnelles classiques du type MS SQL SERVER, Oracle ou MySQL.
L'article publié par Tyler HOBBES de chez DATASTAX est fort intéressant. J'en fait une rapide synthèse en français pour les lecteurs non anglophones
Source: http://www.datastax.com/dev/blog/basic-rules-of-cassandra-data-modeling
Synthèse:
Définir le bon modèle de données est probablement la partie la plus difficile avec Cassandra.
Pour bon nombre de développeurs ou de DBAs, ils sont tentés de reproduire les réflexes acquis sur les bases relationnelles. Même si le langage CQL de Cassandra semble proche du SQL, la modélisation à appliquer est fort différente.
Le but de cette article est donc d'expliquer à travers un court exemple les règles basiques à garder en tête pour modéliser correctement dans Cassandra et ainsi garantir que la base conservera des performances prévisibles et linéaires au fur et à mesure des besoins et de l'ajout de "nodes".
Les pratiques à éviter
Vouloir minimiser le nombre d'écritures
Dans Cassandra, les écritures ne sont pas un problème. Elles sont peu coûteuses et Cassandra est optimisée pour un haut niveau d'écritures toutes avec la même efficacité.
C'est donc un bon compromis de faire des écritures supplémentaires afin d'optimiser les requêtes en lecture.
Dans Cassandra, les écritures ne sont pas un problème. Elles sont peu coûteuses et Cassandra est optimisée pour un haut niveau d'écritures toutes avec la même efficacité.
C'est donc un bon compromis de faire des écritures supplémentaires afin d'optimiser les requêtes en lecture.
Vouloir minimiser la duplication des données
Dénormaliser et dupliquer les données est une pratique normale dans Cassandra. L'espace disque est généralement la ressource la moins chère en comparaison du CPU, de la RAM etc.) et Cassandra est designée pour cela. Afin d'obtenir les lectures les plus efficaces, vous aurez souvent besoin de dupliquer les données.
En outre, Cassandra ne connait pas les jointures et vous ne voudrez certainement pas utiliser celles-ci dans une architecture distribuée.
Ce qu'il faut privilégier
Répartir les données Spread data uniformément dans le cluster
Minimiser le nombre de partitions à lire
Modéliser en fonction de vos requêtes
Ne modéliser pas en tenant compte des relations entre entités, tables etc.
1/ déterminer quelles requêtes la base doit supporter
2/ essayer de créer une table permettant à votre requête de lire une seule partition. En pratique cela se traduit par la lecture d'une table par type de requête. Si vous avez besoin de plusieurs types de requêtes, vous avez certainement besoin de plus d'une table. Dit autrement, chaque table devrait pré-construire la réponse à une requête de haut niveau. Si on a besoin de différentes réponses, on a besoin de différentes tables. C'est ainsi que Cassandra permet d'optimiser les lectures.
Je vous invite à lire l'article original en anglais pour un exemple pratique.
Plus d'infos:
https://www.youtube.com/watch?v=jxGRbOpPql4
Comments
Post a Comment