nosql-expert
Concevoir des bases de données NoSQL évolutives
Cette compétence fournit des conseils d'expert pour la conception de bases de données NoSQL distribuées (Cassandra, DynamoDB). Elle aide les développeurs à comprendre la modélisation orientée requêtes, la conception de table unique, et à éviter les pièges courants comme les partitions chaudes.
Télécharger le ZIP du skill
Importer dans Claude
Allez dans Paramètres → Capacités → Skills → Importer un skill
Activez et commencez à utiliser
Tester
Utilisation de "nosql-expert". Help me design a Cassandra primary key for storing user orders where I need to query by user_id and sort by order_date descending.
Résultat attendu:
Pour ce modèle d'accès, utilisez une clé primaire composite :
**Clé de partition :** user_id (cardinalité élevée - chaque utilisateur est une partition)
**Colonne de clustering :** order_date DESC (trie les commandes par date dans chaque partition)
```sql
CREATE TABLE orders_by_user (
user_id uuid,
order_id uuid,
order_date timestamp,
total decimal,
status text,
PRIMARY KEY (user_id, order_date)
) WITH CLUSTERING ORDER BY (order_date DESC);
```
Cette conception garantit que toutes les commandes d'un utilisateur résident dans une seule partition (efficace), et elles sont automatiquement triées par date.
Utilisation de "nosql-expert". What are the key differences between SQL and NoSQL data modeling?
Résultat attendu:
**Modèle mental SQL vs NoSQL distribué :**
| Aspect | SQL (Relationnel) | NoSQL (Cassandra/DynamoDB) |
|-------|------------------|---------------------------|
| Modélisation | Modéliser les entités + relations | Modéliser les **requêtes d'abord** |
| Jointures | Au moment de la lecture (coûteux) | Pré-calculées au moment de l'écriture |
| Stockage | Minimiser la duplication | Dupliquer pour la vitesse de lecture |
| Cohérence | ACID (forte) | BASE (à terme) |
| Mise à l'échelle | Verticale | Horizontale |
**Règle d'or :** En SQL, concevez les données pour *n'importe quelle* requête. En NoSQL, concevez les données pour des requêtes *spécifiques* efficacement.
Utilisation de "nosql-expert". Explain single-table design in DynamoDB
Résultat attendu:
**Conception de table unique DynamoDB :**
Stocker plusieurs types d'entités dans une seule table en utilisant des clés composites :
| PK | SK | Data |
|----|-----|------|
| USER#123 | PROFILE | {name: 'Ian', email: '...'} |
| USER#123 | ORDER#998 | {total: 50.00, status: 'shipped'} |
| USER#123 | ORDER#999 | {total: 12.00, status: 'pending'} |
**Requête :** PK='USER#123' récupère l'utilisateur + toutes les commandes en UNE seule requête.
**Avantages :**
- Complexité applicative réduite
- Utilisation optimisée des unités de capacité
- Un seul aller-retour réseau pour les données connexes
Audit de sécurité
SûrThis skill is purely educational documentation about NoSQL database design patterns. The static analyzer detected patterns (external_commands, weak_crypto, system_reconnaissance) that are FALSE POSITIVES - they are documentation examples of database table names, query syntax, and design concepts. No actual code execution, network calls, or file operations exist.
Problèmes à risque faible (3)
Score de qualité
Ce que vous pouvez construire
Concevoir un nouveau schéma Cassandra
Architecturer une structure de clé primaire Cassandra pour une application qui doit interroger par ID utilisateur et plage de dates efficacement.
Optimiser la conception de table unique DynamoDB
Refactoriser une table DynamoDB pour stocker plusieurs types d'entités (utilisateurs, commandes, produits) dans une seule table en utilisant des clés composites.
Corriger les problèmes de partitions chaudes
Identifier et résoudre les problèmes de partitions chaudes dans une table DynamoDB à fort trafic en améliorant la cardinalité de la clé de partition.
Essayez ces prompts
Help me design a Cassandra primary key for a table that stores user events. I need to query by user_id and filter by event_type within a date range. What should my partition key and clustering columns be?
I have three entity types: Users, Orders, and Products. Design a single DynamoDB table using composite keys where I can fetch a user's profile and all their orders in one request.
My DynamoDB table is experiencing throttling on one partition. The partition key is 'status' (values: 'active', 'pending', 'completed'). What's wrong and how do I fix it?
I have a relational schema with Author and Book tables joined by author_id. How should I model this in Cassandra or DynamoDB without joins?
Bonnes pratiques
- Concevez toujours les clés de partition avec une cardinalité élevée pour éviter les partitions chaudes
- Pré-calculez les jointures au moment de l'écriture en utilisant la dénormalisation au lieu d'interroger plusieurs tables
- Utilisez des clés de partition composites (par ex. USER#123#2024-01) pour empêcher les partitions de dépasser 10 Go
Éviter
- Utiliser des clés de partition à faible cardinalité comme status='active' ou gender='m' (crée des partitions chaudes)
- Utiliser des requêtes 'scatter-gather' qui analysent toutes les partitions au lieu de cibler des clés spécifiques
- Appliquer des modèles de modélisation SQL (tables séparées avec clés étrangères) aux bases de données NoSQL