
목차1. B-트리 특징/장단점 2. B+트리 특징/장단점 3. 언제 B-트리가 유리할까? 4. 왜 데이터베이스는 B+트리를 쓸까? 5. 실제 사례 비교 (MySQL ↔ Redis) 6. 요약1. B-트리 특징/장단점 특징- 모든 노드(내부 + 리프)에 데이터 저장장점- 중간 노드에서 바로 데이터를 찾을 수 있어 단일 검색 속도 빠름- 메모리 사용 효율 높음 (리프만 따로 두지 않음)- 작은 데이터셋이나 메모리 기반 구조에 적합단점- 리프 노드들이 연결되어 있지 않아 범위 검색 비효율적2. B+트리 특징/장단점특징- 내부 노드는 인덱스만, 데이터는 리프 노드에만 저장- 리프 노드들이 연결 리스트로 연결됨장점- 범위 검색 / 순차 탐색 최적화- 내부 노드에 더 많은 키 저장 가능 → 트리 높이가 낮아짐- 대..

목차1. 문제 배경: Redis가 죽은 이유2. 배경 지식: Redis의 BGSAVE와 Copy-on-Write3. 실험 목적: Copy-on-Write가 실제로 OOM을 유발하는가?4. 실험 환경: Docker 기반 Redis 컨테이너 구성5. 실험 과정: Copy-on-Write 상황 유발 및 메모리 관측6. 실험 결과: Copy-on-Write로 인한 OOM은 실제로 발생했다7. 실험을 통해 알게 된 것8. 결론9. Github 링크1. 문제 배경: Redis가 죽은 이유Redis가 예고 없이 종료될 수 있습니다.Redis의 maxmemory는 6GB로 설정되어 있었고,컨테이너의 메모리 제한은 7GB였으며,메모리 사용량이 한계에 가까운 시점에서 BGSAVE가 실행되었고,그 결과 Redis가 Out ..
- Total
- Today
- Yesterday
- implicit tiling
- z-order
- transferto()
- .b3dm
- content availability
- cpu i/o
- append only
- event streaming
- 오차 최소화
- the unix timesharing system
- child subtree availability
- b3dm
- implict titling
- tile availability
- event srource
- morton order
- zero-copy
- z-order curve
- sendfile()
- user space
- redis bgsave
- Live BMW
- redis
- explicit tiling
- Kafka
- 3d tiles 1.0
- 머신러닝
- Cesium
- bgsave
- kernel space
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
31 |