Cassandra Schema

J'ai actuellement conçu un schéma dans Cassandra mais je me demande s'il y a une meilleure façon de faire les choses. Fondamentalement, le problème est que la plupart, sinon toutes les lectures sont dynamiques. J'ai construit un système de segmentation en tant que service d'application qui lit une requête personnalisée dynamique (complètement indépendante de Cassandra, mais la requête est stricte et limitée à l'application) et il va de l'avant et interroge cassandra et fusionne les résultats.Cassandra Schema

J'ai rendu la plupart des familles de colonnes aussi larges que je le pensais, et comme les données sont extrêmement intensives en écriture, j'ai utilisé des clés composites pour partitionner la charge. Cela consiste essentiellement à implémenter une couche de requête au-dessus de Cassandra qui est spécifique à l'application, y compris une sorte d'opération de jointure ou de fusion.

Y a-t-il des limites à cette mise en page ou processus?

Source

2013-07-03 Daniel

Je pense que vous devez être plus précis. Qu'entendez-vous par "lectures dynamiques"? Pourquoi segmenter puis fusionner? – Raedwald

@Raedwald Fondamentalement, la couche d'application expose un service de requête A. Sa tâche est de servir de segmentation de données. La segmentation est complètement indépendante de Cassandra (bien que les données y soient stockées). Au lieu de toucher Cassandra directement, nous exposons une couche d'indirection pour fournir une segmentation beaucoup plus puissante. Par exemple, quelqu'un pourrait demander l'ensemble de données «Trouver tous les utilisateurs d'où ils viennent du Canada et le navigateur est Firefox et ils ont cherché 5 fois sur la page d'accueil après s'être connecté». C'est le genre de segmentation de données dont je parle. – Daniel

La couche de service est responsable de cette segmentation. J'essaie d'obtenir des lignes extrêmement grandes (sur la colonne) pour permettre des lectures rapides, mais étant donné que certaines données sont des compteurs et que d'autres sont d'autres types, les données doivent être réparties automatiquement entre deux familles de colonnes. – Daniel

Si vous essayez de faire une sorte d'OLAP en utilisant Cassandra comme back-end, je pense que vous aurez des problèmes. Le conseil que j'ai vu sur la conception des tables Cassandra est de start with the queries you expect to run, puis de concevoir des tables dénormalisées qui rendent vos requêtes rapides. Vous devez donc savoir quelles sont les requêtes; il semble que ce n'est pas le cas pour votre application. Peut-être qu'un SGBDR serait-il meilleur?

Source

2013-07-03 10:54:50 Raedwald

RDBMS ne fonctionnerait pas car la base de données gère principalement les écritures. Je dirais que 90% est écrit et 10% sont lus, et le débit des écritures est assez élevé. Cassandra offre de très bonnes performances en écriture et aucune défaillance en un seul point, ce qui est essentiel. – Daniel

Une option est PlayOrm pour cassandra (un mappage nosql d'objet n'est pas relationnel car il suit de nombreux modèles nosql). Il a son propre langage S-SQL qui fait des jointures de partitions. Cependant, il ne va pas rejoindre votre table de milliard de lignes avec des milliards de lignes, mais si vos partitions sont dites inférieures à un million de lignes, cela peut vous aider.

nosql a de temps en temps des jointures côté client selon le contexte et PlayOrm le fait que vous n'avez pas à faire autant de travail quand vous avez besoin d'une jointure dans nosql qui peut être assez rare si ..... plusieurs fois la dénormalisation est meilleure.

Les patterns de playorm sont également différents d'hibernate comme un à plusieurs, les FK pour beaucoup sont intégrés dans la ligne car c'est comme ça que vous le faites dans nosql.

plus tard, Dean

Source

2013-07-03 12:30:26

Cassandra Schema

Répondre

Questions connexes