63 votes

Quelle est La Meilleure Pratique Dans la Conception d'Un Cassandra Modèle de Données?

Et quels sont les écueils à éviter? Il n'existe aucun deal des pauses pour vous? E. g., J'ai entendu dire que l'exportation/importation de la Cassandra de données est très difficile, me faisant me demande si ça va entraver la synchronisation des données de production à l'environnement de développement.

BTW, c'est très dur de trouver de bons tutoriels sur Cassandra, le seul que j'ai http://arin.me/code/wtf-is-a-supercolumn-cassandra-data-model est encore assez basique.

Merci.

41voto

MarkR Points 37178

Pour moi, le principal, c'est une décision d'utiliser le OrderedPartitioner ou RandomPartitioner.

Si vous utilisez le RandomPartitioner, analyse de la plage ne sont pas possibles. Cela signifie que vous devez connaître la clé exacte pour toute activité, y COMPRIS le NETTOYAGE des DONNÉES ANCIENNES.

Donc, si vous avez beaucoup de désabonnement, sauf si vous avez un peu de magie moyen de savoir exactement quelles touches vous avez inséré des trucs, à l'aide de l'aléatoire outil de partitionnement, vous pouvez facilement de "perdre" des choses, ce qui provoque l'espace disque de fuite et finira par consommer tous les éléments de stockage.

D'autre part, vous pouvez demander à l'ordonnée de partitionnement de "ce que font les touches que j'ai dans la Colonne de la Famille X entre A et B" ? - et il va vous le dire. Vous pouvez ensuite nettoyer.

Cependant, il ya un inconvénient. Cassandra n'est pas de faire de l'équilibrage de charge automatique, si vous utilisez la commande de partitionnement, en toute probabilité, toutes vos données à la fin dans un ou deux nœuds, et aucun dans les autres, ce qui signifie que vous aurez un gaspillage de ressources.

Je n'ai pas de réponse facile pour cela, sauf que vous pouvez obtenir le "meilleur des deux mondes", dans certains cas, en mettant un court valeur de hachage (de quelque chose que vous pouvez énumérer facilement à partir d'autres sources de données) sur le début de vos clés - par exemple, un 16-bit hex de hachage de l'ID de l'utilisateur qui va vous donner 4 chiffres hexadécimaux, suivie par ce que la clé est que vous avez vraiment envie de l'utiliser.

Alors si vous aviez une liste de récemment supprimé les utilisateurs, il vous suffit de hachage leur Id et leur gamme de balayage pour nettoyer tout liées à eux.

Le prochain problème est secondaire index - Cassandra n'a pas tout - donc, si vous avez besoin de regarder de X par Y, vous devez insérer les données dans les deux touches, ou avoir un pointeur. De même, ces pointeurs peuvent avoir besoin d'être nettoyé lorsque la chose qu'ils désignent n'existe pas, mais il n'y a pas de moyen facile d'interroger les trucs sur cette base, de sorte que votre application doit Juste se Rappeler.

Et l'application des bugs peuvent laisser des orphelins clés que vous avez oublié, et vous n'aurez aucun moyen de détecter facilement, à moins que vous écrivez du garbage collector qui analyse périodiquement chaque clé dans la base de données (cela va prendre un certain temps - mais vous pouvez le faire en morceaux) à vérifier pour ceux qui ne sont pas nécessaire, pas plus.

Rien de tout cela est basé sur l'utilisation réelle, ce que j'ai compris au cours de la recherche. Nous n'utilisons pas de Cassandra dans la production.

EDIT: Cassandra maintenant ne ont des index secondaires dans le coffre.

17voto

jbellis Points 16235

