Cet article a fait l'objet d'une traduction automatique.

Le programmeur au travail

Base de données NoSQL Cassandra, 3e partie : Clusters

Ted Neward

La dernière fois, j'ai examiné Apache Cassandra, le "open source, distribuée, décentralisée, élastiquement évolutive, hautement disponible, fault-tolerant tuneably cohérente, base de données orientée colonne qui fonde sa conception de la distribution sur Amazon Dynamo et son modèle de données sur Google Bigtable," tel que décrit dans le livre, "Cassandra : Le Guide définitif » (o ' Reilly Media, 2010). Pour être plus précis, ayant installé Cassandra (dans la première partie de cette série), j'ai regardé comment au programme pour elle de Microsoft .NET Framework, faisant les bits de base de la lecture et l'écriture des données qui lui. Rien de spectaculaire.

En fait, partie de Cassandra « spectaculaire » est enveloppé dans sa capacité inhérente à se regrouper, donnant Cassandra facile scale-out. Cela signifie qu'il peut augmenter des tailles « ridicules », le plus souvent avec peu ou aucune tâche d'administration — particulièrement l'on compare le travail requis par la plupart des bases de données relationnelles pour stocker des tailles équivalentes. À titre d'exemple, une entreprise de technologie local ici à Redmond, Wash. (où j'habite), réclamé à une récente rencontre de démarrage qu'il était de stocker plus de 50PB de données de Cassandra.

Même en tenant compte d'exagération et l'hyperbole, seulement un dixième de cela (5PB, ou plus de 5, 000TB) est un morceau assez salée de données. Pour être juste, le site Web de Cassandra (cassandra.apache.org) déclare, « le plus grand connu Cassandra cluster possède plus de 300 téraoctets de données dans plus de 400 machines,"qui est encore assez difficile à faire avec une configuration relationnelle out-of-the-box.

Mais la clé à tous que le stockage se trouve dans le cluster, et tandis que faire un groupe de cette taille mis en place en production est probablement au-delà de la portée de cet article, nous pouvons au moins commencer à jouer avec elle en obtenant un cluster à plusieurs nœuds exécutant des travaux de développement. Il nécessite quelques étapes, donc je vais marcher à travers elle une étape à la fois. (Par ailleurs, DataStax a une installation facile pour Cassandra, mais comme près que je peux dire il manque la possibilité de mettre en place un cluster de nœuds multiples dans une boîte ; C'est au sujet de son seul inconvénient que je vois à ce jour).

Installer Recap

Dans le premier article de cette série (msdn.microsoft.com/magazine/jj553519), je suis passé par la douleur (parfois angoissante) de la mise en place de Cassandra depuis le fichier .zip et la ligne de commande : Assurer un environnement d'exécution Java est installé et sur le chemin d'accès ; Assurez-vous qu'une variable d'environnement JAVA_HOME est configurée ; décompressez la distribution Cassandra dans un répertoire ; et puis lancer le fichier « cassandra.bat » du répertoire « bin » pour obtenir le serveur opérationnel.

À l'époque, il pouvait sembler anachronique vraiment de le faire, mais deux choses positives viennent de faire l'installation de cette façon. Tout d'abord, vous obtenez une certaine expérience dans l'installation d'un serveur, écrit en Java (et qui s'avère pour être une compétence très utile d'avoir, compte tenu de combien les différentes implémentations de NoSQL sont écrits en Java). Deuxièmement, vous aurez besoin de « tromper » que l'installation à un niveau assez bas pour obtenir Cassandra exécuter à plusieurs reprises sur une seule boîte.

Vous voyez, la notion de Cassandra d'évolutivité vient d'un « anneau » de serveurs : plusieurs instances du service Cassandra s'exécutant sur plusieurs compartiments, chacun d'eux stockant une partie de l'ensemble de données total. Puis, lorsque les nouvelles données sont enregistrées sur le ring, Cassandra « commérages » (c'est le terme technique réels pour elle) entre les différents nœuds dans le ring pour mettre les données au bon endroit dans l'anneau. Dans un anneau bien administré, Cassandra équilibrera uniformément les données entre les nœuds. Cassandra a un certain nombre de stratégies différentes à l'écriture des données entre les nœuds, et il est toujours possible d'écrire une nouvelle stratégie personnalisée (en supposant que vous êtes à l'aise écriture Java), mais pour maintenant, je vais rester avec les valeurs par défaut pour garder les choses plus faciles.

Un anneau pour les gouverner tous...

