NoSQL

Agenda
• Un peu d’histoire
• Qu’est ce que le NoSQL
• Théorème CAP
• Qu’est ce que l’on perd
• Types de base NoSQL
• Les différents Frameworks
 History of the World, Part 1
• Relational Databases – pilier du business
• Les applications web entraine un étranglement
– Particulièrement vrai pour les site de e-
commerce
• Les développeurs ont commencé à mettre
devant leur base de données des mécanismes
de cache type memcache ou intégré d’autres
mécanismes de cache au sein de leurs
applications (ex. Ehcache)
 Passé à l’échelle
• Problèmes pour passer à l’échelle quand les
données sont justes trop grandes
• Les RDBMS ne sont pas conçues pour être
distribuées
• Les développeurs/architectes ont commencé à
regarder des solutions avec plusieurs noeuds
• Differentes approches qui incluent :
– Master-slave
– Sharding
Scaling RDBMS – Master/Slave
• Master-Slave
– Tous les écrivains écrivent au master.
Toutes les lectures sont faites sur les
bases de données esclaves
– Les lectures critiques peuvent être
incorrectes
– L’écriture de gros volume de données
pose des problèmes car le maître doit
dupliquer les données à tous les esclaves
 Scaling RDBMS - Sharding
• Partition ou “sharding”
– Passe correctement à l’échelle pour la
lecture et l’écriture
– Ce n’est pas transparent, l’application doit
avoir conscience de la partition
– Perte de la possibilité de faire des
jointures/relations entre partitions
– Perte de l’intégrité réferentielle entre
partitions
 Autres solutions
• Multi-Master replication
• INSERT only, not UPDATES/DELETES
• No JOINs, thereby reducing query time
– This involves de-normalizing data
• In-memory databases
 Qu’est ce que le NoSQL?
• Signification Not Only SQL
• Une classe de système de stockage de
données non-relationnelle
• Habituellement, elle ne requièrt pas un
schéma de table fixe ni le besoin de jointure
• Toutes les bases de données NoSQL
relachent au moins une ou plus des
propriétés ACID
Pourquoi une base de données
NoSQL?
• Pour stocker des données ;)
• Exactement comme il y a plusieurs
langage de programmation, il est
nécessaire d’avoir une boîte à outils avec
différents outils pout stocker des
données
 Comment est ce arrivé?
• Explosion des réseaux sociaux (Facebook, Twitter) avec
des problèmes pour gérer de gros volumes de données
• Apparition d’offre de cloud comme Amazon S3, ou
google apps engine
• Un mouvement du aussi à l’usage de langage
dynamique comme Ruby/Groovy, qui entraine des
changements fréquents dans le modèles de données
• Une large communauté Open-source
 Dynamo et BigTable
• Trois papiers majeurs ont été la semence
du mouvement NoSQL
– BigTable (Google)
– Dynamo (Amazon)
• Gossip protocol (discovery and error detection)
• Distributed key-value data store
• Eventual consistency
– CAP Theorem (discuté tout de suite)
 La révolution
• De gros volumes de données, l’utilisation
de langage dynamique, et l’utilisation
d’alternatives aux RDBMS sont arrivés
ensemble
• Ce n’est pas une révolution contre les
RDBMS
• Un langage comme SQL est un langage
de requête riche qui n’a pas de rivale
dans la liste des offres NoSQL
 CAP Theorem
• Trois propriétés d’un système: consistency,
availability and partitions
• Vous ne pouvez avoir plus de deux de ces
propriétés pour tous systèmes à données
partagées
• Pour passer à l’échelle, vous avez besoin des
partitions. Il vous reste donc à choisir entre la
cohérence et la disponibilité
– Dans la plupart des cas, vous choisirez la
disponibilité
 Disponibilité
• Traditionnellement, on pense/souhaite
avoir un serveur disponible 99.999 %.
• Cependant dans un système réparti, il y
a des chances d’avoir tout le temps au
moins un noeud par terre.
– Nécessaire d’avoir un système robuste
contre ce genre de panne
 Eventuellement cohérent
• Quand aucune modification n’a lieu
pendant longtemps, toutes les mises à
jours seront propagées sur tous les noeuds
et le système sera peut-être cohérent
• Connu sous l’acronyme BASE (Basically
Available, Soft state, Eventual
consistency), à opposer aux propriétés
ACID
 Quelles sortes de NoSQL
