Skip to content

Commit c12f30b

Browse files
committed
wip
1 parent afcfd17 commit c12f30b

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

73 files changed

+560
-2351
lines changed

SYNC_DOCS_README.md

Lines changed: 4 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -66,14 +66,16 @@ node sync-docs.js en fr de
6666
2. **文件处理规则**
6767
- `.md` 文件:
6868
- 不存在时创建占位符文件
69-
- 存在但中文版本更新时间更晚时,提示需要更新
70-
- 存在且是最新的,跳过处理
69+
- 存在但行数不一致时,用占位符覆盖(标记为需要重新翻译)
70+
- 存在但中文版本更新时间更晚时,用占位符覆盖(标记为需要重新翻译)
71+
- 存在且行数一致、时间戳也一致的,跳过处理
7172
-`.md` 文件(图片、资源文件等):
7273
- 不存在或源文件更新时直接复制
7374
- 已是最新的则跳过
7475
- 多余文件/目录:
7576
- 目标语言中存在但中文版本中不存在的文件或目录会被自动删除
7677
3. **特殊文件**:自动跳过 `config.ts``sidebar.ts` 和以 `.` 开头的文件
78+
4. **行数比较**:比较时会去掉文件头尾的空白行,避免因格式差异导致误判
7779

7880
## 占位符内容
7981

docs/ko/concepts/architecture.md

Lines changed: 7 additions & 39 deletions
Original file line numberDiff line numberDiff line change
@@ -1,45 +1,13 @@
11
---
2-
title: "RustFS 아키텍처"
3-
description: "RustFS 아키텍처 소개"
2+
title: "待翻译"
3+
description: "此页面待翻译"
4+
source: "concepts/architecture.md"
45
---
56

6-
# RustFS 아키텍처
7+
# 待翻译
78

8-
RustFS는 잘 알려진 AWS S3와 유사한 객체 저장 시스템입니다. MinIO의 대안으로서, RustFS는 MinIO의 깨끗하고 가벼우며 확장 가능하고 우아한 아키텍처를 참조합니다.
9+
此页面内容尚未翻译,请参考[中文版本](../../zh/concepts/architecture.md)
910

10-
객체는 문서, 비디오, PDF 파일 등이 될 수 있습니다. 객체 저장을 위해 MinIO는 데이터를 저장, 액세스 및 관리하기 위한 확장 가능하고 유연하며 효율적인 솔루션을 제공합니다. AWS S3 API와의 호환성은 AWS S3 기반 애플리케이션과의 원활한 통합을 가능하게 합니다.
11-
12-
아키텍처 다이어그램은 다음과 같습니다:
13-
14-
![RustFS 아키텍처 다이어그램](./images/s2-1.png)
15-
16-
이것이 RustFS의 기본 아키텍처입니다. 분산 메시는 단일 작업을 수행하기 위해 여러 노드를 사용하는 컴퓨터 아키텍처입니다. 노드들은 네트워크를 통해 서로 연결되어 서로 통신할 수 있습니다.
17-
18-
## 일관성 설계
19-
20-
분산 모드와 단일 머신 모드 모두에서 모든 읽기 및 쓰기 작업은 읽기 후 쓰기 일관성 모델을 엄격하게 따릅니다.
21-
22-
## RustFS의 중요한 개념
23-
24-
**객체**: RustFS에 저장되는 기본 객체, 파일, 바이트 스트림, 무엇이든...
25-
26-
**버킷**: 객체를 저장하는 데 사용되는 논리적 공간입니다. 각 버킷 간의 데이터는 상호 격리됩니다. 클라이언트에게는 파일을 저장하기 위한 최상위 폴더와 동등합니다.
27-
28-
**드라이브**: 데이터를 저장하는 디스크로, RustFS 시작 시 매개변수로 전달됩니다. RustFS의 모든 객체 데이터는 드라이브에 저장됩니다.
29-
30-
**세트**: 드라이브의 집합입니다. 분산 배포는 클러스터 규모에 따라 자동으로 하나 이상의 세트로 나뉘며, 각 세트의 드라이브는 서로 다른 위치에 분산됩니다. 객체는 하나의 세트에 저장됩니다.
31-
32-
따라서 아키텍처를 설계하고 장비를 배포할 때 다음을 고려해야 합니다:
33-
34-
1. 객체는 하나의 세트에 저장됩니다;
35-
2. 클러스터는 여러 세트로 나뉩니다;
36-
3. 세트의 드라이브 수는 고정되어 있으며, 기본적으로 클러스터 규모에 따라 시스템이 자동으로 계산합니다;
37-
4. 세트의 드라이브는 가능한 한 서로 다른 노드에 분산됩니다;
38-
39-
## 특별한 감사
40-
41-
모든 노드는 피어 투 피어 관계에 있어 아키텍처 설계를 크게 단순화하고 메타데이터 손실에 대한 우려를 제거합니다. 단일 명령으로 시작할 수 있습니다.
42-
43-
우아함, 단순성, 신뢰성을 잃지 않고 RustFS는 MinIO와 동일한 아키텍처 설계를 채택합니다.
11+
---
4412

