Cloud Computing Les bases de données NoSQL Année académique 2014/15

Cloud Computing Les bases de données NoSQL Année académique 2014/15 Bases de données Aperçu historique Préhistoire : Bases de données hiérarchiques ou orientées réseau 1980 Montée des bases de données relationnelles 1990 Bases de données orientées-objet Dominance des bases de données relationnelles 2000 2010 Apparition des bases de données NoSQL 2

Bases de données SQL Rappel : Avantages des bases de données SQL Stockage de données persistant La base de données stocke un grand nombre de données sur disque. Les applications prennent les morceaux dont elles ont besoin à travers des requêtes. Intégration d'applications Souvent les applications ont besoin de partager de l'information. En les faisant utiliser la même base de données, nous assurons que les applications ont des données cohérentes et mises à jour. Plutôt standardisé Gestion des accès concurrents Plusieurs utilisateurs accèdent simultanément à la même information. La gestion des accès concurrents est difficile à programmer, c'est pourquoi les bases de données offrent des transactions pour aider à assurer une interaction cohérente. Reporting Le modèle de données SQL est simple et la standardisation a fait de lui la base d'un grand nombre d'outils de reporting. Le modèle relationnel est largement utilisé et compris. L'interaction avec la base de données se fait à travers SQL, un langage standardisé (principalement). 3 (C) 2012 Bases de données SQL Rappel : Modélisation relationnelle Exemple de données et schéma Customer Id Name 1 Anne Order Id CustomerID 99 1 Shipping AddressId 77 Customer name 1 * 1 Order 1 1 2 Bob 3 Claire 100 3 101 1 78 79 1 Product Id Name 27 Garden chair 28 Cushion 29 Umbrella BillingAddress Id CustomerID AddressId 55 1 77 56 2 78 57 3 79 * Billing Address * 1 * * Order Payment cardnumber transactionid * Order Item price * OrderItem Address 1 Id OrderID ProductId Price Id City 1 Product 210 99 27 211 99 29 49.90 12.80 77 78 London Nice Address name 212 100 27 Id OrderID 49.90 OrderPayment CardNumber 383 99 1000-1000 Billing AddressId 55 79 Milano TransactionId 45fjhs63h8 street city state post code 1 shipping Address 384 100 2000-2000 385 101 3000-3000 56 57 934fjh34835 7hbj53sk845 4

Bases de données SQL Problèmes des bases de données SQL Désadaptation d'impédance 6 Chapter 1 Why NoSQL? ID: 1001 orders customer: Ann line items: 0321293533 2 $48 $96 customers 0321601912 1 $39 $39 0131495054 1 $51 $51 order lines payment details: Card: Amex CC Number: 12345 expiry: 04/2001 credit cards Figure 1.1 An order, which looks like a single aggregate structure in the UI, is split into many rows from many tables in a relational database 5 ptg9987953 a lot of grunt work, but can become a problem of their own when people try too hard to ignore the database and query performance suffers. Relational databases continued to dominate the enterprise computing world in the 2000s, but during that decade cracks began to open in their dominance. HEIG-VD 1.3 Application TIC Technologies de l Information and et de Integration la Communication Databases The exact reasons why relational databases triumphed over OO databases are Bases still the subject de données of an occasional orientées-objet pub debate for developers of a certain age. But L'échec in our view, des bases the primary de données factor orientées-objet was the role of SQL as an integration mechanism between applications. In this scenario, the database acts as an integration database with Inventées au milieu multiple des années applications, 1990, usually les developed by separate teams, storing bases their de données data in a orientées-objet common database. promettaient This improves communication because all de the résoudre applications le problème are operating de la désadaptation a consistent set of persistent data. d'impédance. There are downsides to shared database integration. A structure Facturation that s designed to Mais integrate contrairement many applications à ce que ends l'on attendait, up being more complex indeed, often dramatically elles ne connurent more complex than pas beaucoup any single de succès. application needs. Furthermore, should an application want to make changes to its data storage, it needs to coordinate with Les bases all the de other données applications SQL restèrent using the database. Different applications have dominantes. different structural and performance needs, so an index required by one Raison majeure : leur utilisation comme bases de données d'intégration entre applications différentes Base de données d'intégration From Inventaire the Library of Marcel Graf 6

