Cassandra modèle de données avec plusieurs conditions

Question

Je suis nouveau à Cassandra, donc j'ai lu une douzaine d'articles à ce sujet et donc je connais les bases. Tous les tutoriels montrent une récupération de données efficace par 1 ou 2 colonnes et une plage de temps. Ce que je ne pouvais pas trouver était comment modéliser correctement vos données si vous avez plus de conditions.

J'ai un grand événement base de données normalisée, avec quelques colonnes, dites:

• Type d'événement
• temps
• email
• User_age
• user_country
• user_language
• et ainsi de suite.

Je devrais pouvoir interroger toutes les colonnes. Donc SGBDR j'interroger:

SELECT email FROM table WHERE time > X AND user_age BETWEEN X AND X AND user_language = 'nl' etc ..

Je sais que je peux faire un tableau distinct pour chaque colonne, mais je encore besoin de combiner les résultats. Peut-être que ce n'est pas une mauvaise approche, mais j'en doute car il n'y a pas de sous-requêtes.

Ma question est évidemment, comment puis-je modéliser ce type de données correctement dans Cassandra?

Merci beaucoup!

Answer 1

Je devrais pouvoir interroger toutes les colonnes.

Laissez-moi vous arrêter là. Dans Cassandra, vous créez vos tables en fonction de vos modèles de requête anticipés, et généralement une table prend en charge une seule requête. Dans votre cas, vous avez "plusieurs" colonnes et vous devrez dupliquer ces données dans une table conçue pour prendre en charge chaque requête possible. Cela va devenir gros et disgracieux, très rapidement. Pourrions-nous simplement ajouter le reste en tant qu'index secondaires?

il peut toujours y avoir des millions de lignes dans la table eventtype + merchant_id + sélection de l'heure.

Les index secondaires sont destinés à être utilisés sur des colonnes de cardinalité au centre de la route. Les deux colonnes de cardinalité extrêmement basse et extrêmement élevée sont donc mauvaises pour les index secondaires. Le problème, c'est que Cassandra devra choisir un de vos nœuds en tant que coordinateur, analyser l'index sur chaque nœud (ce qui implique beaucoup de temps réseau), puis générer et renvoyer le jeu de résultats. C'est une prescription pour une mauvaise performance, qui va à l'encontre des meilleures pratiques pour travailler avec une base de données distribuée.

En bref, Cassandra n'est pas une bonne solution pour les cas d'utilisation comme celui-ci. Il semble que vous vouliez être capable de faire des requêtes de type OLAP, et pour cela vous devriez utiliser un outil mieux adapté à cette fin.