La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

Cassandra Un moteur in-memory d’écriture. Plan  Caractéristiques principales  Ring  LSM-Tree  Modèle de données  Insertion massive des données 

Présentations similaires


Présentation au sujet: "Cassandra Un moteur in-memory d’écriture. Plan  Caractéristiques principales  Ring  LSM-Tree  Modèle de données  Insertion massive des données "— Transcription de la présentation:

1 Cassandra Un moteur in-memory d’écriture

2 Plan  Caractéristiques principales  Ring  LSM-Tree  Modèle de données  Insertion massive des données  Interrogation des données  Nouveau paradigme: in-memory

3  Un cluster Cassandra est appelé ring: il fonctionne en mode peer-to- peer, chaque nœud du ring pouvant traiter toute demande d’un client ( absence de relation maître-esclave )  Un nœud du ring appelé par un client en tant que coordinateur est capable de lire ou d’écrire des données d’une table ( ou famille de colonnes ) réparties sur plusieurs noeuds ( architecture de type shared-nothing )  Chaque table a ses données répliquées n fois sur les nœuds du cluster.  Cassandra optimise l’écriture des données via une table en mémoire appelée Memtable.  Les écritures disques se font de manière asynchrone dans une Sstable ( Sorted String Table ) Lexique

4 Caractéristiques  Solution libre de la fondation Apache développée initialement par Facebook  Distribution Datastax ( Community + Enterprise )  Ecrit en Java  SGBD orienté colonne => clé-valeur ( valeur = ensemble de colonnes )  Système distribué en mode peer-to-peer

5 Caractéristiques  Cassandra 2.0  CQL, système d’interrogation de la base, surcouche sql => client cqlsh à privilégier au détriment de cassandra-cli orienté colonne  Liste des drivers clients: Java, C#, Python  Pas de locking en cas de mises à jour concurrentes => si plusieurs clients modifient les mêmes colonnes de manière concurrente, seule les modifications les plus récentes seront conservées.

6 Une table Cassandra

7 Caractéristiques  Atomicité assurée au niveau de la ligne pour une transaction => insertion et modification de colonnes pour une ligne traitées comme une seule opération  Isolation assurée au niveau d’une ligne  Durabilité assurée via un journal de commit log  Read & Write consistency

8 Ring Cassandra  Système peer-to-peer où chaque nœud est capable de traiter une demande d’un client ( pas de relation maître/esclave ).  Les données des tables sont distribuées de manière hashée et compressée sur chaque nœud dans des partitions.  Chaque partition est répliquée sur des nœuds différents.

9 Ring: écriture

10 Ring: lecture

11 LSM-tree

12  Structure optimisée pour l’écriture des données, plus performante qu’une table SQL munie d’index sur de grands volumes ( GB, TB ).  Idée principale: écrire en mémoire dans une table de type clé-valeur, puis écrire sur disque de manière asynchrone et séquentielle  Une écriture sur disque est immuable => algorithme de merge-sort pour fusionner les mêmes tables SST LSM-tree

13 Ecriture dans une table

14 Lecture dans une table

15  Ensemble de tables indépendantes les unes des autres ( pas de jointure en nosql )  Un seul index, la clé de partition  Clusterisation possible des tables: clé composite  Ajout possible d’index secondaires  Tip: a good rule of a thumb is one column family per query since you optimize column families for read performance Modèle de données

16  Types usuels: int, double, varchar, boolean, timestamp, blob  Collections : set, list, map  Autres types : counter, inet, uuid, timeuuid Type des données

17 Cluster de test  Cluster à 3 nœuds  I ( 4 CPU )  32 GB RAM  4 TB HDD ( 7200 RPM )  Carte réseau à 100 Mb/s  Ubuntu LTS  Commodity hardware

18  Pré-requis:  Sudo  JRE Oracle 7  Accès internet => apt-get  Installation rapide ( < 1 jour si ports ouverts )  Documentation: doc/getting_started/gettingStartedDeb_t.html doc/getting_started/gettingStartedDeb_t.html Installation

19  Méthode 1 : commande Copy ( cql )  Import de fichiers csv  Exemple: copy T from ‘/home/user/file’ with delimiter = ‘|’  Méthode 2: outil sstableloader  Générer une SS table à partir d’un fichier csv via un programme Java à créer  Utiliser l’outil pour charger la SS table créée dans Cassandra  Pas d’outil pour insérer des données semi-structurées => Création d’un outil en java Insertion massive de données

20  SsTableLoad  Il se connecte à un nœud du ring, lance n itérations sur une table au format prédéfini.  Pour chaque itération, il exécute un bulk-insert de m lignes.  La première ligne insérée a comme clé min_key, puis on incrémente de 1 pour chaque nouvelle insertion. SsTableLoad

21  CREATE TABLE test_insert (  string varchar,  nb bigint,  bool boolean,  list list,  map map,  val blob,  PRIMARY KEY (nb));  alter table test_insert with gc_grace_seconds = 30;  Insertion d’un BLOB de 1 MB SsTableLoad