ACM Transactions on Computer Systems, Vol. 26, No. 2, Article 4,Pub.date:June2008. Bases de données SQL Aujourd'hui la dominance de SQL est en train de craquer Les bases de données relationnelles sont conçues pour tourner sur une seule machine. Pour étendre la capacité de la base de données on doit acheter une machine plus puissante. Il est moins cher et on peut étendre la capacité de stockage davantage en achetant beaucoup de machines : un cluster 7 Individuellement les machines ne sont pas fiables, mais le cluster continue de fonctionner si une machine meurt le cluster en total est fiable. Mais les bases de données relationnelles ne sont pas adaptés à des clusters. (C) 2012 Une nouvelle approche pour les bases de données 4 Google et Amazon furent les premiers à utiliser des grands clusters, et évitèrent les bases de données relationnelles Google : Bigtable Amazon : Dynamo Leurs efforts ont été une grande inspiration pour la communauté NoSQL Bigtable: A Distributed Storage System for Structured Data FAY CHANG, JEFFREY DEAN, SANJAY GHEMAWAT, WILSON C. HSIEH, DEBORAH A. WALLACH, MIKE BURROWS, TUSHAR CHANDRA, ANDREW FIKES, and ROBERT E. GRUBER Google, Inc. Bigtable is a distributed storage system for managing structured data that is designed to scale to a very large size: petabytes of data across thousands of commodity servers. Many projects at Google store data in Bigtable, including web indexing, Google Earth, and Google Finance. These applications place very different demands on Bigtable, both intermsofdatasize(fromurlsto web pages to satellite imagery) and latency requirements (from backend bulk processing to realtime data serving). Despite these varied demands, Bigtable has successfully provided a flexible, high-performance solution for all of these Google products. Inthisarticle,wedescribethesimple data model provided by Bigtable, which gives clients dynamiccontroloverdatalayoutandformat, and we describe the design and implementation of Bigtable. Categories and Subject Descriptors: C.2.4 [Computer Communication Networks]: Distributed Systems distributed databases General Terms: Design Additional Key Words and Phrases: Large-Scale Distributed Storage ACM Reference Format: Chang, F., Dean, J., Ghemawat, S., Hsieh, W. C., Wallach, D. A., Burrows, M., Chandra, T., Fikes, A., and Gruber, R. E. 2008. Bigtable: A distributed storage system for structured data. ACM Trans. Comput. Syst. 26, 2, Article 4 (June 2008), 26 pages. DOI = 10.1145/1365815.1365816. http://doi.acm.org/10.1145/1365815.1365816. This article was originally published as an award paper in the Proceedings of the 7 th Symposium on Operating Systems Design and Implementation [Chang et al. 2006]. It is being republished here with minor modifications and clarifications. Authors address: Google Inc., 1600 Amphitheatre Parkway, Mountain View, CA 94043; email: {fay, jeff, sanjay, wilsonh, kerr, m3b, tushar, fikes, gruber}@google.com. Permission to make digital or hard copies of part or all of this workforpersonalorclassroom use is granted without fee provided that copies are not made or distributedforprofitordirect commercial advantage and that copies show this notice on the first page or initial screen of a display along with the full citation. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credits is permitted. To copy otherwise, to republish, to post on servers, to redistribute to lists, or to use any component of this work in other works requires prior specific permission and/or a fee. Permissions may be requested from the Publications Dept., ACM, Inc., 2 Penn Plaza, Suite 701, New York, NY 10121-0701 USA, fax +1 (212) 869-0481, or permission@acm.org. c 2008 ACM 0734-2071/2008/06-ART4 $5.00 DOI: 10.1145/1365815.1365816. http://doi.acm.org/ 10.1145/1365815.1365816. Dynamo: Amazon s Highly Available Key-value Store Giuseppe DeCandia, Deniz Hastorun, Madan Jampani, Gunavardhan Kakulapati, Avinash Lakshman, Alex Pilchin, Swaminathan Sivasubramanian, Peter Vosshall and Werner Vogels Amazon.com One of the lessons our organization has learned from operating ABSTRACT Amazon s platform is that the reliability and scalability of a Reliability at massive scale is one of the biggest challenges we system is dependent on how its application state is managed. face at Amazon.com, one of the largest e-commerce operations in Amazon uses a highly decentralized, loosely coupled, service the world; even the slightest outage has significant financial oriented architecture consisting of hundreds of services. In this consequences and impacts customer trust. The Amazon.com environment there is a particular need for storage technologies platform, which provides services for many web sites worldwide, that are always available. For example, customers should be able is implemented on top of an infrastructure of tens of thousands of to view and add items to their shopping cart even if disks are servers and network components located in many datacenters failing, network routes are flapping, or data centers are being around the world. At this scale, small and large components fail destroyed by tornados. Therefore, the service responsible for continuously and the way persistent state is managed in the face managing shopping carts requires that it can always write to and of these failures drives the reliability and scalability of the read from its data store, and that its data needs to be available software systems. across multiple data centers. This paper presents the design and implementation of Dynamo, a Dealing with failures in an infrastructure comprised of millions of highly available key-value storage system that some of Amazon s components is our standard mode of operation; there are always a core services use to provide an always-on experience. To small but significant number of server and network components achieve this level of availability, Dynamo sacrifices consistency that are failing at any given time. As such Amazon s software under certain failure scenarios. It makes extensive use of object systems need to be constructed in a manner that treats failure versioning and application-assisted conflict resolution in a manner handling as the normal case without impacting availability or that provides a novel interface for developers to use. performance. Categories and Subject Descriptors To meet the reliability and scaling needs, Amazon has developed D.4.2 [Operating Systems]: Storage Management; D.4.5 a number of storage technologies, of which the Amazon Simple [Operating Systems]: Reliability; D.4.2 [Operating Systems]: Storage Service (also available outside of Amazon and known as Performance; Amazon S3), is probably the best known. This paper presents the design and implementation of Dynamo, another highly available General Terms and scalable distributed data store built for Amazon s platform. Algorithms, Management, Measurement, Performance, Design, Dynamo is used to manage the state of services that have very Reliability. high reliability requirements and need tight control over the tradeoffs between availability, consistency, cost-effectiveness and 1. INTRODUCTION performance. Amazon s platform has a very diverse set of Amazon runs a world-wide e-commerce platform that serves tens applications with different storage requirements. A select set of of millions customers at peak times using tens of thousands of applications requires a storage technology that is flexible enough servers located in many data centers around the world. There are to let application designers configure their data store appropriately strict operational requirements on Amazon s platform in terms of based on these tradeoffs to achieve high availability and performance, reliability and efficiency, and to support continuous guaranteed performance in the most cost effective manner. growth the platform needs to be highly scalable. Reliability is one of the most important requirements because even the slightest There are many services on Amazon s platform that only need outage has significant financial consequences and impacts primary-key access to a data store. For many services, such as customer trust. In addition, to support continuous growth, the those that provide best seller lists, shopping carts, customer platform needs to be highly scalable. preferences, session management, sales rank, and product catalog, the common pattern of using a relational database would lead to inefficiencies and limit scale and availability. Dynamo provides a simple primary-key only interface to meet the requirements of these applications. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are Dynamo uses a synthesis of well known techniques to achieve not made or distributed for profit or commercial advantage and that scalability and availability: Data is partitioned and replicated copies bear this notice and the full citation on the first page. To copy using consistent hashing [10], and consistency is facilitated by otherwise, or republish, to post on servers or to redistribute to lists, object versioning [12]. The consistency among replicas during requires prior specific permission and/or a fee. updates is maintained by a quorum-like technique and a SOSP 07, October 14 17, 2007, Stevenson, Washington, USA. Copyright 2007 ACM 978-1-59593-591-5/07/0010...$5.00. decentralized replica synchronization protocol. Dynamo employs 195 205 8

