nosql-expert
設計可擴展的 NoSQL 資料庫
此技能提供設計分散式 NoSQL 資料��（Cassandra、DynamoDB）的專業指導。它幫助開發人員理解以查詢為優先的建模、單表設計，並避免常見陷阱如熱分割區。
تنزيل ZIP المهارة
رفع في Claude
اذهب إلى Settings → Capabilities → Skills → Upload skill
فعّل وابدأ الاستخدام
اختبرها
استخدام "nosql-expert". 幫我設計一個用於儲存使用者訂單的 Cassandra 主鍵，我需要依 user_id 查詢並依 order_date 降序排序。
النتيجة المتوقعة:
對於此存取模式，使用複合主鍵：
**分割區鍵：** user_id（高基數——每個使用者是一個分割區）
**叢集欄位：** order_date DESC（在每個分割區內依日期排序訂單）
```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);
```
此設計確保使用者的所有訂單都在一個分割區中（有效率），並且它們會自動依日期排序。
استخدام "nosql-expert". SQL 和 NoSQL 資料建模的主要差異是什麼？
النتيجة المتوقعة:
**SQL 與分散式 NoSQL 思維模型：**
| 方面 | SQL（關聯式）| NoSQL（Cassandra/DynamoDB）|
|-------|------------------|---------------------------|
| 建模 | 模型實體 + 關聯 | 模型**以查詢為優先**|
| 連接 | 在讀取時（昂貴）| 在寫入時預先計算|
| 儲存 | 最小化重複 | 為讀取速度而重複|
| 一致性 | ACID（強）| BASE（最終）|
| 擴展 | 垂直 | 水平|
**黃金法則：** 在 SQL 中，設計資料以適配*任何*查詢。在 NoSQL 中，設計資料以有效地執行*特定*查詢。
استخدام "nosql-expert". 解釋 DynamoDB 中的單表設計
النتيجة المتوقعة:
**DynamoDB 單表設計：**
使用複合鍵在一個資料��中儲存多個實體類型：
| PK | SK | 資料 |
|----|-----|------|
| USER#123 | PROFILE | {name: 'Ian', email: '...'} |
| USER#123 | ORDER#998 | {total: 50.00, status: 'shipped'} |
| USER#123 | ORDER#999 | {total: 12.00, status: 'pending'} |
**查詢：** PK='USER#123' 在單一請求中擷取使用者 + 所有訂單。
**優點：**
- 減少應用程式複雜度
- 優化容量單位使用
- 相關資料的單一網路往返
التدقيق الأمني
آمنThis 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.
مشكلات منخفضة المخاطر (3)
درجة الجودة
ماذا يمكنك بناءه
設計新的 Cassandra 綱要
為需要依使用者 ID 和日期範圍有效查詢的應用程式設計 Cassandra 主鍵結構。
優化 DynamoDB 單表設計
使用複合鍵將 DynamoDB 資料表重構為在一個資料表中儲存多個實體類型（使用者、訂單、產品）。
修復熱分割區問題
透過改善分割區鍵基數來識別並解決高流量 DynamoDB 資料表中的熱分割區問題。
جرّب هذه الموجهات
幫我設計一個用於儲存使用者事件的 Cassandra 主鍵。我需要依 user_id 查詢並在日期範圍內依 event_type 篩選。我的分割區鍵��叢集欄位應該是什麼？
我有三種實體類型：Users、Orders 和 Products。設計一個使用複合鍵的單一 DynamoDB 資料表，讓我可以在一個請求中取得使用者的資料及其所有訂單。
我的 DynamoDB 資料表在某個分割區上遇到節流問題。分割區鍵是 'status'（值：'active'、'pending'、'completed'）。有什麼問題以及如何修復？
我有一個包含 Author 和 Book 資料表的關聯式綱要，透過 author_id 連接。我應該如何在 Cassandra 或 DynamoDB 中不使用連接來建模？
أفضل الممارسات
- 始終設計具有高基數的分割區鍵以避免熱分割區
- 使用反正規化在寫入時預先計算連接，而不是查詢多個資料表
- 使用���合分割區鍵（例如 USER#123#2024-01）以防止分割區超過 10GB
تجنب
- 使用低基數的分割區鍵，如 status='active' 或 gender='m'（會建立熱分割區）
- 使用「分散收集」查詢來掃描所有分割區，而不是定位特定鍵
- 將 SQL 建模模式（具有外鍵的獨立資料表）應用於 NoSQL 資料庫