22  Exceptions java rencontrées durant la phase de développement:  Exception in thread "main" com.datastax.driver.core.exceptions.NoHostAvailableException: All host(s) tried for query failed (tried: / (com.datastax.driver.core.exceptions.DriverException: Timeout during read), / (com.datastax.driver.core.TransportException: [/ ] Error writing), / (com.datastax.driver.core.exceptions.DriverException: Timeout during read))  Dans le fichier /etc/cassandra/cassandra.yaml:  read_request_timeout_in_ms: 5000 => 1 minute  write_request_timeout_in_ms: 2000 => 24 secondes Exceptions Java

23  Exception in thread "main" com.datastax.driver.core.exceptions.InvalidQueryExc eption: Request is too big: length exceeds maximum allowed length => nb_insert = 250  java.lang.OutOfMemoryError: Java heap space => changer la taille de la heap size dans le fichier /etc/cassandra/cassandra-env.sh : 8 GB => 12 GB Exceptions Java

24 Scalabilité  Un processus charge 64 GB en 14m25s, soit 1 GB en 14s.  Deux processus chargent 64 GB en 8m47s, soit 1 GB en 8s.  Saturation si lancement de 3 processus, un par noeud

25 Activité réseau

26  Objectif: comprendre le fonctionnement interne de quelques requêtes => tracing on sous cqlsh  Liste des requêtes étudiées ( CRUD ) :  Insert  Update  Select  Count(*)  Scan full, utilisation d’index secondaire, order by  Delete Etude des requêtes

27 Description des tables  CREATE TABLE test_insert_x (  nb bigint,  bool boolean,  "list" list,  "map" map,  string text,  val blob,  PRIMARY KEY (nb)  ) WITH  bloom_filter_fp_chance= AND  caching='ALL' AND  comment='' AND  dclocal_read_repair_chance= AND  gc_grace_seconds=30 AND  index_interval=128 AND  read_repair_chance= AND  replicate_on_write='true' AND  populate_io_cache_on_flush='false' AND  default_time_to_live=0 AND  speculative_retry='99.0PERCENTILE' AND  memtable_flush_period_in_ms=0 AND  compaction={'class': 'SizeTieredCompactionStrategy'} AND  compression={'sstable_compression': 'LZ4Compressor'};  CREATE TABLE test_select_x (  nb bigint,  string text,  bool boolean,  "list" list,  "map" map,  val blob,  PRIMARY KEY (nb, string)  ) WITH  bloom_filter_fp_chance= AND  caching='KEYS_ONLY' AND  comment='' AND  dclocal_read_repair_chance= AND  gc_grace_seconds=30 AND  index_interval=128 AND  read_repair_chance= AND  replicate_on_write='true' AND  populate_io_cache_on_flush='false' AND  default_time_to_live=0 AND  speculative_retry='99.0PERCENTILE' AND  memtable_flush_period_in_ms=0 AND  compaction={'class': 'SizeTieredCompactionStrategy'} AND  compression={'sstable_compression': 'LZ4Compressor'};

28 Insert  insert into test_insert_1 (nb,bool,list,map,string)values (12001, true, ['azerty', 'qwerty'], { ' :00' : 't1'}, '12000');

29 Count(*)  select count(*) from test_insert_1 limit 20000;

30 Utilisation de l’index de la clé primaire select nb, list, string from test_insert_1 where nb = 1535 ;

31 Utilisation d’un index secondaire CREATE INDEX test_insert_1_string_idx ON test_insert_1 (string); select nb, list, string from test_insert_1 where string = 'VvmEQQwkPEtypCrmBRrKUbhpXXxtfe';

32 Order by select nb,string, bool,list,map from test_select_1 where nb = 1221 order by string

33 Update update test_select_1 set bool = true where nb = 1221 and string = 'LfazkllbGORcyHSwmiZgLVWcmbaWHL' ;

34 Delete delete from test_select_1 where nb = 840;

35  Grammaire du select très limitée, peu d’index, accès disque en lecture => comment mieux exploiter cette immense quantité de données collectée ?  Une solution: version Enterprise de Datastax  Partie batch ( map-reduce, hive, apache mahout )  Moteur de recherche full-text: solr ( = elasticsearch )  Ajout d’une couche in-memory Interrogation des données

36 In-memory  Changement de paradigme: disque & RAM => RAM & cache processeur  Solution 1: coupler Cassandra à un moteur in-memory ( Spark, Shark, MLlib, … )  Solution 2: coupler Cassandra à une base in-memory en mode colonne ( Hana de SAP, Vertica de HP, Amazon RedShift, … ) => cible: BI


Télécharger ppt "Cassandra Un moteur in-memory d’écriture. Plan  Caractéristiques principales  Ring  LSM-Tree  Modèle de données  Insertion massive des données "

Présentations similaires


Annonces Google