Normalement, la meilleure façon de mettre en place un cluster Cassandra est d'avoir plusieurs machines et évidemment une façon de faire qui consiste à configurer plusieurs instances de machine virtuelle exécutant tous simultanément sur un seul ordinateur portable. Mais que peuvent obtenir trop compliqué et ampli jusqu'à la configuration matérielle requise assez rapidement, surtout si vous êtes un de ces développeurs qui fait tout au large un ordinateur portable (comme moi).

Ainsi, la deuxième façon d'obtenir plusieurs nœuds doit avoir Cassandra exécuté plusieurs fois sur la même boîte, stockage des données dans de multiples endroits et écoute sur des ports différents socket. Cela signifie plonger dans les fichiers de configuration de Cassandra à mettre en place des configurations différentes configuration deux (ou plus) et le lancement de chacun.

En supposant une installation Cassandra 1.1 (la dernière version en date de cette écriture), Cassandra stocke toutes ses informations de configuration dans le répertoire /conf. Dans ce répertoire, il ya deux fichiers en particulier que j'ai besoin d'éditer : log4j-server.properties et cassandra.yaml. J'ai aussi besoin de savoir où des nœuds données et les journaux vont aller, donc je vais aller de l'avant et il suffit de créer deux sous-répertoires sous le Cassandra répertoire d'installation. En supposant que vous avez installé Cassandra à C:\Prg\apache-cassandra-1.1.0 (comme moi), puis à créer deux nouveaux répertoires situé juste au-dessous, un pour chaque nœud que vous allez créer : C:\Prg\apache-cassandra-1.1.0\node1 et \node2.

Au sein de ces deux répertoires, copiez le contenu du répertoire /conf Cassandra, qui apportera au cours de ces deux fichiers dont vous avez besoin. Vous souhaitez également copier le fichier cassandra.bat dans/bin, parce que c'est où le troisième et dernier changement devra arriver, afin de dire où elle a besoin pour exécuter les fichiers de configuration seront à Cassandra.

Ce n'est pas fun stuff Java ?

Le premier fichier, log4j-server.properties, un fichier de configuration pour le projet open source de journalisation log4j. (Java utilise les fichiers « .properties » comme Windows utilise des fichiers « .ini » retour dans la journée). Votre intérêt principal ici est de s'assurer que chaque nœud Cassandra écrit un fichier journal de diagnostic à un endroit différent que les autres nœuds. Personnellement, je veux toutes les données pour chaque nœud à l'intérieur de ces répertoires \node1 et \node2, je tiens donc à trouver la ligne à l'intérieur de log4j-server.properties qui se lit comme suit :

log4j.appender.R.file=/var/log/cassandra/System.log

Alors je veux le changer pour quelque chose de plus Windows-ish et plus \node1-ish, comme ceci :

log4j.appender.R.file=C:/PRG/Apache-cassandra-1.1.0/Node1/log/System.log

Le répertoire des journaux ne doit pas exister avant le début de Cassandra — elle vais créer si elle n'est pas là. Par ailleurs, assurez-vous que les barres obliques sont des barres obliques ici juste me faire confiance sur celui-ci ; ça va marcher. (Java reconnaît leur si elles sont vers l'avant ou des barres obliques vers l'arrière, mais la syntaxe du fichier de propriétés utilise des barres obliques vers l'arrière comme caractères d'échappement séquence, un peu comme leur fonctionnement dans les chaînes de langage c#).

En second lieu, il faut le crack ouvrir le fichier « cassandra.yaml » pour que la prochaine série de modifications. La syntaxe « .yaml » est « Encore un autre langage de balisage, » et — oui, vous l'aurez deviné, c'est une autre syntaxe de configuration .ini-style. Java standardisé jamais sur ce point, n'est pas rare de voir plusieurs styles de configuration différente tous les deux ensemble dans un projet unique (comme Cassandra).

