Affichage des articles dont le libellé est NoSQL. Afficher tous les articles
Affichage des articles dont le libellé est NoSQL. Afficher tous les articles

lundi 1 novembre 2010

Cassandra - Diagnostiquer et réparer des problèmes : nodetool

Un outil très important est nodetool sur Cassandra. Nous allons voir quelques utilisations de nodetool dans la suite.
Cette première entrée sera dédiée à obtenir des informations sur vos serveurs cassandra.

Avant de commencer 

 
Il faut commencer par trouver le port jmx qu'utilise Cassandra, qui est stocké dans bin/cassandra.in.sh, la ligne :
-Dcom.sun.management.jmxremonte.port=XXXX (XXXX sera très probablement 8081)

Pour lancer nodetool (nous utiliserons un serveur Cassandra qui tourne en local) :
$ bin/nodetool --host localhost --port XXXX [vote commande]

Premières opérations

Dorénavant nous utiliserons le port 8081

1. Commande Ring

On peut d'abord voir les informations sur le "ring" cassandra que l'on a créé. Le ring est l'ensemble de vos serveurs connecté partageant un Keyspace :



Pour se faire on lance la commande :
$bin/nodetool --host localhost --port 8081 ring

Exemple :

On peut voir sur l'exemple ci-dessous qu'e l'on a qu'un seul serveur dans le ring (à l'adresse 127.0.0.1 ). Vous pourrez trouver d'autres exemples sur internet avec plus de serveurs pour voir à quoi cela ressemble.

Address       Status     Load          Range                                      Ring
127.0.0.1     Up         181.87 KB     28629777447930928502858236796283324409     |<--|

2. Commande cfstats

Cette commande vous donne des informations sur les ColumnFamily dans votre Keyspace. C'est particulièrement intéressant de voir les données qui en ressortent. Vous pourrez ainsi diagnostiquer s'il y a des problèmes ainsi qu'un grand nombre d'autres informations.

$ bin/nodetool --host localhost --port 8081 ring

Example :

                Column Family: Last10KPosts
                SSTable count: 2
                Space used (live): 14801
                Space used (total): 14801
                Memtable Columns Count: 3
                Memtable Data Size: 132
                Memtable Switch Count: 1
                Read Count: 1664
                Read Latency: 0.391 ms.
                Write Count: 6
                Write Latency: 0.022 ms.
                Pending Tasks: 0
                Key cache capacity: 256
                Key cache size: 18
                Key cache hit rate: 0.9740420271940667
                Row cache: disabled
                Compacted row minimum size: 0
                Compacted row maximum size: 0
                Compacted row mean size: 0


3. Commande tpstats

La commande cfstats est particulièrement intéressante lorsque votre serveur Cassandra est très sollicité. de nombreuses informations utiles sont affichées par cette commande et c'est une des commandes les plus importantes lorsque vous administrez une base de données Cassandra.
Il est important que vous ayez le moins possible de tâche pending ainsi qu'active, sinon cela veut dire que vous devez changer votre configuration !

$ bin/nodetool --host localhost --port 8081 tpstats

Example :

Pool Name                  Active   Pending   Completed
STREAM-STAGE                0         0          0
RESPONSE-STAGE              0         0        7196
ROW-READ-STAGE              0         0        7196
LB-OPERATIONS               0         0          0
MESSAGE-DESERIALIZER-POOL   0         0          0
GMFD                        0         0          0
LB-TARGET                   0         0          0
CONSISTENCY-MANAGER         0         0          0
ROW-MUTATION-STAGE          0         0        524
MESSAGE-STREAMING-POOL      0         0          0
LOAD-BALANCER-STAGE         0         0          0
FLUSH-SORTER-POOL           0         0          0
MEMTABLE-POST-FLUSHER       0         0         28
FLUSH-WRITER-POOL           0         0         28
AE-SERVICE-STAGE            0         0          0


4. Commande info

La commande info vous permet d'avoir une vue rapide sur votre base de données. Vous verrez la taille de votre base de données, l'uptime.

$ bin/nodetool --host localhost --port 8081 info

Example :

28629777447930928502858236796283324409
Load             : 185.29 KB
Generation No    : 1288687184
Uptime (seconds) : 32868
Heap Memory (MB) : 180.26 / 1020.81



A bientôt pour mon prochain billet,
N'hésitez pas à faire passer ce blog si les informations que vous y trouvez vous semblent utiles, c'est une grande motivation de voir les visites augmenter sur ce site. Merci à tous !

mardi 4 mai 2010

Les alternatives à Cassandra

Maintenant que nous avons un peu vu ce qu'est Cassandra, j'aimerais parler des alternatives qui existent.
Cet article est en partie une traduction de l'excellent article :

Il ne faut pas croire qu'il existe actuellement une ou deux bases NoSQL qui se battent en duel, c'est un mouvement qui est bien enclenché maintenant et qui possède une excellente dynamique dynamique.

Voici une liste non exhaustive des bases qui existent, classées suivant leurs caractéristiques. J'ai mis en gras celles qui semblaient à mon goût être utilisable de façon stable et qui sont activement développées.

Excellente consistance des données (bonne réplications dans les nodes) :

Les bases ci-dessous assurent que les données ne seront pas perdues et donc que les modifications, inclusions des données se feront de façon sûre à travers les nodes. Cependant le principal désavantage de ces bases est que l'on doit faire constamment attention car il faut attendre que les modifications soient répercutées dans l'ensemble des noeuds.
  • BigTable : Table de Google
  • HyperBase : Base de données performante
  • HBase : Cette base de données est performante pour les accès très fréquents et courts. Elle peut en particulier dépasser (et de loin si on en croit les tests effectués par rapport à Cassandra 0.5.1, cf le rapport de yahoo déjà posté sur ce blog).
  • MongoDB
  • Terrastore : Base de données utile pour la gestion de base de données très importantes.
  • Redis
  • Scalaris
  • MemcacheDB
  • Berkeley DB

Consistance moyenne des données, mais disponibilité excellente :

Cette catégorie correspond aux bases de données qui sont plus tolérantes à des données non intégralement répliquées. La plupart de ces dernières ont une variable "consistency" qui indiquent à quel point les données sont correctement répliquées au travers des noeuds (nodes). L'avantage est que l'accès, l'écriture et la lecture peuvent se faire à n'importe quel moment.
  • Dynamo
  • Voldemort
  • Tokyo Cabinet 
  • KAI
  • Cassandra : Peut être la plus couramment utilisée parmis toutes les bases de données du monde NoSQL. Utilisée en version modifiée dans Twitter, Digg, Reddit.
  • CouchDB
  • SimpleDB
  • Riak : Toute jeune base, cf l'article sur linuxfr.org


Enfin pour finir, une petite image issue du même blog qu'en haut, voici un petit graphique qui résume bien les capacités de chacune des bases ainsi que leurs caractéristiques :