C'était trop long pour ajouter un commentaire, afin d'éclaircir certaines idées fausses à partir de la liste de problèmes de réponse:

  1. Le client peut se connecter à n'importe quel nœud; si le premier nœud à vous de choisir (ou de vous connecter via un équilibreur de charge) va vers le bas, il suffit de se connecter à un autre. En outre, un "fat client" de l'api est disponible à l'endroit où le client peut ordonner à l'écrit elle-même; un exemple est sur http://wiki.apache.org/cassandra/ClientExamples

  2. Calendrier quand un serveur ne répond pas, plutôt que d'accrocher indéfiniment est une caractéristique que la plupart des personnes qui ont traité avec surchargé systèmes sgbdr a souhaité. Cassandra délai d'attente RPC est configurable; si vous le souhaitez, vous êtes libre de le régler pour plusieurs jours et de les traiter avec accrocher indéfiniment au lieu. :)

  3. Il est vrai qu'il n'est pas multidelete ou de troncature encore de support, mais il y a des patchs pour les deux de ces en cours d'examen.

  4. Il est évidemment nécessaire de trouver un compromis en gardant d'équilibrer la charge sur les nœuds de cluster: le plus parfaitement équilibré vous essayez de garder les choses, plus de mouvement de données que vous allez faire, ce qui n'est pas libre. Par défaut, les nouveaux nœuds dans un cluster Cassandra se déplace vers la position optimale dans l'anneau à jeton pour minimiser inégale-ness. Dans la pratique, cela a été prouvé à travailler très bien, et la plus grande de votre cluster est, moins il est vrai que le doublage est optimal. Ce point est abordé plus en http://wiki.apache.org/cassandra/Operations

7voto

Alice Points 71

7voto

Igor Katkov Points 1124

Il n'existe aucun deal des pauses pour vous? Pas nécessairement deal breakers, mais quelque chose d'être conscient de

  1. Un client se connecte à un nœud le plus proche dont l'adresse qu'il doit savoir au préalable, toutes les communications avec tous les autres Cassandra nœuds mandatées par elle. un. trafic en lecture/écriture n'est pas répartie également entre les nœuds: des nœuds de proxy plus de données qu'ils hébergent eux-mêmes b. Si le nœud, le client est impuissant, ne peut pas lire, ne peut pas écrire n'importe où dans le cluster.

  2. Bien que Cassandra affirme que "l'écrit ne manquent jamais" ils ne, au moins, au moment de parler, il n'. Si la cible nœud de données devenu lent, demande du temps et de l'écriture échoue. Il y a beaucoup de raison pour qu'un nœud ne répond plus: le garbage collector de coups de pied dans, processus de compactage, quoi que... Dans tous ces cas, toute écriture/lecture échec de la demande. Dans un classique de la base de données de ces demandes seraient devenus proportionnellement lente, mais de Cassandra, ils ont échouer.

  3. Il est multi-get, mais il n'y a pas de multi-supprimer et on ne peut pas tronquer ColumnFamily soit

  4. Si un nouveau, vide nœud de données entrez le cluster, la portion de données d'un voisin nœuds sur le porte-clés sera transféré. Cela conduit à l'inégale distribution des données et de charge inégale. Vous pouvez résoudre le problème en doublant le nombre de nœuds.Il convient également de garder une trace sur les jetons manuellement et sélectionnez-les à bon escient.

5voto

Je pense que cela mérite une mise à jour depuis Cassandra 1.2 est sorti récemment.

J'ai été à l'aide de Cassandra en production depuis plus de 18 mois pour les jeux de société.

Mon bien c'est que vous devez utiliser à Cassandra de ses forces. Ainsi, une bonne compréhension de ce que et comment il le fait, il est nécessaire de consulter les données le modèle à utiliser, ou même pour identifier si une autre base de données de la solution est le plus utile pour vous.

OrderedPartitioner est utile uniquement si votre application s'appuient sur une plage de requêtes, MAIS vous donner sur l'une des fonctionnalités les plus puissantes de Cassandra: le partage automatique et l'équilibrage de la charge. Au lieu de la touche de ligne gamme requêtes essayer de mettre en œuvre les mêmes fonctionnalités dont vous avez besoin à l'aide de gammes de noms de colonnes dans la même ligne. TL;DR en lecture/écriture ne SERA PAS équilibré entre les nœuds à l'aide de ce.

RandomPartioner (hachage md5) et MurmurPartitioner (Murmure de hachage, mieux et plus vite) sont la façon dont VOUS DEVEZ aller si vous voulez soutenir le big data et d'un accès haut fréquences. La seule chose que vous donnez sur est la clé de la gamme des requêtes. Tout ce qui est dans la même ligne est toujours sur le même nœud dans le cluster et vous pouvez utiliser le comparateur et le nom de colonne de la gamme des requêtes sur ceux-ci. TL;DR : à UTILISER pour un BON ÉQUILIBRE, vous donnera rien de majeur.


Choses que vous devez savoir à propos de cassandre:

