Obtention d'une entrée de base de données lors d'une opération de suppression dans Cassandra

Question

J'ai un service Web qui maintient l'état d'une "requête". Les états possibles sont "Active" et "InActive". Je stocke les informations de demande dans une base de données Cassandra. J'ai deux tables - une pour les demandes actives et une autre pour les demandes InActive. Ils ont tous les deux le même schéma.

Mon schéma est comme suit:

ActiveRequests{ 
    UserId text, 
    RequestId int, 
    RequestData text 
    PRIMARY KEY(UserId, RequestId) 
} 

J'ai besoin de mettre en œuvre une API qui se déplacera une demande de l'état actif à l'état inactif. Je prévois de le faire en supprimant l'entrée de la table active, puis en ajoutant l'entrée supprimée à la table InActive.

Dans Cassandra, il semble qu'une opération DELETE ne retourne pas réellement les données qui ont été supprimées. Donc, je dois faire un SELECT sur l'entrée de la demande (de sorte que je puisse obtenir toutes les données de demande pour l'ajout à la table InActive) et ensuite faire une opération DELETE. Y a-t-il une meilleure manière de faire cela?

EDIT

Vous pouvez demander pourquoi je maintiens les demandes actives et inactives comme des tables séparées. Je pourrais potentiellement les combiner dans une seule table et avoir une colonne IsActive. Mon raisonnement pour maintenir des tables séparées est le suivant:

Je veux que mes requêtes à la table active soient très rapides. Si je veux interroger toutes les demandes actives dans une table qui a des demandes actives et InActive qui ne seront pas optimales. PartitionKey est userId et j'attends que la table InActive ait plusieurs 1000 requestIds pour un UserId donné. Mais, Active ne devrait avoir que 10 requestIds ou plus par UserId.

Answer 1

La réponse de base à avoir DELETE retourner les données est que ce n'est vraiment pas quelque chose que Cassandra peut faire. Une suppression dans Cassandra est en fait une écriture d'une pierre tombale. Cassandra en général ne fera pas de lectures avant d'écrire et en avoir besoin est en fait considéré comme un anti-pattern.

Une autre chose à retenir est une suppression dans Cassandra signifie que les données ne quittent le système que quelque temps après les réglages GC Grace pour cette table.

Ces demandes sont-elles toujours basées? Si c'est le cas, vous pourriez penser à seau les demandes. Donc, vous auriez une seule table quelque chose comme:

Requests{ 
    UserId text, 
    TimeBucket text, 
    RequestId int, 
    RequestData text, 
    Active boolean, 
    PRIMARY KEY((UserId, TimeBucket) RequestId) 
} 

Les seaux de temps pourrait être à l'heure ou à la minute ce qui fait toujours sens pour votre cas d'utilisation. Vous pouvez ensuite travailler à travers les compartiments donnés avec des sélections différentes. Cela vous évitera d'avoir trop de demandes pour une clé de partition donnée. L'hypothèse est que le timebucket est assez grand pour couvrir la plupart des requêtes actives et que vous n'avez donc pas besoin de regarder tous les buckets. Je ne sais pas non plus combien de temps vous prévoyez de conserver des enregistrements s'ils sont conservés pendant de longues périodes ou si, à tout jamais, ce stockage ne vous permettra pas de créer des partitions trop grandes qui pourraient se retrouver dans le Table InActive avec l'autre configuration.