Définition Il n'y a pas de définition précise du terme NoSQL Utilisé la première fois en 2009 pour nommer un workshop de développeurs de nouvelles bases de données. Mais il y a un nombre de caractéristiques communes aux bases de données NoSQL Elles sont issues des sites web du 21ème siècle. Elles n'utilisent pas le modèle de données relationnel, et n'utilisent donc pas le langage SQL. Elles sont conçues pour tourner sur un cluster. Elles sont souvent Open Source. Elles n'ont pas un schéma fixe, ce qui permet de stocker n'importe quel type de données dans un enregistrement. 9 Pourquoi les bases de données relationnelles vont continuer à exister Il y a des bonnes raisons pour la survie des bases de données relationnelles : Le modèle relationnel est toujours pertinent S'adapte à beaucoup de types de données, spécialement quand il faut décortiquer les données et les reconstituer de manière différente pour des usages différents. Transactions ACID Pour pouvoir tourner sur un cluster, la majorité des bases de données NoSQL ont des capacités transactionnelles limitées. C'est souvent suffisant... mas pas toujours. Outils La longue dominance de SQL signifie que grand nombre d'outils ont été créés pour fonctionner avec des BD relationnelles. Familiarité Les systèmes NoSQL sont encore nouveaux, et les développeurs ne les connaissent pas encore bien. 10 (C) 2012