• Deux grandes catégories
– Key/Value ou ‘the big hash table’.
• Amazon S3 (Dynamo)
• Voldemort
• Scalaris
– Schema-less qui viennent de différentes sortes :
column-based, document-based ou graph-based.
• Cassandra (column-based)
• CouchDB (document-based)
• Neo4J (graph-based)
• HBase (column-based)
 Key/Value
Pour:
– Très rapide
– Passe très bien à l’échelle
– Modèle simple
– Peuvent être distribué de manière
horizontale
Contre:
- Beuacoup de données structuré ne rentre pas
bien dans un modèle key/value
 Schema-Less
Pour:
- Plus riches que le modèle key/value
- Eventuellement consistente
- La plupart sont distribuées
- Fournissent tjrs de très bonne
performance et passe à l’échelle
Contre:
- Pas de propriétés acid ni de transactions
 Avantages communs
• Peu cher, facile à utiliser (open source)
• Les données sont répliqués sur de nombreux noeuds et
peuvent être partionnées
– Un noeud qui tombe peut être facilement remplacé
– No single point of failure
• Facile à distribuer
• Pas de schema
• Peut grossir ou diminuer facilement
• Il faut relacher l’exigence de données consistente (CAP)
 Qu’est ce que l’on abandonne
• joins
• group by
• order by
• ACID transactions
• SQL as a sometimes frustrating but still
powerful query language
• easy integration with other applications
that support SQL
 Cassandra
• Originally developed at Facebook
• Follows the BigTable data model: column-
oriented
• Uses the Dynamo Eventual Consistency model
• Written in Java
• Open-sourced and exists within the Apache
family
• Uses Apache Thrift as it’s API
 Thrift
• Created at Facebook along with
Cassandra
• Is a cross-language, service-generation
framework
• Binary Protocol (like Google Protocol
Buffers)
• Compiles to: C++, Java, PHP, Ruby,
Erlang, Perl, ...
 Searching
• Relational
– SELECT `column` FROM `database`,`table`
WHERE `id` = key;
– SELECT product_name FROM rockets WHERE
id = 123;
• Cassandra (standard)
– keyspace.getSlice(key, “column_family”,
"column")
– keyspace.getSlice(123, new ColumnParent(“rockets”),
getSlicePredicate());
 API NoSQL typique
• API pour accéder aux données :
– get(key) -- Extract the value given a key
– put(key, value) -- Create or update the value
given its key
– delete(key) -- Remove the key and its associated
value
– execute(key, operation, parameters) -- Invoke an
operation to the value (given its key) which is a
special data structure (e.g. List, Set, Map .... etc).
 Quelques Statistiques
• Recherche Facebook
• MySQL > 50 GB Data
– Writes Average : ~300 ms
– Reads Average : ~350 ms
• Réécrit avec Cassandra > 50 GB Data
– Writes Average : 0.12 ms
– Reads Average : 15 ms
 N’oubliez pas le rôle du DBA
• Tjrs nécessaire
• Tjrs nécessaire de gérer
– Backups & recovery
– Capacity planning
– Performance monitoring
– Data integration
– Tuning & optimization
 Quand utiliser une base de
données NoSQL?
• Pour la plupart d’entres vous, bosser à LinkedIn ou Twitter n’est pas
dans nos projets
• Pourquoi j’utiliserez une base NoSQL?
• Avez vous des données volumineuse, non controlée, non structuré,
que vous essayer de faire rentrer dans une base de données
relationnelle:
– Log Analysis
– Social Networking Feeds (many firms hooked in through
Facebook or Twitter)
– External feeds from partners (EAI)
– Data that is not easily analyzed in a RDBMS such as time-based
data
– Large data feeds that need to be massaged before entry into an
RDBMS
 Résumé
• Les principaux utilisateurs des bases de
données NoSQL datastores sont les sites de
réseaux sociaux comme Twitter, Facebook,
LinkedIn, et Digg
• Pour implémenter une fonctionnlité dans
Cassandra, Digg a un ensemble de données
de 3 terabytes et 76 billion columns
• “Not every problem is a nail and not every
solution is a hammer”