2

Je me tape la tête dessus, mais, franchement, mon cerveau ne l'obtiendra pas - à ce qu'il semble.Utilisation de la clé de cluster Cassandra

J'ai une famille de colonnes qui détient des emplois pour un groupe d'acteurs plutôt important. Il s'agit d'une table centrale de gestion et d'ordonnancement des tâches qui doit être distribuée et disponible dans l'ensemble du cluster et peut même éventuellement traverser les barrières du centre de données dans un proche avenir. Chaque système d'acteur exécuteur de travaux, ceux qui exécutent réellement les travaux, est installé à côté d'un nœud Cassandra, c'est-à-dire sur le même nœud. En fait, il ya bien sûr un acteur principal qui tire les emplois et les distribue aux agents des acteurs, mais cela n'a rien à voir avec ma question.

Certains systèmes d'acteur peuvent créer des tâches dans la table de tâches centrale pour être exécutées par d'autres acteurs ou même des systèmes d'acteur, mais généralement les tâches sont chargées par lots ou manuellement via une interface Web.

Un acteur qui doit exécuter un travail interroge toujours son nœud local de cassandra. Si c'est fini, le tableau des travaux sera mis à jour pour indiquer qu'il est terminé. Cette écriture devrait, dans des circonstances normales, également seulement mettre à jour des enregistrements avec des travaux, pour lesquels son noeud Cassandra local fait autorité.

Maintenant, il peut parfois arriver qu'un système d'acteur sur un hôte donné n'ait rien à faire. Dans ce cas, il devrait en effet obtenir des jobs d'autres nœuds, mais bien sûr, il ne parlera que de son nœud local de Cassandra. Je sais que cela fonctionne et ça ne me dérange pas un peu.

Ce qui me garder la nuit est la suivante:

Comment puis-je créer une clé composée pour réaliser l'autorité locale d'un noeud Cassandra pour les entrées d'emploi pour son système d'acteur local et, par conséquent, il est des acteurs d'exécution du travail, sans se fendre la table de travail dans plusieurs familles de colonnes ou similaire? En d'autres termes: comment créer une clé composée garantissant que a) les tâches sont réparties uniformément dans mon cluster et b) une requête locale dans la table de travail renvoie uniquement les tâches pour lesquelles ce nœud Cassandra fait autorité et c) mon système d'agent distribué a toujours la possibilité d'aller chercher des travaux d'autres nœuds, au cas où il n'aurait pas de tâches à exécuter ???

Un dernier mot sur c) ci-dessus. Je ne veux pas faire 2 requêtes dans le cas où il n'y a pas de travail local, mais seulement sur!

Des indices à ce sujet?

Cette structure générale est de la table de travail jusqu'à présent:

ClusterKey UUID: Primary Key 
JobScope String: HOST/GLOBAL/SERVICE/CHANNEL 
JobIdentifier String: Web-Crawler, Twitter 
Description String: 
URL String: 
JobType String: FETCH/CLEAN/PARSE/
Job String: Definition of the job 
AdditionalData Collection: 
JobStatus  String: NEW/WORKING/FINISHED 
User String: 
ValidFrom Timestamp: 
ValidUntill Collection: 

Toujours dans le tout processus d'établissement des, donc aucune requête jusqu'à présent défini. Mais un acteur va en retirer des tâches et en définir le statut, donc

+0

Pouvez-vous modifier votre question avec votre schéma (CREATE) table' et instructions de requête? Cela rendra beaucoup plus facile de voir ce que vous essayez de faire. – Aaron

Répondre

2

Cassandra n'a aucun moyen de "bloquer" une clé sur un nœud, si c'est ce que vous recherchez. Si j'étais vous, je cesserais de m'inquiéter de savoir si mon nœud local faisait autorité pour un ensemble de données, et commencerais à tirer parti des contrôles de cohérence intégrés dans Cassandra pour gérer l'ensemble des nœuds que vous lisez ou écrivez à.

Beaucoup d'informations ici sur la cohérence de lecture et d'écriture consistency- en utilisant la bonne consistance fera en sorte que votre application évolue tout en gardant bien logiquement correct: http://www.datastax.com/documentation/cassandra/2.0/cassandra/dml/dml_config_consistency_c.html

Un autre point à noter est atomique « comparer et échange », aussi connu sous le nom de transactions légères. Disons que vous voulez vous assurer qu'un travail donné n'est effectué qu'une seule fois. Vous pouvez ajouter un champ indiquant si le travail a été "ramassé", puis interroger ce champ (where picked_up = 0) et simultanément (et de manière atomique) mettre à jour le champ pour indiquer que vous "ramassez" ce travail. De cette façon, aucun autre acteur ne le ramassera.

Informations sur les transactions légères ici: http://www.datastax.com/documentation/cassandra/2.0/cassandra/dml/dml_ltwt_transaction_c.html