Plus précisément, vous devez modifier quelques paramètres ici ; ceux-ci sont dispersés dans tout le fichier (qui, soit dit en passant, est parsemé avec des tonnes de commentaires, alors qu'ils sont vraiment un peu explicites si vous lisez à travers tout cela) :

cluster_name: 'Test Cluster'
data_file_directories:
  - /var/lib/cassandra/data
commitlog_directory: /var/lib/cassandra/commitlog
saved_caches_directory: /var/lib/cassandra/saved_caches
listen_address: localhost
rpc_address: localhost

Le « nom_cluster » est facultative, mais elle n'est pas une mauvaise chose pour changer de toute façon, peut-être à quelque chose comme "Mon_cluster" ou "Big Fun Cluster O." Le reste des paramètres, cependant, doivent être modifiées. Les entrées « répertoires » doivent pointer vers les répertoires \node1 et \node2, respectivement.

Un anneau pour les trouver tous les...

Les deux derniers paramètres doivent être modifiés pour des raisons différentes. Cassandra, rappelez-vous, instinctivement veut courir comme un seul service par machine, alors qu'elle part du principe que c'est OK pour simplement lier un socket TCP/IP à « localhost ». Mais si vous avez deux ou plus de services qui s'exécutent sur la même boîte, cela ne va pas au travail. Vous devez donc lui dire de lié aux adresses qui résoudront efficacement à la même boîte, même s'ils peuvent être des valeurs différentes. Heureusement, vous pouvez faire ceci en mettant expressément 127.0.0.1 pour node1, 127.0.0.2 pour node2 et ainsi de suite.

(Vous demandez peut-être pourquoi cela fonctionne ; la réponse est au-delà de la portée de cet article, mais toute bonne référence TCP/IP doit être capable de l'expliquer. Si vous n'êtes pas convaincu, essayez « ping 127.0.0.1 » et « ping 127.0.0.2 » sur votre boîte. Tous deux doivent résoudre très bien. Si vous n'aimez pas spécifier ces valeurs, vous pouvez toujours affecter les noms dans votre fichier "hosts" dans le répertoire C:\Windows\System32\drivers\etc.)

Une partie de la raison que Cassandra a besoin de cette configuration réseau a fonctionné est parce qu'elle va « découvrir » l'anneau de la première connexion à un nœud de « semences », qui dira ensuite cette instance sur les autres nœuds dans le ring. Tout cela fait partie du protocole potins qu'elle utilise pour transmettre des informations importantes autour de l'anneau. Si nous avons été mise en place l'anneau de courir à travers les différentes machines, Cassandra aurait besoin de la configuration de « graines » configuration pour pointer vers un nœud en cours d'exécution, mais dans ce cas — parce que nous sommes tous s'exécutant sur la même boîte, la valeur par défaut 127.0.0.1 fonctionne très bien.

Après toutes les modifications, le fichier cassandra.yaml dans \node1 devrait ressembler à ceci :

cluster_name: 'Test Cluster'
data_file_directories:
  - C:/Prg/apache-cassandra-1.1.0/node1/data
commitlog_directory: C:/Prg/apache-cassandra-1.1.0/node1/commitlog
saved_caches_directory: C:/Prg/apache-cassandra-1.1.0/node1/saved_caches
listen_address: localhost
rpc_address: localhost
For \node2, the file should look like this:
cluster_name: 'Test Cluster'
data_file_directories:
  - C:/Prg/apache-cassandra-1.1.0/node2/data
commitlog_directory: C:/Prg/apache-cassandra-1.1.0/node2/commitlog
saved_caches_directory: C:/Prg/apache-cassandra-1.1.0/node2/saved_caches
listen_address: 127.0.0.2
rpc_address: 127.0.0.2

Enfin, Cassandra a besoin d'être dit quand elle commence vers le haut, où trouver la configuration files, et normalement elle fait ceci en regardant le long de l'instruction CLASSPATH Java (qui ressemble vaguement au mécanisme de résolution d'assembly du .NET Framework, mais d'une demi-décennie plus primitive, pour être franc). Elle souhaite également exposer certains gestion et le suivi des informations de JMX (Java équivalent à l'analyseur de performances ou Windows Management Instrumentation) sur un port TCP/IP, et les deux services ne peut pas utiliser le même port. Ainsi, les modifications finales doivent être à cassandra.bat :

REM s'assurer que toutes les variables définies par l'utilisateur CLASSPATH ne servent pas au démarrage

Set CLASSPATH="%CASSANDRA_HOME%\node1"

Et pour les cassandra.bat en \node2 :

REM s'assurer que toutes les variables définies par l'utilisateur CLASSPATH ne servent pas au démarrage

Set CLASSPATH="%CASSANDRA_HOME%\node2"

Ainsi que la ligne suivante dans \node2 :

-Dcom.sun.management.jmxremote.port=7299^

Dans l'original, le port va lire « 7199. »

Comme je l'ai dit, ne s'agit-il pas fun stuff Java ?

… Et dans les ténèbres les lier

Mais une fois que toutes les commandes de configuration obtient de la route, le plaisir commence. Feu vers le haut une fenêtre d'invite de commandes (avec des variables d'environnement JAVA_HOME et CASSANDRA_HOME pointant vers la racine du JDK et Cassandra répertoires d'installation, n'oubliez pas) et passez dans le répertoire \node1 vous avez été tromper sur. Off « cassandra -f » à l'invite et regarder le défilement de l'information sur le diagnostic par le feu. Il s'agit de la première instance, et en supposant que tous les paramètres de configuration sont bonnes (aucune faute de frappe), vous devriez voir le texte défiler et finissent avec « Écoute clients thrift... »

Maintenant, dans une deuxième fenêtre d'invite de commandes, placez-vous sur \node2 et faire la même chose. Cette fois, comme il tire vers le haut, vous verrez également certaines activités se produisent en quelques minutes dans la fenêtre \node1 — ce qui se passe là-bas, c'est qu'après que l'instance de \node2 se lève et en cours d'exécution, il se connecte à l'instance de \node1 (la "graine"), et les deux essentiellement configurer mutuellement pour commencer à travailler ensemble dans un anneau. En particulier, recherchez les deux lignes "JOINING : en attente de l'anneau et le schéma d'informations"et"noeud /127.0.0.1 fait maintenant partie du cluster"à apparaissent dans la fenêtre de \node2 et « nœud /127.0.0.2 fait maintenant partie du cluster » et"InetAddress /127.0.0.2 est maintenant vers le haut"dans la fenêtre de \node1.

Mais, si vous avez manqué de voir ces messages, Cassandra a une autre surprise vous attend. Dans une troisième fenêtre d'invite de commandes, accédez à – l'original Cassandra \bin répertoire et lancez "nodetool anneau h 127.0.0.1" et vous devriez voir quelque chose comme Figure 1.

Figure 1 deux Instances de Cassandra, chaque propriétaire de 50 pour cent des données

C'est vraiment excitant de trucs, parce que comme vous pouvez le voir sur la colonne possède, les deux instances de Cassandra ont déjà compris que chacun d'entre eux fassent propre 50 pour cent des données, sans aucune configuration supplémentaire de votre part. Sweet !

La meilleure partie est, si vous exécutez le code dans l'article précédent, les données seront réparties sur l'ensemble du cluster sans modification supplémentaire.

C'est un complément, pas un remplacement

Comme certains de l'autre base de données outils cette colonne a exploré (MongoDB et SQLite), Cassandra ne devrait pas être considérée comme un remplacement massif pour une base de données relationnelle, mais comme une technologie complémentaire qui peut être utilisé soit pour les zones où la fonctionnalité définie d'une base de données relationnelle simplement inadaptée bien (mise en cache ou le stockage d'ensembles de données hautement structurées viennent à l'esprit, par exemple), ou comme un système hybride, en conjonction avec une base de données relationnelle. Par exemple, une entreprise peut stocker un « fixe » ensemble d'éléments de données dans une base de données relationnelle et comprennent, comme l'une des colonnes relationnelles, une touche de Cassandra, afin de récupérer les données restantes, non structurées. La base de données relationnelle peut ensuite rester structurées et relationnelles (obéissant à la plupart ou toutes les règles de forme normale), mais le système global auront toujours la possibilité de stocker des éléments de données imprévues supplémentaires que les utilisateurs semblent toujours à ajouter au système comme il âges.

Voici un autre exemple, considérez Webseite frappé des données, qui pourraient toujours être assorties hors de la page elle-même, mais pourraient de suivre facilement dans des millions ou des milliards d'éléments de données. Un service de raccourcissement d'URL (comme bit.ly) serait trivial à faire ici, parce que le chemin d'accès URL réduite (la partie "foobar" dans http://bit.ly/foobar) serait la clé et a frappé ses stats données — ainsi qu'une description facultative et peut-être même un instantané périodique de l'URL redirigée — serait faite pour Cassandra. Et ainsi de suite.

Cassandra ne va pas prendre en charge le centre de données n'importe quand bientôt, ni devrait il. Mais lorsqu'il est utilisé intelligemment, c'est un nouvel outil dans la boîte à outils, et les développeurs serait insensés de l'ignorer. Il y a beaucoup plus à découvrir à propos de Cassandre, mais il est temps de laisser la prophétesse de Troie aller et passer à d'autres choses.

bon codage !

Ted Neward est consultant en architecture chez Neudesic LLC. Auteur de plus de 100 articles, il a rédigé ou corédigé plus d'une dizaine d'ouvrages, y compris « Professional F# 2.0 » (Wrox, 2010). Il est un éminent expert Java MVP F # et prononce des conférences fois Java et .NET dans le monde entier. Il consulte et mentors régulièrement — le joindre à ted@tedneward.com ou Ted.Neward@neudesic.com si vous désirez lui de venir travailler avec votre équipe. Il blogs à blogs.tedneward.com et peut être suivi sur Twitter à twitter.com/tedneward.

Merci à l'expert technique suivant d'avoir relu cet article : Kelly Sommers