Modèle de données Document Famille de colonnes Graphe Clé-valeur 11 Modèle de données clé-valeur La base de données permet de stocker des objets quelconques (un nombre, une image, un document,...) et de les retrouver grâce à une clé C'est le principe d'un hashmap, mais stocké de manière persistante sur un disque. 837094 071943 812792 12

Modèle de données orienté document La base de données permet de stocker des documents, où chaque document est une structure de données complexe. Structure hiérarchique (comme un document XML) Structure souvent représentée en JSON Le développeur peut faire des requêtes dans la structure de données pour en extraire des parties ou mettre à jour des parties {""id":"1001, """customer_id":"7231, """line8items":"[ """"{""product_id":"4555,""quantity":"8"}, """"{""product_id":"7655,""quantity":"4"}, ""], """discount8code":"y } {""id":"1002, """customer_id":"9831, """line8items":"[ """"{""product_id":"4555,""quantity":"3"}, """"{""product_id":"2155,""quantity":"4"}, """"{""product_id":"6384,""quantity":"1"}, ""], } 13 Modèle de données famille de colonnes Clé colonne Valeur colonne Clé ligne (row key) Une clé unique par ligne. Famille de colonnes name "Martin" Une ligne contient plusieurs familles de colonnes. Accessibles par le biais de la clé. Famille de colonnes (column family)... Clé ligne profile billingaddress payment données... données... Une combination de colonnes qui vont ensemble. Porte un nom. 071943 OR1001 données... Contient plusieurs paires clé colonne / valeur colonne. Clé colonne / valeur colonne (column key / column value)... orders OR1002 OR1003 données... données... Paire clé-valeur qui contient les données. OR1004 données... 14

Modèle de données orienté graphe Structure d'un graphe composé de sommets et arcs. Peut être orienté ou non. Très avantageux pour suivre des relations entre objets. Les bases de données relationnelles ne sont pas très bonnes pour cela. Il faut faire des joins qui peuvent devenir très complexes. Le terme "relationnel" vient de la théorie des ensembles. Langage d'interrogation adapté à la structure de graphe. est ami(e) avec est ami(e) avec est la fille de Yann est marié avec est ami(e) avec Marie Anne 15 Modèle de données orienté graphe Langage d'interrogation Exemple : Langage Cypher de Neo4j BigCo employee of employee of Anna Carol friend of friend of Barbara friend of Elizabeth START%barbara%=%node:nodeIndex(name%=%"Barbara") MATCH%(barbara)9[:FRIEND]9>(friend_node) RETURN%friend_node.name,friend_node.location 16