Cassandra est FINALEMENT cohérent. Cassandra a choisi de commerce de Cohérence pour une haute Disponibilité et une excellente Partitionnement (http://en.wikipedia.org/wiki/CAP_theorem). MAIS vous pouvez obtenir la consistance de cassandra, il est tout au sujet de vous la Cohérence de la politique lorsque vous lire et à écrire. C'est tout à fait important et un sujet complexe lorsque l'on parle de l'utilisation de cassandra, mais vous pouvez lire à ce sujet dans le détail ici http://www.datastax.com/docs/1.2/dml/data_consistency.

En règle générale (et pour faire simple) je lire et d'écrire au COLLÈGE ConsistencyLevel (puisque dans mes applications lit ont tendance à être du même ordre de fréquence, comme l'écrit). Si votre application est extrêmement écriture lourde et lit beaucoup moins souvent, puis écrire à UN et de le lire à TOUS. Ou si votre cas est l'inverse (les écritures sont beaucoup moins fréquentes que dans le lit), alors vous pouvez essayer de lire sur l'UN et à écrire sur TOUS les. L'utilisation de TOUT comme un niveau de consistance pour l'écrit n'est pas une bonne idée si la cohérence est ce que vous essayez de résoudre, car il garantit que la mutation a atteint le cluster, mais pas qu'il a été écrit nulle part. C'est le seul cas dans lequel je l'ai écrit en silence échouer sur cassandra.

Ce sont des règles simples pour le rendre facile pour commencer avec cassandra développement. Pour obtenir un maximum de cohérence et de performance que possible à partir d'un cluster de production, vous devriez étudier ce sujet dur et vraiment comprendre vous-même.

Si vous avez besoin d'un lisible par l'homme datamodel avec un système complexe de relations entre les Entités (tables) alors je ne pense pas que Cassandra est fait pour vous. MySQL et peut-être NewSQL pourraient être plus utiles pour votre cas d'utilisation.

Une bonne chose à savoir, c'est comment, à peu près, cassandra enregistre et lit les données. Chaque fois que vous écrivez (suppressions sont écrit en fait d'un "tombstone" valeur cassandra) le système va mettre la nouvelle valeur et son timbre de temps dans un nouvel emplacement physique.

Quand vous lisez, cassandra, essaie de tirer toutes les écritures pour une certaine touche/column_name emplacement et vous renvoie le plus récent qu'il a pu trouver (celui avec la plus haute timestamp, qui a été fourni par le client). Donc, la mémoire nécessaire à un nœud est directement dépendante des fréquences de l'écrit. Il y a un processus de compactage de cassandra, qui se charge de nettoyer vieux mutations. Cassandra a un cache interne qui est mis à jour sur le lit avec la dernière valeur de l'emplacement.

La fusion/compactage sur le disque de la SSTables (les structures de données que de persister les données) peut être provoqué par des lectures, mais c'est mieux de ne pas compter sur elle. Le nettoyage de pierres tombales et de l'expiration des colonnes (à l'aide de la durée de vie de la fonctionnalité) est un autre mécanisme géré par le garbage collector (voir la GC grâce réglage de l'heure pour plus de détails).


Ce qui m'amène au dernier point que je veux faire: assurez-vous que votre écrit et de la lecture sera équilibré dans l'ensemble de votre cluster!

Supposons que tous vos utilisateurs ont besoin de mise à jour d'un seul emplacement très fréquemment.
NE PAS la carte que théorique emplacement unique à une seule touche de ligne! Ce serait tout de vos écritures de l'automne sur un seul nœud d'un cluster. Si ce n'est pas tout amener vers le bas (parce que vous avez rockstar sysops), il sera au moins fortement paralyser le cluster de la performance.
Mon conseil est de seau de vos écritures en assez différents rangée de touches que vous allez distribuer votre écrit sur tous les nœuds du cluster. Pour récupérer toutes les données pour que seul théorique de l'utilisation de la localisation d'un multi_get sur tous les "sous rangée de touches".

Exemple :
Je veux avoir une liste de toutes les sessions http actives (qui ont uuid affecté). Ne pas enregistrer tous dans une "session" touche de ligne. Ce que j'utilise comme une touche de ligne pour mon cluster cassandra de 6 nœuds est : _sessions. Alors j'ai un petit 16 touches multi_get pour récupérer toutes les sessions actives, ou je peux encore dire si une session est active par juste en utilisant un simple get (si je sais que son uuid, bien sûr). Si votre cluster est beaucoup plus grand que vous pourriez vouloir utiliser une fonction de hachage pour la génération seau clés.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X