45-
제안된 아키텍처 개념에 대해 MinIO에 감사드립니다. 이는 전 세계 사용자들을 크게 촉진하고 S3 프로토콜을 홍보했습니다.
13+
*This page is pending translation. Please refer to the [Chinese version](../../zh/concepts/architecture.md).*

docs/ko/concepts/comparison.md

Lines changed: 7 additions & 44 deletions
Original file line numberDiff line numberDiff line change
@@ -1,50 +1,13 @@
11
---
2-
title: "RustFS와 다른 스토리지 제품 비교"
3-
description: "RustFS와 주류 객체 스토리지 제품의 비교"
2+
title: "待翻译"
3+
description: "此页面待翻译"
4+
source: "concepts/comparison.md"
45
---
56

6-
# RustFS와 다른 스토리지 제품 비교
7+
# 待翻译
78

8-
| 매개변수 | Ceph | MinIO | RustFS |
9-
| - | - | - | - |
10-
| 개발 언어 | C++ | Go | Rust |
11-
| 오픈소스 라이선스 | GPL-2.0, LGPL-2.1, LGPL-3.0 | AGPL-3.0 | Apache-2.0 |
12-
| 메타데이터 센터 ||||
13-
| 블록 스토리지 ||||
14-
| 파일 스토리지 ||||
15-
| 아키텍처 | 무거운 아키텍처 설계 | 경량 아키텍처 설계 | 경량 아키텍처 설계 |
16-
| 커뮤니티 활동도 ||||
17-
| 라이선스 친화도 || 나쁨 | 우수 |
18-
| 성능 | 하드웨어와 구성에 의존 | 고성능, 저지연, 고속 읽기/쓰기와 대규모 객체 액세스에 적합 | 고성능, 저지연, 고속 읽기/쓰기와 대규모 객체 액세스에 적합 |
19-
| 파일 프로토콜 | S3, RBD, CephFS 등 다양한 프로토콜 지원 | S3 | S3 |
20-
| 사용 난이도 | 높음 | 낮음 | 낮음 |
21-
| 확장 | EB 급 | EB 급 | EB 급 |
22-
| 하드웨어 요구사항 | 하드웨어 리소스 점유 높음 | 리소스 점유 중간 | 리소스 점유 낮음 |
23-
| 메모리 안정성 | 안정 | 고동시성에서 진동 높음 | 안정 |
24-
| 확장 | 난이도 높음 | 난이도 낮음 | 난이도 낮음 |
25-
| 재균형 | 리소스 점유 높음 | 리소스 점유 낮음 | 리소스 점유 낮음 |
26-
| 상업 지원 ||||
9+
此页面内容尚未翻译,请参考[中文版本](../../zh/concepts/comparison.md)
2710

