[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6FTCXHX6X2DVRZPE35MPXJ7":3,"skill-same:01M6FTCXHX6X2DVRZPE35MPXJ7":70},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":42,"linkOnly":43,"markdownContent":44,"markdownBody":45,"frontMatter":46,"refName":48,"commitSha":49,"skillDirectory":50,"forksCount":14,"repositoryHtmlUrl":51,"repositoryHomepageUrl":6,"ownerHtmlUrl":52,"ownerBlogUrl":53,"ownerDescription":54,"updatedAt":55,"install":56,"resources":69},"01M6FTCXHX6X2DVRZPE35MPXJ7","nosql-expert",null,"Expert guidance for distributed NoSQL databases (Cassandra, DynamoDB). Focuses on mental models, query-first modeling, single-table design, and avoiding hot partitions in high-scale systems.","reikiplanet\u002Fdaoskills","reikiplanet","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F96377599?v=4","01M6CVWCMD740YHQDK7E9QYBW4","Reiki Planet","01M6CVWCS4KXVA2CWFVJ43EAXK",0,"MIT","https:\u002F\u002Fgithub.com\u002Freikiplanet\u002Fdaoskills\u002Fblob\u002Fmaster\u002Fdata\u002Fnosql-expert\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41],"nosql","nosql expert","expert","guidance","scale","systems","modeling","partitions","dynamodb","query","community","design","models","databases","table","first","cassandra","distributed","2026-11-10 10:12:30",false,"---\nname: nosql-expert\ndescription: \"Expert guidance for distributed NoSQL databases (Cassandra, DynamoDB). Focuses on mental models, query-first modeling, single-table design, and avoiding hot partitions in high-scale systems.\"\nrisk: unknown\nsource: community\n---\n\n# NoSQL Expert Patterns (Cassandra & DynamoDB)\n\n## Overview\n\nThis skill provides professional mental models and design patterns for **distributed wide-column and key-value stores** (specifically Apache Cassandra and Amazon DynamoDB).\n\nUnlike SQL (where you model data entities), or document stores (like MongoDB), these distributed systems require you to **model your queries first**.\n\n## When to Use\n\n- **Designing for Scale**: Moving beyond simple single-node databases to distributed clusters.\n- **Technology Selection**: Evaluating or using **Cassandra**, **ScyllaDB**, or **DynamoDB**.\n- **Performance Tuning**: Troubleshooting \"hot partitions\" or high latency in existing NoSQL systems.\n- **Microservices**: Implementing \"database-per-service\" patterns where highly optimized reads are required.\n\n## The Mental Shift: SQL vs. Distributed NoSQL\n\n| Feature | SQL (Relational) | Distributed NoSQL (Cassandra\u002FDynamoDB) |\n| :--- | :--- | :--- |\n| **Data modeling** | Model Entities + Relationships | Model **Queries** (Access Patterns) |\n| **Joins** | CPU-intensive, at read time | **Pre-computed** (Denormalized) at write time |\n| **Storage cost** | Expensive (minimize duplication) | Cheap (duplicate data for read speed) |\n| **Consistency** | ACID (Strong) | **BASE (Eventual)** \u002F Tunable |\n| **Scalability** | Vertical (Bigger machine) | **Horizontal** (More nodes\u002Fshards) |\n\n> **The Golden Rule:** In SQL, you design the data model to answer *any* query. In NoSQL, you design the data model to answer *specific* queries efficiently.\n\n## Core Design Patterns\n\n### 1. Query-First Modeling (Access Patterns)\n\nYou typically cannot \"add a query later\" without migration or creating a new table\u002Findex.\n\n**Process:**\n1.  **List all Entities** (User, Order, Product).\n2.  **List all Access Patterns** (\"Get User by Email\", \"Get Orders by User sorted by Date\").\n3.  **Design Table(s)** specifically to serve those patterns with a single lookup.\n\n### 2. The Partition Key is King\n\nData is distributed across physical nodes based on the **Partition Key (PK)**.\n-   **Goal:** Even distribution of data and traffic.\n-   **Anti-Pattern:** Using a low-cardinality PK (e.g., `status=\"active\"` or `gender=\"m\"`) creates **Hot Partitions**, limiting throughput to a single node's capacity.\n-   **Best Practice:** Use high-cardinality keys (User IDs, Device IDs, Composite Keys).\n\n### 3. Clustering \u002F Sort Keys\n\nWithin a partition, data is sorted on disk by the **Clustering Key (Cassandra)** or **Sort Key (DynamoDB)**.\n-   This allows for efficient **Range Queries** (e.g., `WHERE user_id=X AND date > Y`).\n-   It effectively pre-sorts your data for specific retrieval requirements.\n\n### 4. Single-Table Design (Adjacency Lists)\n\n*Primary use: DynamoDB (but concepts apply elsewhere)*\n\nStoring multiple entity types in one table to enable pre-joined reads.\n\n| PK (Partition) | SK (Sort) | Data Fields... |\n| :--- | :--- | :--- |\n| `USER#123` | `PROFILE` | `{ name: \"Ian\", email: \"...\" }` |\n| `USER#123` | `ORDER#998` | `{ total: 50.00, status: \"shipped\" }` |\n| `USER#123` | `ORDER#999` | `{ total: 12.00, status: \"pending\" }` |\n\n-   **Query:** `PK=\"USER#123\"`\n-   **Result:** Fetches User Profile AND all Orders in **one network request**.\n\n### 5. Denormalization & Duplication\n\nDon't be afraid to store the same data in multiple tables to serve different query patterns.\n-   **Table A:** `users_by_id` (PK: uuid)\n-   **Table B:** `users_by_email` (PK: email)\n\n*Trade-off: You must manage data consistency across tables (often using eventual consistency or batch writes).*\n\n## Specific Guidance\n\n### Apache Cassandra \u002F ScyllaDB\n\n-   **Primary Key Structure:** `((Partition Key), Clustering Columns)`\n-   **No Joins, No Aggregates:** Do not try to `JOIN` or `GROUP BY`. Pre-calculate aggregates in a separate counter table.\n-   **Avoid `ALLOW FILTERING`:** If you see this in production, your data model is wrong. It implies a full cluster scan.\n-   **Writes are Cheap:** Inserts and Updates are just appends to the LSM tree. Don't worry about write volume as much as read efficiency.\n-   **Tombstones:** Deletes are expensive markers. Avoid high-velocity delete patterns (like queues) in standard tables.\n\n### AWS DynamoDB\n\n-   **GSI (Global Secondary Index):** Use GSIs to create alternative views of your data (e.g., \"Search Orders by Date\" instead of by User).\n    -   *Note:* GSIs are eventually consistent.\n-   **LSI (Local Secondary Index):** Sorts data differently *within* the same partition. Must be created at table creation time.\n-   **WCU \u002F RCU:** Understand capacity modes. Single-table design helps optimize consumed capacity units.\n-   **TTL:** Use Time-To-Live attributes to automatically expire old data (free delete) without creating tombstones.\n\n## Expert Checklist\n\nBefore finalizing your NoSQL schema:\n\n-   [ ] **Access Pattern Coverage:** Does every query pattern map to a specific table or index?\n-   [ ] **Cardinality Check:** Does the Partition Key have enough unique values to spread traffic evenly?\n-   [ ] **Split Partition Risk:** For any single partition (e.g., a single user's orders), will it grow indefinitely? (If > 10GB, you need to \"shard\" the partition, e.g., `USER#123#2024-01`).\n-   [ ] **Consistency Requirement:** Can the application tolerate eventual consistency for this read pattern?\n\n## Common Anti-Patterns\n\n❌ **Scatter-Gather:** Querying *all* partitions to find one item (Scan).\n❌ **Hot Keys:** Putting all \"Monday\" data into one partition.\n❌ **Relational Modeling:** Creating `Author` and `Book` tables and trying to join them in code. (Instead, embed Book summaries in Author, or duplicate Author info in Books).\n","# NoSQL Expert Patterns (Cassandra & DynamoDB)\n\n## Overview\n\nThis skill provides professional mental models and design patterns for **distributed wide-column and key-value stores** (specifically Apache Cassandra and Amazon DynamoDB).\n\nUnlike SQL (where you model data entities), or document stores (like MongoDB), these distributed systems require you to **model your queries first**.\n\n## When to Use\n\n- **Designing for Scale**: Moving beyond simple single-node databases to distributed clusters.\n- **Technology Selection**: Evaluating or using **Cassandra**, **ScyllaDB**, or **DynamoDB**.\n- **Performance Tuning**: Troubleshooting \"hot partitions\" or high latency in existing NoSQL systems.\n- **Microservices**: Implementing \"database-per-service\" patterns where highly optimized reads are required.\n\n## The Mental Shift: SQL vs. Distributed NoSQL\n\n| Feature | SQL (Relational) | Distributed NoSQL (Cassandra\u002FDynamoDB) |\n| :--- | :--- | :--- |\n| **Data modeling** | Model Entities + Relationships | Model **Queries** (Access Patterns) |\n| **Joins** | CPU-intensive, at read time | **Pre-computed** (Denormalized) at write time |\n| **Storage cost** | Expensive (minimize duplication) | Cheap (duplicate data for read speed) |\n| **Consistency** | ACID (Strong) | **BASE (Eventual)** \u002F Tunable |\n| **Scalability** | Vertical (Bigger machine) | **Horizontal** (More nodes\u002Fshards) |\n\n> **The Golden Rule:** In SQL, you design the data model to answer *any* query. In NoSQL, you design the data model to answer *specific* queries efficiently.\n\n## Core Design Patterns\n\n### 1. Query-First Modeling (Access Patterns)\n\nYou typically cannot \"add a query later\" without migration or creating a new table\u002Findex.\n\n**Process:**\n1.  **List all Entities** (User, Order, Product).\n2.  **List all Access Patterns** (\"Get User by Email\", \"Get Orders by User sorted by Date\").\n3.  **Design Table(s)** specifically to serve those patterns with a single lookup.\n\n### 2. The Partition Key is King\n\nData is distributed across physical nodes based on the **Partition Key (PK)**.\n-   **Goal:** Even distribution of data and traffic.\n-   **Anti-Pattern:** Using a low-cardinality PK (e.g., `status=\"active\"` or `gender=\"m\"`) creates **Hot Partitions**, limiting throughput to a single node's capacity.\n-   **Best Practice:** Use high-cardinality keys (User IDs, Device IDs, Composite Keys).\n\n### 3. Clustering \u002F Sort Keys\n\nWithin a partition, data is sorted on disk by the **Clustering Key (Cassandra)** or **Sort Key (DynamoDB)**.\n-   This allows for efficient **Range Queries** (e.g., `WHERE user_id=X AND date > Y`).\n-   It effectively pre-sorts your data for specific retrieval requirements.\n\n### 4. Single-Table Design (Adjacency Lists)\n\n*Primary use: DynamoDB (but concepts apply elsewhere)*\n\nStoring multiple entity types in one table to enable pre-joined reads.\n\n| PK (Partition) | SK (Sort) | Data Fields... |\n| :--- | :--- | :--- |\n| `USER#123` | `PROFILE` | `{ name: \"Ian\", email: \"...\" }` |\n| `USER#123` | `ORDER#998` | `{ total: 50.00, status: \"shipped\" }` |\n| `USER#123` | `ORDER#999` | `{ total: 12.00, status: \"pending\" }` |\n\n-   **Query:** `PK=\"USER#123\"`\n-   **Result:** Fetches User Profile AND all Orders in **one network request**.\n\n### 5. Denormalization & Duplication\n\nDon't be afraid to store the same data in multiple tables to serve different query patterns.\n-   **Table A:** `users_by_id` (PK: uuid)\n-   **Table B:** `users_by_email` (PK: email)\n\n*Trade-off: You must manage data consistency across tables (often using eventual consistency or batch writes).*\n\n## Specific Guidance\n\n### Apache Cassandra \u002F ScyllaDB\n\n-   **Primary Key Structure:** `((Partition Key), Clustering Columns)`\n-   **No Joins, No Aggregates:** Do not try to `JOIN` or `GROUP BY`. Pre-calculate aggregates in a separate counter table.\n-   **Avoid `ALLOW FILTERING`:** If you see this in production, your data model is wrong. It implies a full cluster scan.\n-   **Writes are Cheap:** Inserts and Updates are just appends to the LSM tree. Don't worry about write volume as much as read efficiency.\n-   **Tombstones:** Deletes are expensive markers. Avoid high-velocity delete patterns (like queues) in standard tables.\n\n### AWS DynamoDB\n\n-   **GSI (Global Secondary Index):** Use GSIs to create alternative views of your data (e.g., \"Search Orders by Date\" instead of by User).\n    -   *Note:* GSIs are eventually consistent.\n-   **LSI (Local Secondary Index):** Sorts data differently *within* the same partition. Must be created at table creation time.\n-   **WCU \u002F RCU:** Understand capacity modes. Single-table design helps optimize consumed capacity units.\n-   **TTL:** Use Time-To-Live attributes to automatically expire old data (free delete) without creating tombstones.\n\n## Expert Checklist\n\nBefore finalizing your NoSQL schema:\n\n-   [ ] **Access Pattern Coverage:** Does every query pattern map to a specific table or index?\n-   [ ] **Cardinality Check:** Does the Partition Key have enough unique values to spread traffic evenly?\n-   [ ] **Split Partition Risk:** For any single partition (e.g., a single user's orders), will it grow indefinitely? (If > 10GB, you need to \"shard\" the partition, e.g., `USER#123#2024-01`).\n-   [ ] **Consistency Requirement:** Can the application tolerate eventual consistency for this read pattern?\n\n## Common Anti-Patterns\n\n❌ **Scatter-Gather:** Querying *all* partitions to find one item (Scan).\n❌ **Hot Keys:** Putting all \"Monday\" data into one partition.\n❌ **Relational Modeling:** Creating `Author` and `Book` tables and trying to join them in code. (Instead, embed Book summaries in Author, or duplicate Author info in Books).\n",{"name":5,"risk":47,"source":34,"description":7},"unknown","master","dff58085da947e81e8418c922055644bf0082b1b","data\u002Fnosql-expert","https:\u002F\u002Fgithub.com\u002Freikiplanet\u002Fdaoskills","https:\u002F\u002Fgithub.com\u002Freikiplanet","https:\u002F\u002Fwww.reiki-planet.com","Reiki Planet Game","2026-03-29 06:02:29",{"source":8,"skillName":5,"commands":57,"prompt":67,"zipAvailable":68},[58,61,64],{"tool":59,"command":60},"npx","npx skills add reikiplanet\u002Fdaoskills --skill nosql-expert",{"tool":62,"command":63},"bunx","bunx skills add reikiplanet\u002Fdaoskills --skill nosql-expert",{"tool":65,"command":66},"pnpm","pnpm dlx skills add reikiplanet\u002Fdaoskills --skill nosql-expert","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Freikiplanet\u002Fdaoskills\u002Fblob\u002Fmaster\u002Fdata\u002Fnosql-expert\u002FSKILL.md",true,[],[71,97,109,124,143,166],{"skillNo":72,"name":73,"nameZh":6,"description":74,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":75,"categories":76,"keywords":77,"publishedAt":42},"01M6G614JTEQJHPT8AKK3YQ18S","web-games","Web browser game development principles. Framework selection, WebGPU, optimization, PWA.","https:\u002F\u002Fgithub.com\u002Freikiplanet\u002Fdaoskills\u002Fblob\u002Fmaster\u002Fweb-games\u002FSKILL.md",[],[78,79,80,81,82,83,34,84,85,86,87,88,89,90,91,92,93,94,95,96],"games","web games","web","grep","principles","selection","framework selection","edit","write","read","pwa","game","web browser","game development","Optimization","framework","browser","development","webgpu",{"skillNo":98,"name":99,"nameZh":6,"description":100,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":101,"categories":102,"keywords":103,"publishedAt":42},"01M6G611H2YGV0GZFP90D38ZMJ","vr-ar","VR\u002FAR development principles. Comfort, interaction, performance requirements.","https:\u002F\u002Fgithub.com\u002Freikiplanet\u002Fdaoskills\u002Fblob\u002Fmaster\u002Fvr-ar\u002FSKILL.md",[],[104,105,95,106,107,34,85,86,87,81,108,82],"ar","vr ar","interaction","requirements","performance",{"skillNo":110,"name":111,"nameZh":6,"description":112,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":113,"categories":114,"keywords":115,"publishedAt":42},"01M6G60XNMHAMV1SV0EJ1CX0AY","templates","Project scaffolding templates for new applications. Use when creating new projects from scratch. Contains 12 templates for various tech stacks.","https:\u002F\u002Fgithub.com\u002Freikiplanet\u002Fdaoskills\u002Fblob\u002Fmaster\u002Ftemplates\u002FSKILL.md",[],[111,116,117,118,119,120,34,121,87,122,123,81],"project scaffolding","From Scratch","tech","project","scaffolding","use","projects","applications",{"skillNo":125,"name":126,"nameZh":6,"description":127,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":128,"categories":129,"keywords":130,"publishedAt":42},"01M6G60T0GATMK3Q5H8GDC1Z8S","wcag-audit-patterns","Conduct WCAG 2.2 accessibility audits with automated testing, manual verification, and remediation guidance. Use when auditing websites for accessibility, fixing WCAG violations, or implementing ac...","https:\u002F\u002Fgithub.com\u002Freikiplanet\u002Fdaoskills\u002Fblob\u002Fmaster\u002Fskills\u002Fsecurity\u002Fwcag-audit-patterns\u002FSKILL.md",[],[131,132,133,134,135,34,136,137,138,27,121,139,140,141,142],"wcag audit patterns","wcag audit","patterns","WCAG","audit","manual","with","automated testing","remediation","verification","accessibility","testing",{"skillNo":144,"name":145,"nameZh":6,"description":146,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":147,"categories":148,"keywords":149,"publishedAt":42},"01M6G60PMCHW1FRZ63F931QK3R","vulnerability-scanner","Advanced vulnerability analysis principles. OWASP 2025, Supply Chain Security, attack surface mapping, risk prioritization.","https:\u002F\u002Fgithub.com\u002Freikiplanet\u002Fdaoskills\u002Fblob\u002Fmaster\u002Fskills\u002Fsecurity\u002Fvulnerability-scanner\u002FSKILL.md",[],[150,151,152,153,154,155,156,157,34,87,81,158,82,159,160,161,162,163,164,165],"scanner","vulnerability scanner","vulnerability","prioritization","2025","mapping","chain","supply chain","Bash","analysis","risk","owasp","supply chain security","security","supply","advanced",{"skillNo":167,"name":168,"nameZh":6,"description":169,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":170,"categories":171,"keywords":172,"publishedAt":42},"01M6G60JZBB8DK0W3DSG1WNMZK","threat-modeling-expert","Expert in threat modeling methodologies, security architecture review, and risk assessment. Masters STRIDE, PASTA, attack trees, and security requirement extraction. Use for security architecture r...","https:\u002F\u002Fgithub.com\u002Freikiplanet\u002Fdaoskills\u002Fblob\u002Fmaster\u002Fskills\u002Fsecurity\u002Fthreat-modeling-expert\u002FSKILL.md",[],[30,173,174,26,175,176,177,178,163,121,179,180,181,34,182,183,184,160,185,186],"threat modeling expert","threat modeling","threat","risk assessment","architecture review","architecture","security architecture review","trees","security architecture","security requirement extraction","assessment","extraction","review","stride"]