docs(10_Wiki): 위키 전체 재구성 — Topic_* 폴더를 4개 카테고리로 통합 + 대규모 중복 제거
Topic_Agent/Topic_Blog/Topics/Topics_Biz/Topics_Meeting/Topics_Rag의 마크다운 지식 문서를 Topic_General/Topic_Programming/Topic_Graphic/Topic_Business 4개 카테고리로 재분류. - 중복 제거: frontmatter의 status:duplicate/merged + duplicate_of/redirect_to 필드로 자기 자신을 중복으로 선언한 리다이렉트 stub 1032개 제거, 완전 동일 내용 파일 472개 제거, 동일 파일명·다른 내용 충돌 시 더 큰(완전한) 버전만 유지(162개 제거) — 총 1639개 중복 제거. - 분류: 폴더 단위로 명확한 항목(AI_and_ML/Coding/Architecture 등 → Programming, Comfyui/Visual_Effects → Graphic, Topics_Biz/Topics_Meeting/사업 등 → Business, Poetic_Blog_Writing/창의성/Game_Design 등 → General)은 폴더 우선순위로, 나머지 혼재 폴더(Topic_Agent/Topic_Blog/Topics 루트/Thinking & Reasoning/Other/UI_UX_Assets)는 title/tags 키워드 스코어링으로 파일 단위 분류(불명확한 경우 General로 폴백). 원본 폴더명은 "From_*" 서브폴더로 보존해 추적 가능성 유지. - 최종 배치: Programming 2784 / General 1608 / Graphic 285 / Business 249 = 4926개 문서. - 에이전트 운영 상태(.astra/.agent/.obsidian/sessions/memory/_company/docs/lessons/_shared/src)는 지식 콘텐츠가 아니므로 재분류 대상에서 제외하고 원위치 유지. - Topics/Topic_email(상위 보호 폴더 Topic_email과 파일명 100% 중복) 삭제 — 보호 폴더 자체는 미변경. - 완전히 비게 된 Topic_Agent/Topic_Blog/Topics_Biz/Topics_Rag 폴더 제거.
This commit is contained in:
Antigravity Agent
@@ -0,0 +1,149 @@
|
||||
---
|
||||
id: db-sharding-strategies
|
||||
title: Sharding — 수평 분할 / 라우팅 / Resharding
|
||||
category: Coding
|
||||
status: draft
|
||||
source_trust_level: B
|
||||
verification_status: conceptual
|
||||
created_at: 2026-05-09
|
||||
updated_at: 2026-05-09
|
||||
tags: [database, sharding, scaling, vibe-coding]
|
||||
tech_stack: { language: "SQL / Postgres / Citus", applicable_to: ["Backend"] }
|
||||
applied_in: []
|
||||
aliases: [sharding, partitioning, hash sharding, range sharding, Citus, Vitess]
|
||||
---
|
||||
|
||||
# Sharding
|
||||
|
||||
> 1대 RDB 한계 (CPU/메모리/디스크) 도달. **여러 노드에 데이터 수평 분할**. Hash / Range / Lookup. **늦게, 진짜 필요할 때만** — read replica + cache + 인덱스 먼저.
|
||||
|
||||
## 📖 핵심 개념
|
||||
- Shard key: 어떤 컬럼으로 분할 (보통 user_id, tenant_id).
|
||||
- Hash sharding: hash(key) % N.
|
||||
- Range: id 1-1M = shard1, 1M-2M = shard2.
|
||||
- Lookup: 어떤 shard 인지 별도 매핑.
|
||||
- Resharding: shard 수 변경 시 데이터 이동.
|
||||
|
||||
## 💻 코드 패턴
|
||||
|
||||
### App-level sharding (가장 단순)
|
||||
```ts
|
||||
const SHARDS = [pool0, pool1, pool2, pool3];
|
||||
|
||||
function shardFor(userId: string): Pool {
|
||||
const h = murmurhash(userId);
|
||||
return SHARDS[h % SHARDS.length];
|
||||
}
|
||||
|
||||
async function getUser(id: string) {
|
||||
const db = shardFor(id);
|
||||
return db.users.find(id);
|
||||
}
|
||||
```
|
||||
|
||||
### Multi-tenant by row
|
||||
```sql
|
||||
-- 모든 테이블에 tenant_id
|
||||
CREATE TABLE orders (
|
||||
id UUID,
|
||||
tenant_id UUID NOT NULL,
|
||||
...
|
||||
PRIMARY KEY (tenant_id, id)
|
||||
);
|
||||
|
||||
CREATE INDEX orders_tenant ON orders(tenant_id);
|
||||
|
||||
-- 모든 query 에 tenant_id 필수
|
||||
SELECT * FROM orders WHERE tenant_id = $1 AND id = $2;
|
||||
```
|
||||
|
||||
RLS (Row Level Security):
|
||||
```sql
|
||||
ALTER TABLE orders ENABLE ROW LEVEL SECURITY;
|
||||
CREATE POLICY tenant_iso ON orders USING (tenant_id = current_setting('app.tenant_id')::UUID);
|
||||
```
|
||||
|
||||
### Citus (Postgres extension)
|
||||
```sql
|
||||
SELECT create_distributed_table('orders', 'tenant_id');
|
||||
-- Citus 가 hash(tenant_id) 로 자동 분산
|
||||
```
|
||||
|
||||
```sql
|
||||
-- 같은 tenant 의 join 은 같은 shard 안 — colocated
|
||||
SELECT create_distributed_table('order_items', 'tenant_id', colocate_with => 'orders');
|
||||
```
|
||||
|
||||
### Vitess (MySQL)
|
||||
- VTGate 가 query 라우팅.
|
||||
- VSchema 로 keyspace + sharding 정의.
|
||||
- Vindex 로 lookup 변환.
|
||||
- YouTube / Slack / Square 사용.
|
||||
|
||||
### MongoDB sharding
|
||||
```js
|
||||
sh.shardCollection('app.orders', { tenantId: 'hashed' });
|
||||
```
|
||||
|
||||
### Resharding (Hash → 더 많은 shard)
|
||||
**문제**: hash mod N 변경 시 모든 데이터 이동.
|
||||
|
||||
**해결**: Consistent hashing — virtual node 로 일부만 이동.
|
||||
```ts
|
||||
import { HashRing } from 'hashring';
|
||||
|
||||
const ring = new HashRing(['shard0', 'shard1', 'shard2'], 'md5', { vnodes: 256 });
|
||||
const node = ring.get(userId); // 'shard1'
|
||||
|
||||
// shard 추가
|
||||
ring.add('shard3'); // 일부만 재분배
|
||||
```
|
||||
|
||||
### Lookup table (가장 유연)
|
||||
```sql
|
||||
CREATE TABLE shard_map (
|
||||
user_id UUID PRIMARY KEY,
|
||||
shard_id INT NOT NULL
|
||||
);
|
||||
|
||||
-- 라우팅: lookup → shard 결정
|
||||
-- 조회 비용 1 hop, 단 cache.
|
||||
```
|
||||
|
||||
### Cross-shard query (피하기)
|
||||
- 같은 shard key 로 joined 데이터 colocate.
|
||||
- Cross-shard 가 필요하면 fan-out + merge.
|
||||
- Aggregate 는 분석 DB 로 따로.
|
||||
|
||||
### Hot tenant 문제
|
||||
- 한 tenant 가 너무 큼 → shard 불균등.
|
||||
- 해결: 그 tenant 만 별도 shard / sub-shard (user_id 도 같이).
|
||||
|
||||
## 🤔 의사결정 기준
|
||||
| 규모 / 상황 | 추천 |
|
||||
|---|---|
|
||||
| <1TB / <10K QPS | Sharding 불필요 — 인덱스 / replica / cache |
|
||||
| Multi-tenant SaaS | tenant_id sharding (Citus) |
|
||||
| Time-series | range sharding (월별 파티션) |
|
||||
| 균일 access | hash sharding |
|
||||
| Hot key 있음 | + sub-sharding |
|
||||
| Geo (지역별) | region 별 cluster |
|
||||
| Strong consistency | 같은 shard 안만 |
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **너무 일찍 sharding**: 운영 부담 폭증. 다른 옵션 먼저.
|
||||
- **Shard key 변경 가정**: 거의 불가능. 잘 골라야.
|
||||
- **Cross-shard transaction 자주**: 2PC 어려움. 디자인 변경.
|
||||
- **모든 query 에 shard key 누락**: scatter-gather.
|
||||
- **N → N+1 변경 못 함**: consistent hashing 또는 lookup.
|
||||
- **Hot tenant 무시**: 한 노드 OOM.
|
||||
- **No backup / restore plan**: shard 별 backup 일관성.
|
||||
|
||||
## 🤖 LLM 활용 힌트
|
||||
- 늦게 + 진짜 필요할 때.
|
||||
- Citus / Vitess 같은 매니지드 도구 가급적.
|
||||
- Tenant_id / user_id 같은 자연 shard key.
|
||||
|
||||
## 🔗 관련 문서
|
||||
- [[DB_Partitioning_Patterns]]
|
||||
- [[DB_Read_Replica_Patterns]]
|
||||
Reference in New Issue
Block a user