Comment les utiliser? Exemple d'une plateforme e-commerce Traditionnellement elle utilise une base de données relationnelle pour tout ses besoins de stockage. Les bases de données NoSQL offrent un nombre de modèles de données différents. La plateforme e-commerce peut utiliser pour chaque composante la base de données la mieux adaptée à ses besoins. Plateforme e-commerce Plateforme e-commerce Données session Business intelligence Data warehouse Données session Caddie électronique Graphe social clients Caddie électronique Commandes Commandes Inventaire Prix Base de données relationnelle BD clé-valeur BD documents BD relationnelle BD graphe 17 (C) 2012 Utilisations recommandées Modèle clé-valeur Stockage d'information de session web Profils et préférences d'utilisateurs Données du caddie électronique Modèle orienté document Logging d'événements Gestion électronique des documents, plateformes de blog Collecte de données pour analytique web Applications e-commerce : données de produits et de commandes Modèle famille de colonnes Logging d'événements Gestion électronique des documents, plateformes de blog Compteurs Modèle orienté graphe Réseaux sociaux Applications de routage et expédition basées sur la géolocalisation Moteurs de recommandations 18 (C) 2012

Principes de distribution Sharding et réplication Sharding : L'espace de stockage est subdivisé en plusieurs zones. Chaque zone est affectée à une machine. Réplication : Pour un objet on crée plusieurs copies. Chaque copie est stockée sur une machine différente. René Iris Louis René Iris Louis 19 Sharding : Découpage de la base de données Au lieu de traiter la base de données comme un éspace monolithique, les données sont découpées en zones (shards = éclats de verre) qui sont assignées à des machines. Supposons que les données soient du type clé-valeur, p.ex. des photos d'utilisateurs identifiés par leurs noms. <clé> <valeur> La question est comment découper l'espace des clés entre les machines pour équilibrer la charge. René au lieu d'un grand espace de stockage une multitude de machines <photo de > <photo de > Iris Louis élasticité : ajout de nouvelles machines...... René Iris Louis ou enlèvement de machines 20

Placement équilibré d'objets Les requêtes des utilisateurs pour stocker ou récupérer les objets sont reçues par des distributeurs. Ils déterminent les machines qui sont responsables du stockage des objets. Les distributeurs doivent prendre une décision très rapidement. Ils ne peuvent pas communiquer entre eux, cela prendrait trop de temps. stocker objet avec clé distributeur 1 distributeur 2 assigner l'objet à quelle machine? machines A B C D récupérer objet avec clé récupérer l'objet de quelle machine? 21 Placement équilibré d'objets Le hachage traditionnel Une table de hachage distribue les objets a stocker dans un tableau grâce à une fonction de hachage calculée sur la clé. Une bonne fonction de hachage distribue les objets plus ou moins uniformément pour minimiser les collisions. table de hachage avec 4 positions 0 1 2 3 position = hash(clé) mod 4 22

Placement équilibré d'objets Le hachage traditionnel Le même principe peut s'appliquer au placement des objets sur les machines. Seul problème : Quand on rajoute une machine, les positions de presque tous les objets changent. Cela causerait un trafic de migration inacceptable! hash( ) hash( ) hash( ) hash( ) position = hash(clé) mod 4 0 1 2 3 4... A B C D A B C D A B C D A B C D A B C A B C D E A B C D E A B C D E A B C D 23 Placement équilibré d'objets Le hachage cohérent Le hachage cohérent (consistent hashing) évite les déplacements des objets en cas d'addition ou d'enlèvement de machines. Les clés son mappées par la même fonction de hachage, mais la valeur de hachage est mappée dans un cercle. Les machines sont mappées de la même manière dans le cercle en utilisant leur nom comme clé. On établit la convention suivante : Un objet est assigné á la machine qui le suit dans le cercle (sens des aiguilles d'une montre). B A B C D hash( ) hash( ) A hash( ) D hash( ) hash( ) C hash( ) hash( ) hash( ) B 0 2 32 2 64 2 96 2 128 A D C 24

