L'utilisation de Cassandra pour une série chronologique de données

Je suis sur mes recherches pour le stockage des journaux à Cassandra.

Le schéma de journaux pourrait être quelque chose comme ça.

EDIT: j'ai modifié le schéma afin d'apporter quelques précisions.

CREATE TABLE log_date (
  userid bigint,
  time timeuuid,
  reason text,
  item text,
  price int,
  count int,
  PRIMARY KEY ((userid), time) - #1
  PRIMARY KEY ((userid), time, reason, item, price, count) - #2
);

Un nouveau tableau sera créé pour la journée tous les jours.
Si une table contient les journaux pour une seule journée.

Mon interrogation condition est comme suit.

Requête de tous les journaux à partir d'un utilisateur spécifique sur un jour précis(date pas du temps).

Donc, la raison, le point, le prix, le nombre de pas être utilisées comme des conseils ou des conditions pour les requêtes à tous.

Ma Question est la PRINCIPALE CLÉ de la conception convient le mieux.

EDIT: Et la clé ici est que je veux stocker les logs de manière schématique.

Si je choisis #1 ainsi, de nombreuses colonnes seraient créés par le journal. Et la possibilité d'avoir plus de valeurs par journal est très élevé. Le schéma ci-dessus est juste un exemple. Le journal peut contenir des valeurs comme subreason, friendid et ainsi de suite.

Si je choisis #2 un (très) composite colonne va être créé par le journal, et jusqu'à présent je ne pouvais pas trouver toutes les informations précieuses à propos de la surcharge de l'colonnes composites.

Lequel dois-je choisir? S'il vous plaît aider.

InformationsquelleAutor Woojun Kim | 2015-05-07
  1. 19

    Mon conseil est qu'aucun de vos deux options me semble être idéal pour votre temps de la série, le fait que vous êtes en train de créer une table par jour, ne semble pas optimal non plus.

    Au lieu de cela, je vous recommande de créer une seule Table de partition et par nom d'utilisateur et le jour et utiliser un temps d'uuid que le cluster de la colonne pour l'événement, un exemple de ceci serait:

    CREATE TABLE log_per_day (
   userid bigint,
   date text, 
   time timeuuid, 
   value text,
      PRIMARY KEY ((userid, date), time)
)

    Cela vous permettra d'avoir tous les événements en un jour, en une seule ligne et vous permettent de faire votre requête par jour et par utilisateur.

    En déclarant la time cluster colonne permet de disposer d'une large ligne où vous pouvez insérer un des nombreux événements que vous avez besoin dans une journée.

    Donc la clé de la ligne est un composite key le nom d'usager et plus date dans un texte, par exemple

    insert into log_per_day (userid, date, time, value) values (1000,'2015-05-06',aTimeUUID1,'my value')

    insert into log_per_day (userid, date, time, value) values (1000,'2015-05-06',aTimeUUID2,'my value2')

    Les deux plaquettes ci-dessus sera dans la même ligne et, par conséquent, vous serez en mesure de lire en une seule requête.

    Aussi, si vous souhaitez plus d'informations sur le temps de la série, je vous recommande fortement de vérifier Mise en route avec le Temps, la Série de la Modélisation de Données

    Espérons que cela aide,

    José Luis

    • Merci mais ma question n'est pas sur la partition ou le clustering partie de la clé, mais sur le stockage le reste de la bûche de façon schématique.
    • Je suis d'accord avec @jbarrueta pour le partitionnement/clustering. En matière de stockage de repos de données du journal, Car il peut être variable, l'u a deux approches possibles: 1. Carte de type de données pour le stockage sous forme de paires clé-valeur 2. les données json stocké dans le type de données texte format. P. S. :la Seconde approche est léger sur les besoins en mémoire.
    • Le lien doit être mis à jour à: academy.datastax.com/resources/...
    InformationsquelleAutor jbarrueta