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.