nosql-expert
Design Scalable NoSQL Databases
This skill provides expert guidance for designing distributed NoSQL databases (Cassandra, DynamoDB). It helps developers understand query-first modeling, single-table design, and avoid common pitfalls like hot partitions.
Baixar o ZIP da skill
Upload no Claude
Vá em Configurações → Capacidades → Skills → Upload skill
Ative e comece a usar
Testar
A utilizar "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.
Resultado esperado:
For this access pattern, use a composite primary key:
**Partition Key:** user_id (high cardinality - each user is a partition)
**Clustering Column:** order_date DESC (sorts orders by date within each 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);
```
This design ensures all orders for a user live in one partition (efficient), and they're automatically sorted by date.
A utilizar "nosql-expert". What are the key differences between SQL and NoSQL data modeling?
Resultado esperado:
**SQL vs Distributed NoSQL Mental Model:**
| Aspect | SQL (Relational) | NoSQL (Cassandra/DynamoDB) |
|-------|------------------|---------------------------|
| Modeling | Model entities + relationships | Model **queries first** |
| Joins | At read time (expensive) | Pre-computed at write time |
| Storage | Minimize duplication | Duplicate for read speed |
| Consistency | ACID (strong) | BASE (eventual) |
| Scaling | Vertical | Horizontal |
**Golden Rule:** In SQL, design data for *any* query. In NoSQL, design data for *specific* queries efficiently.
A utilizar "nosql-expert". Explain single-table design in DynamoDB
Resultado esperado:
**DynamoDB Single-Table Design:**
Store multiple entity types in one table using composite keys:
| 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'} |
**Query:** PK='USER#123' retrieves user + all orders in ONE request.
**Benefits:**
- Reduced application complexity
- Optimized capacity unit usage
- Single network round-trip for related data
Auditoria de Segurança
SeguroThis 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.
Problemas de Baixo Risco (3)
Pontuação de qualidade
O Que Você Pode Construir
Design a new Cassandra schema
Architect a Cassandra primary key structure for an application that needs to query by user ID and date range efficiently.
Optimize DynamoDB single-table design
Refactor a DynamoDB table to store multiple entity types (users, orders, products) in one table using composite keys.
Fix hot partition issues
Identify and resolve hot partition problems in a high-traffic DynamoDB table by improving partition key cardinality.
Tente Estes 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?
Melhores Práticas
- Always design partition keys with high cardinality to avoid hot partitions
- Pre-compute joins at write time using denormalization instead of querying multiple tables
- Use composite partition keys (e.g., USER#123#2024-01) to prevent partitions from exceeding 10GB
Evitar
- Using low-cardinality partition keys like status='active' or gender='m' (creates hot partitions)
- Using 'scatter-gather' queries that scan all partitions instead of targeting specific keys
- Applying SQL modeling patterns (separate tables with foreign keys) to NoSQL databases