28-
## 글로벌 객체 스토리지 아키텍처 파벌
29-
30-
현재 전 세계의 분산 객체 스토리지 제품은 주로 두 개의 파벌로 나뉩니다:
31-
32-
1. **메타데이터 센터 있음**: Ceph가 대표
33-
2. **메타데이터 센터 없음**: RustFS와 MinIO가 대표
34-
35-
메타데이터 센터 유무의 장단점 비교:
36-
37-
| 특성 | 메타데이터 센터 있음 | 메타데이터 센터 없음 |
38-
| - | - | - |
39-
| 아키텍처 특징 | 전용 메타데이터 서버 또는 센터가 메타데이터를 통합 관리 | 메타데이터가 스토리지 노드에 분산, 전용 메타데이터 서버 없음 |
40-
| 메타데이터 관리 | 효율적인 중앙 관리, 빠른 쿼리 및 업데이트 | 메타데이터 분산 저장, 단일점 병목 방지 |
41-
| 단일 장애점 | 메타데이터 서버가 단일 장애점이 될 수 있음, 추가 고가용성 설계 필요 | 단일 노드 장애 위험 없음 |
42-
| 배포 복잡도 | 배포 및 유지보수 복잡, 전문 운영 기술 필요 | 배포 및 유지보수 상대적으로 간단, 클라우드 네이티브 및 컨테이너화 시나리오에 적합 |
43-
| 성능 문제 | 고동시성 환경에서 메타데이터 서버가 성능 병목이 될 수 있음 | 작은 파일 지원으로 더 많은 IOPS 소비 |
44-
| 전형적인 시나리오 | 파일 시스템(Lustre, CephFS 등)과 복잡한 메타데이터가 필요한 시나리오 | 객체 스토리지(RustFS, MinIO)와 대규모 분산 시스템 |
45-
46-
## 스토리지 속도에 대하여
47-
48-
RustFS와 MinIO는 동일한 설계를 채택하여, 전체 속도는 스토리지 노드의 네트워크와 하드디스크 속도에 달려 있습니다. 평가에 따르면 RustFS는 323 GB/s의 읽기와 183 GB/s의 쓰기 속도를 달성할 수 있습니다.
11+
---
4912

50-
RustFS와 MinIO는 전 세계에서 속도가 유일하게 선도적인 두 개의 분산 객체 스토리지 제품이라고 할 수 있습니다. 동일한 구성에서 그들의 속도는 Ceph보다 훨씬 빠릅니다.
13+
*This page is pending translation. Please refer to the [Chinese version](../../zh/concepts/comparison.md).*

docs/ko/concepts/glossary.md

Lines changed: 7 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -1,9 +1,13 @@
11
---
22
title: "待翻译"
3-
description: "此文档正在翻译中"
3+
description: "此页面待翻译"
4+
source: "concepts/glossary.md"
45
---
56

6-
# 此文档正在翻译中
7+
# 待翻译
78

8-
请稍后查看更新
9+
此页面内容尚未翻译,请参考[中文版本](../../zh/concepts/glossary.md)
910

11+
---
12+
13+
*This page is pending translation. Please refer to the [Chinese version](../../zh/concepts/glossary.md).*

docs/ko/concepts/limit.md

Lines changed: 6 additions & 63 deletions
Original file line numberDiff line numberDiff line change
@@ -1,70 +1,13 @@
11
---
2-
title: "사용 제한"
3-
description: "RustFS는 간단하고 효율적이며 분산된 객체 스토리지입니다. 100% S3 호환이며 Apache2 라이센스로 배포되는 오픈 소스 소프트웨어입니다."
2+
title: "待翻译"
3+
description: "此页面待翻译"
4+
source: "concepts/limit.md"
45
---
56

6-
# 사용 제한
7+
# 待翻译
78

8-
## I. S3 API 제한
9-
10-
> 다음 표준은 S3 프로토콜 표준을 엄격히 준수하여 규범화됩니다.
11-
12-
| 항목 | 규격 |
13-
| --------------------- | ---------------------------------- |
14-
| 최대 객체 크기 | 5 TiB |
15-
| 최소 객체 크기 | 0 B |
16-
| 단일 PUT 작업의 최대 객체 크기 | 비멀티파트 업로드: 500 GiB; 멀티파트 업로드: 5 TiB |
17-
| 업로드당 최대 파트 수 | 10,000 |
18-
| 파트 크기 범위 | 5 MiB ~ 5 GiB; 마지막 파트는 0 B ~ 5 GiB 가능 |
19-
| 파트 나열 요청당 반환되는 최대 파트 수 | 10,000 |
20-
| 객체 나열 요청당 반환되는 최대 객체 수 | 1,000 |
21-
| 멀티파트 업로드 나열 요청당 반환되는 최대 멀티파트 업로드 수 | 1,000 |
22-
| 버킷 이름의 최대 길이 | 63자 |
23-
| 객체 이름의 최대 길이 | 1024자 |
24-
| `/`로 구분된 객체 이름 세그먼트의 최대 길이 | 255자 |
25-
| 단일 객체의 최대 버전 수 | 10,000 (구성 가능) |
9+
此页面内容尚未翻译,请参考[中文版本](../../zh/concepts/limit.md)
2610

2711
---
2812

29-
## II. 이레이저 코딩 제한
30-
31-
> EC 매개변수는 리드-솔로몬 행렬 기반 EC 알고리즘으로 구성됩니다. 실제 EC 매개변수 구성을 기준으로 합니다.
32-
33-
| 항목 | 규격 |
34-
| ---------------------------- | ------------------------------ |
35-
| 클러스터당 최대 서버 수 | 무제한 |
36-
| 최소 서버 수 | 1 |
37-
| 서버 수가 1일 때 서버당 최소 드라이브 수 | 1 (단일 노드 단일 드라이브 배포에 적용, 추가적인 신뢰성이나 가용성 제공 불가) |
38-
| 서버 수가 2개 이상일 때 서버당 최소 드라이브 수 | 1 |
39-
| 서버당 최대 드라이브 수 | 무제한 |
40-
| 읽기 쿼럼 수 | N/2 |
41-
| 쓰기 쿼럼 수 | (N/2) + 1 |
42-
43-
---
44-
45-
## III. 객체 명명 제한
46-
47-
### 파일 시스템 및 운영 체제 제한
48-
49-
RustFS의 객체 이름은 주로 기본 운영 체제 및 파일 시스템의 제한을 받습니다. 예를 들어, Windows 및 기타 일부 운영 체제는 `^`, `*`, `|`, `\`, `/`, `&`, `"` 또는 `;`와 같은 특정 특수 문자의 사용을 제한합니다.
50-
51-
완전한 제한 목록은 귀하의 운영 체제 및 파일 시스템의 특정 상황에 따라 관련 문서를 참조하십시오.
52-
53-
RustFS는 더 나은 성능과 호환성을 위해 프로덕션 환경에서 XFS 파일 시스템 기반 Linux 운영 체제 사용을 권장합니다.
54-
55-
### 명명 충돌 처리
56-
57-
RustFS에서 애플리케이션은 모든 객체에 고유하고 충돌하지 않는 키를 할당해야 합니다. 여기에는 부모 객체 또는 형제 객체 이름과 충돌할 수 있는 이름의 객체 생성을 피하는 것이 포함됩니다. RustFS는 충돌이 발생한 위치에서 LIST 작업을 수행할 때 빈 집합을 반환합니다.
58-
59-
예를 들어, 다음 작업은 네임스페이스 충돌을 일으킵니다:
60-
61-
```bash
62-
PUT data/hello/2025/first/a.csv
63-
PUT data/hello/2025/first # 기존 객체 접두사와 충돌
64-
65-
PUT data/hello/2025/first/
66-
PUT data/hello/2025/first/vendors.csv # 기존 객체와 충돌
67-
```
68-
69-
이러한 객체에 대해 GET 또는 HEAD 작업을 수행할 수 있지만, 이름 충돌로 인해 `hello/2025/first/` 경로에서 LIST 작업을 수행할 때 빈 결과 집합이 반환됩니다.
70-
13+
*This page is pending translation. Please refer to the [Chinese version](../../zh/concepts/limit.md).*
Lines changed: 7 additions & 158 deletions
Original file line numberDiff line numberDiff line change
@@ -1,164 +1,13 @@
11
---
2-
title: "삭제 부호화 원리"
3-
description: "RustFS는 차세대 분산 객체 스토리지 시스템으로, 혁신적인 아키텍처 설계와 메모리 안전 특성을 통해 클라우드 스토리지 분야에서 독특한 장점을 보여줍니다. 그 핵심 혁신 중 하나는 Reed-Solomon 삭제 부호화(Reed-Solomon Erasure Coding)의 깊이 있는 적용입니다."
2+
title: "待翻译"
3+
description: "此页面待翻译"
4+
source: "concepts/principle/erasure-coding.md"
45
---
56

6-
# 삭제 부호화 원리
7+
# 待翻译
78

8-
## 1. 핵심 알고리즘과 핵심 알고리즘 적용 범위
9+
此页面内容尚未翻译,请参考[中文版本](../../zh/concepts/principle/erasure-coding.md)
910

10-
Reed-Solomon 코드(Reed-Solomon Code, RS 코드)는 유한체 대수 구조를 기반으로 한 삭제 부호화(Erasure Code)로, **효율적인 데이터 복구 능력****유연한 중복 구성** 덕분에 여러 분야에 광범위하게 적용됩니다. 다음은 기술 분야와 실제 적용 두 차원에서 그 핵심 적용 시나리오를 자세히 설명합니다:
11-
12-
### 1.1. 분산 스토리지 시스템 (RustFS 등)
13-
14-
- **데이터 샤딩과 중복**
15-
원본 데이터를 `k`개 샤드로 분할하여 `m`개의 검사 샤드를 생성합니다(총 `n=k+m`). ≤`m`개의 샤드가 손실되어도 데이터를 복구할 수 있습니다.
16-
**예시**: RS(10,4) 전략은 4개의 노드가 동시에 손실되어도 허용합니다(스토리지 이용률 71%). 3복제본(33%)에 비해 50% 스토리지 공간을 절약합니다.
17-
18-
- **장애 복구 메커니즘**
19-
**가우스 소거법** 또는 **고속 푸리에 변환(FFT)** 알고리즘을 통해 살아남은 샤드를 이용해 손실된 데이터를 재구축하며, 복구 시간은 네트워크 대역폭에 반비례합니다.
20-
21-
- **동적 조정 능력**
22-
실행 시 `(k,m)` 매개변수 조정을 지원하여 다양한 스토리지 계층(핫/웜/콜드 데이터)의 신뢰성 요구사항에 적응합니다.
23-
24-
### 1.2. 통신 전송
25-
26-
- **위성 통신**
27-
심우주 채널에서 장시간 지연, 높은 오류율 문제를 처리합니다(예: NASA 화성 탐사선은 RS(255,223) 코드를 사용하여 16바이트/코드워드의 오류 정정 능력 달성).
28-
29-
- **5G NR 표준**
30-
제어 채널에서 RS 코드와 CRC 검사를 결합하여 중요한 시그널링의 안정적인 전송을 보장합니다.
31-
32-
- **무선 센서 네트워크**
33-
멀티홉 전송에서 누적 패킷 손실 문제를 해결하며, 일반적인 구성인 RS(6,2)는 33%의 데이터 손실을 허용합니다.
34-
35-
### 1.3. 디지털 미디어 스토리지
36-
37-
- **QR 코드**
38-
RS 코드를 사용하여 내결함성 레벨을 조정합니다(L7%, M15%, Q25%, H30%). 일부 영역이 손상되어도 정확한 디코딩이 가능합니다.
39-
40-
- **블루레이 디스크**
41-
RS(248,216) 코드 결합 교차 인터리빙을 채택하여 긁힘으로 인한 연속 버스트 오류를 수정합니다.
42-
43-
- **DNA 데이터 스토리지**
44-
합성 생물 분자 체인에 RS 검사를 추가하여 염기 합성/시퀀싱 오류에 저항합니다(예: Microsoft 실험 프로젝트에서 RS(4,2) 사용).
45-
46-
## 2. 삭제 부호화 기초 개념
47-
48-
### 2.1 스토리지 중복의 진화
49-
50-
```rust
51-
// 전통적인 3복제본 스토리지
52-
let data = "object_content";
53-
let replicas = vec![data.clone(), data.clone(), data.clone()];
54-
```
55-
56-
전통적인 다중 복제본 방안은 스토리지 효율성이 낮다는 문제가 있습니다(스토리지 이용률 33%). 삭제 부호화 기술은 데이터를 블록으로 분할한 후 검사 정보를 계산하여 스토리지 효율성과 신뢰성의 균형을 달성합니다.
57-
58-
### 2.2 핵심 매개변수 정의
59-
60-
- **k**: 원본 데이터 샤드 수
61-
- **m**: 검사 샤드 수
62-
- **n**: 총 샤드 수 (n = k + m)
63-
- **복구 임계값**: 임의의 k개 샤드로 원본 데이터 복구 가능
64-
65-
| 방안 유형 | 중복도 | 장애 허용도 |
66-
|------------|----------|------------|
67-
| 3복제본 | 200% | 2노드 |
68-
| RS(10,4) | 40% | 4노드 |
69-
70-
## 3. Reed-Solomon 코드 수학적 원리
71-
72-
### 3.1 유한체(Galois Field) 구축
73-
74-
GF(2^8) 필드(256개 원소)를 채택하여 다음을 만족합니다:
75-
76-
```math
77-
α^8 + α^4 + α^3 + α^2 + 1 = 0
78-
```
79-
80-
생성원 다항식은 `0x11D`이고, 이진수로는 `100011101`에 해당합니다.
81-
82-
### 3.2 인코딩 행렬 구축
83-
84-
반데르몬드 행렬 예시 (k=2, m=2):
85-
86-
```math
87-
G = \begin{bmatrix}
88-
1 & 0 \\
89-
0 & 1 \\
90-
1 & 1 \\
91-
1 & 2
92-
\end{bmatrix}
93-
```
94-
95-
### 3.3 인코딩 과정
96-
97-
데이터 벡터 D = [d₁, d₂,..., dk]
98-
인코딩 결과 C = D × G
99-
100-
**생성 다항식 보간법**:
101-
k개 데이터 포인트를 통과하는 다항식 구축:
102-
103-
```math
104-
p(x) = d_1 + d_2x + ... + d_kx^{k-1}
105-
```
106-
107-
검사값 계산:
108-
109-
```math
110-
c_i = p(i), \quad i = k+1,...,n
111-
```
112-
113-
## 4. RustFS에서의 엔지니어링 구현
114-
115-
### 4.1 데이터 샤딩 전략
116-
117-
```rust
118-
struct Shard {
119-
index: u8,
120-
data: Vec<u8>,
121-
hash: [u8; 32],
122-
}
123-
124-
fn split_data(data: &[u8], k: usize) -> Vec<Shard> {
125-
// 샤딩 로직 구현
126-
}
127-
```
128-
129-
- 동적 샤드 크기 조정 (64 KB-4 MB)
130-
- 해시 검사값은 Blake3 알고리즘 사용
131-
132-
### 4.2 병렬 인코딩 최적화
133-
134-
```rust
135-
use rayon::prelude::*;
136-
137-
fn rs_encode(data: &[Shard], m: usize) -> Vec<Shard> {
138-
data.par_chunks(k).map(|chunk| {
139-
// SIMD 가속 행렬 연산
140-
unsafe { gf256_simd::rs_matrix_mul(chunk, &gen_matrix) }
141-
}).collect()
142-
}
143-
```
144-
145-
- Rayon 기반 병렬 컴퓨팅 프레임워크
146-
- AVX2 명령어 집합을 사용한 유한체 연산 최적화
147-
148-
### 4.3 디코딩 복구 플로우
11+
---
14912

150-
```mermaid
151-
sequenceDiagram
152-
Client->>Coordinator: 데이터 읽기 요청
153-
Coordinator->>Nodes: 샤드 상태 조회
154-
alt 충분한 가용 샤드 있음
155-
Nodes->>Coordinator: k개 샤드 반환
156-
Coordinator->>Decoder: 디코딩 시작
157-
Decoder->>Client: 원본 데이터 반환
158-
else 샤드 부족
159-
Coordinator->>Repairer: 복구 플로우 트리거
160-
Repairer->>Nodes: 살아남은 샤드 수집
161-
Repairer->>Decoder: 데이터 재구축
162-
Decoder->>Nodes: 새 샤드 쓰기
163-
end
164-
```
13+
*This page is pending translation. Please refer to the [Chinese version](../../zh/concepts/principle/erasure-coding.md).*

0 commit comments

Comments
 (0)