Placement équilibré d'objets Le hachage cohérent Situation initiale L'ajout d'une machine affecte seulement les objets entre la nouvelle machine et la machine qui la précède. L'enlèvement d'une machine affecte seulement les objets entre la machine enlevée et la machine qui la précède. A A A objets qui vont sortir de D B D B D B C E C E C objets qui vont entrer dans E 25 Cohérence en présence d'un conflit logique Problème Utilisateur A Navigateur Serveur d'application Base de données Utilisateur B GET GET Utilisateurs A et B accèdent aux mêmes données POST Utilisateur A modifie les données Conflit write-write POST Utilisateur B modifie les données 26

Cohérence en présence d'un conflit logique Problème Première solution Utilisateur A Navigateur Serveur d'application Base de données Utilisateur B GET POST GET POST Première solution : envelopper la lecture et l'écriture des données dans une transaction. La base de données va détecter le conflit, exécuter une des deux transactions avec succès et faire un rollback pour l'autre. Probléme : Maintenir une transaction aussi longtemps va dégrader la performance. 27 Cohérence en présence d'un conflit logique Problème Deuxième solution Utilisateur A Navigateur Serveur d'application Base de données Utilisateur B GET POST GET Deuxième solution : envelopper seulement l'écriture dans une transaction. Cela va assurer que l'écriture est faite complètement ou pas du tout (pas d'écriture moitié faite). Conflit write-write POST Mais ni la base de données ni l'application se vont rendre compte qu'il y a un conflit entre les utilisateurs. 28

Cohérence en présence d'un conflit logique Problème Deuxième solution Suite Utilisateur A Navigateur Serveur d'application Base de données Utilisateur B v. 101 GET v. 101 GET v. 101 Un mécanisme extérieur résout le problème : L'application ajoute un champ de version aux données. La version sera incrémentée par l'application chaque fois que les données sont modifiées. v. 101 POST v. 101? v. 102 v. 101? POST v. 101 La version est aussi retournée par le GET et passée avec le POST. Avant de modifier les données dans la base de données, l'application vérifie qu'elles sont bien à la bonne version. Ainsi l'application va détecter qu'il y a un problème avec l'écriture de l'utilisateur B. 29 Cohérence en présence de réplication La réplication des données en plusieurs copies introduit des nouveaux problèmes de cohérence. Tant que les replicas sont connectées, tout va bien. Quand elles sont déconnectées (network partition) il peut y avoir problème. Il y a différentes approches dans ce cas. Refuser la modification des données pour garantir la cohérence des replicas : bases de données relationnelles Permettre la modification des données et accepter une incohérence des replicas : bases de données NoSQL Réplicas connectées Réplicas déconnectées 30

Cohérence en présence de réplication Bases de données avec commit en deux étapes Connected Application Transaction monitor Replica A Replica B La base de données garantit un état cohérent des replicas. write x = 2 prepare x = 2 prepare OK x = 1 x = 1 prepare x = 2 prepare OK OK commit commit OK commit commit OK x = 2 x = 2 31 (C) 2012 Cohérence en présence de réplication Bases de données avec commit en deux étapes Partitioned (disconnected) Application write x = 2 Transaction monitor prepare x = 2 prepare OK Replica A Replica B x = 1 x = 1 La base de données fait un rollback (elle refuse de faire l'opération) et garantit un état cohérent des replicas. prepare x = 2 write error timeout cancel cancel OK partition 32 (C) 2012

Cohérence en présence de réplication Bases de données sans garanties de cohérence Connected write x = 2 OK Replica A Replica B x = 1 x = 1 x = 2 La base de données accepte l'opération pour une replica sans se soucier de l'état de l'autre réplica. Si les replicas sont connectées elles auront finalement un état cohérent sync x = 2 x = 2 33 (C) 2012 Cohérence en présence de réplication Bases de données sans garanties de cohérence Partitioned (disconnected) Application Application write x = 2 Replica A OK x = 2 Replica B x = 1 x = 1 Aussi longtemps que les replicas restent déconnectées elles auront un état incohérent. partition sync x = 2 34 (C) 2012

Réplication Modèles de distribution Avec la réplication des données on utilise généralement un de deux modèles Réplication master-slave Réplication peer-to-peer write write read Master replication read Peer replication Slave Peer Slave Peer Slave Peer 35 (C) 2012