Mon parcours • UTBM, 2 Google Summer Of Code • 1 stage de 6 mois chez Dailymotion • Mise en place d’une infrastructure de tests • 1 stage de 6 mois chez Novapost puis 9 mois • Automatisation de l’infrastructure
Mon parcours • 6 mois chez Tinyclues • Automatisation de l’infrastructure • Création d’outils en interne • Réflexion sur les processus internes et la culture d’entreprise
Limites du modèle SQL • Difficulté de modéliser certaines structures de données : • Graphes • Arbres • Enregistrements complexes (compte utilisateur) • Schéma coûteux à designer. • Architecture ancienne. • Difficultés de mise à l’échelle…
Scalabilité du modèle relationnel • Scalabilité verticale le plus souvent (== plus grosses machines). • Modèle de réplication master - slave quand disponible sur les solutions open-source. • Des plugins disponibles au-dessus des solutions, mais pas de solutions intégrées. • Difficulté de mise à l’échelle de la capacité d’écriture et la perte du master est souvent problématique.
ACID • Atomic – Une transaction s’applique complètement ou pas du tout. • Consistent – Une transaction ne peut rompre les contraintes d’intégrité de la base, qu’elle soit en succès ou non. • Isolated – Les résultats d’une transaction ne sont pas visibles tant que la transaction n’est pas terminée. • Durable – Le résultat des transactions en succès survivent à une panne ou à une transaction en échec.
Les promesses du NoSQL • Volume de données plus importants. • Meilleures performances. • Meilleure scalabilité horizontale. • Sacrifie la consistance (la valeur n’est pas toujours la dernière disponible). • Schema-less. • Plus dev-friendly.
« Inconvénients » • Le plus souvent pas de join à la SQL. • Pas de transactions inter-enregistrements. • Nouvelle manière de penser son schéma. • La dénormalisation est entrée dans les mœurs.
Recherche • Recherche classique, on envoie une recherche au serveur et on récupère les résultats. • Requête en JSON-like. • SQL-Like. • Langage dédie (Cypher). • Map / Reduce, méthode de traitement de masse des données. • Materialized Map / Reduce.
Clé / Valeur • La base de tout, toute base de données peut être implémentée au-dessus d’une base de données clé / valeur. • La valeur est arbitraire, soit un contenu binaire (string) soit un contenu plus structuré. • Très bonnes performances.
Memcached • Base de données orientée cache clé / valeur massivement distribuée. • Valeur simple. • Invalidation de cache par expiration ou par algorithme du moins récemment utilisé.
Requête >>> import memcache >>> mc = memcache.Client(['127.0.0.1:11211']) >>> mc.set("foo", "bar") >>> mc.get("foo") "bar" Deux types de requêtes principalement : • Set (avec une durée de validité). • Get
Requêtes • Set d’une valeur d’une colonne à un index donné. • Récupération d’une colonne ou de plusieurs colonnes entières. • Récupération d’une colonne ou plusieurs colonnes correspondant à une requête.
MongoDB • Base de données orientée document la plus connue et l’une des bases de données NoSQL la plus connue. • Possibilité d’indexation secondaires. • Moteur d’agrégation plus simple que Map / Reduce. • Support de recherches Full-Text
Requêtes • Enregistrement d’un document. • Récupération d’un document en particulier. • Recherche d’un document. • Agrégation des documents (count by, group by, sum…).
Graph database • Le modèle relationnel est un sous-ensemble du modèle orienté graphe. • Peu ou pas de besoin de design du schéma, le schéma s’enrichit avec les nouveaux liens. • Bonne performance pour les requêtes orientées graphes sur un grand nombre de nœuds.
Requêtes MATCH (charlie:Person { name:'Charlie Sheen' })-[:ACTED_IN]- (movie:Movie) RETURN movie • Requête complexe écrit dans un langage dédié (Cypher), par exemple, les films dans lesquels ‘Charlie Sheen’ a joué :
Requêtes • Enregistrement d’un document • Requête d’un document précis. • Recherche des documents correspondant à une recherche utilisateur (full-text).
Requête • Agrégation de données sur le temps : • Somme des visiteurs sur telle page de mon site sur le dernier mois. • Moyenne de la charge des serveurs agrégé par serveur sur la dernière semaine par période de 5 minutes.
Requêtes • Langage de requête structuré (JSON) ou non (Cypher), avancé (MongoDB) ou non (Redis). • Permet de scanner l’ensemble des éléments ou non même sans index. • Nécessite de préparer les requêtes à l’avance ou non.
Map / Reduce • Algorithme de traitement de large volumes de données crée par Google. • Recherche en deux étapes : • On extrait les données utiles ou on les calcule à partir des données brutes (Map). • Puis on les fusionne et on les trie (Reduce). • L’opération de Map est du coup facilement parallélisable, l’opération de Reduce un peu moins.
Replication • Sharding • On répartie les données entre plusieurs nœuds égaux. • Replication • On recopie les données entre plusieurs nœuds égaux. • Master-Slave • On recopie les données entre un maître et un slave, réplication uni-directionnelle.
Sécurité • Le plus souvent un modèle de sécurité basé sur celui de SQL est disponible. • Mais pas activé par défaut ou non disponible dans un soucis de simplicité (clé-valeur).
Choix d’une solution • Le choix d’une solution NoSQL est plus difficile que le choix d’une solution SQL. • Comment votre schéma va s’adapter. • Quelles sont vos contraintes métiers ? • Le temps développeur vous coûtera toujours plus cher.
Design du modèle de donnée • Modèle de donnée optimisé pour les requêtes. • CouchDB: préparer les requêtes, pas possible ou difficile d’en ajouter à postériori. • Au besoin, dupliquer la donnée et la démoraliser pour améliorer les requêtes.
Pourquoi NoSQL ? • Les bases de données NoSQL couvrent un périmètre bien plus large que les bases SQL, mais elles tentent de répondre aux mêmes besoins : • Plus vite • Plus de données • Plus de serveurs
Conclusion • Le modèle relationnel a des limites • Qui peuvent vous suffire, le NoSQL n’est pas une solution magique. • Dans le cas contraire, les bases NoSQL peuvent vous aider • Mais c’est un choix qui doit être bien réfléchi, RTFM !
lothiraldan
koic
10xinc
ogijun2018
usamik26
masahiro_nishimi
sasakendayo
coe401_
77web
dosukoi_android
hicka04
iwasiman
coconala_engineer
productmarketing
hannesfritz
chriscoyier
cassininazir
mthomps
ammeep
philhawksworth
colly
tmm1
aki_iinuma
eileencodes