Je veux utiliser Cassandra dans une application .Net. Mon objective est de stocker des données dans une famille de colonnes, mais chaque ligne de données aura un schéma différent.
Exemple (très simple) Je souhaite disposer d’une famille de colonnes “Jouets” pour stocker les objects suivants (remarquez qu’ils ont des propriétés très différentes de la propriété ID)
Objet de jouet 1 {“id”: “1”, “name”: “Voiture”, “numéro_de_porte”: 4, “aime”: 3}
Objet de jouet 2 {“id”: “2”, “type”: “avion”, “plage_volante”: “100m”}
Objet de jouet 3 {“id”: “3”, “catégorie”: “Train”, “nombre_de_carriages”: 10}
D’après ma compréhension initiale et l’utilisation du pilote Datastax CSharp, je dois toujours modifier le tableau (famille de colonnes), ce qui ne me convient pas. Je voudrais que chaque ligne ait son propre schéma. Thrift API pourrait peut-être résoudre ce problème, mais il semblerait qu’HectorSharp soit pratiquement mort.
Une question similaire à mon besoin mais qui n’a pas la réponse que je veux
Cassandra pour une firebase database sans schéma, 10 millions de tables de commandes et des millions de requêtes par jour
Est-ce que j’aborde le mauvais arbre en m’attendant à ce que chaque ligne ait son propre schéma ou existe-t-il un moyen de le faire avec Cassandra + Csharp?
Merci d’avance pour vos réponses.
Les anciennes versions de Cassandra étaient sans schéma, ce qui voulait dire que vous n’aviez nulle part une définition de ce que pouvait contenir une ligne. Ce dont vous avez besoin maintenant pourrait être partiellement fait avec une Map
sur Cassandra 2.1
CREATE TABLE toys ( id text PRIMARY KEY, toy map )
Mettez des données …
INSERT INTO toys (id, toy) VALUES ( '1', {'name':'Car', 'number_of_doors':'4', 'likes':'3'}); INSERT INTO toys (id, toy) VALUES ( '2', {'type':'Plane', 'flying_range':'100m'}); INSERT INTO toys (id, toy) VALUES ( '3', {'category':'Train', 'number_of_carriages':'10'});
Contenu de la table …
id | toy ----+------------------------------------------------------- 3 | {'category': 'Train', 'number_of_carriages': '10'} 2 | {'flying_range': '100m', 'type': 'Plane'} 1 | {'likes': '3', 'name': 'Car', 'number_of_doors': '4'}
Nous pouvons maintenant créer un index sur les clés …
CREATE INDEX toy_idx ON toys (KEYS(toy));
… et effectuer des requêtes sur les touches de la carte …
SELECT * FROM toys WHERE toy CONTAINS KEY 'name'; id | toy ----+------------------------------------------------------- 1 | {'likes': '3', 'name': 'Car', 'number_of_doors': '4'}
Maintenant, vous pouvez mettre à jour ou supprimer des entrées de carte comme vous le feriez avec des colonnes normales, sans lire avant d’écrire
DELETE toy['name'] FROM toys WHERE id='1'; UPDATE toys set toy = toy + {'name': 'anewcar'} WHERE id = '1'; SELECT * FROM toys; id | toy ----+----------------------------------------------------------- 3 | {'category': 'Train', 'number_of_carriages': '10'} 2 | {'flying_range': '100m', 'type': 'Plane'} 1 | {'likes': '3', 'name': 'anewcar', 'number_of_doors': '4'}
Quelques limitations
Personnellement, je considère qu’une utilisation extensive de cette approche est un anti-modèle.
HTH, Carlo
Pour append à la réponse de Carlo: