서버에서 9조 레코드 아키텍처

표준 서버에서 트리리온 레코드를 위한 확장 가능한 파일 아키텍처

주소는 레코드보다 앞서 있다: 은하계와 항성 좌표로 구성된 64비트 경로가 키 EHO-7K3F-91QM-2X를 형성한다. 각 은하는 723MB 크기의 희박한 파일이며(300만 × 256바이트), 실제로 1%만 채워져 있을 경우 약 7MB에 불과하다. 리눅스는 빈 공간을 디스크에 쓰지 않는다.

디렉터리 계층은 레벨당 최대 10만 개의 파일까지 제한된다:

galaxies/
  AA/
  AB/
  ...

1,296개의 섹터에 각각 약 2,300개의 은하가 포함된다. 내부에서는 Z-순서 인코딩(Morton 곡선)을 사용해 x/y 비트를 혼합하여 접근 지역성을 극대화하고, 검색 횟수를 최소화한다.

레코드 구조 및 보안

항성은 오프셋으로 고정되며, 업데이트는 동일한 위치에 수행된다. 비어 있는 슬롯은 0으로 채우고 CRC32 검증을 통해 무결성을 보장한다. 파일은 필요할 때 생성되며 영원히 유지된다.

키: GUID (2¹²² 공간), 좌표와 함께 Argon2(GUID + 좌표)로 저장된다. 구조는 256바이트이다:

• 1바이트 플래그 (쓰기 중인 상태)
• 32바이트 Argon2 해시
• 219바이트 데이터
• 4바이트 CRC32

잠금 없이 키 기반으로 접근한다. GUID를 잃으면 레코드도 소실된다.

확장성: 접두사가 노드를 결정한다. 합의, 트랜잭션, 리더 선출이 필요 없다.

우주 시각화 및 최적화

우주 지도(1170×2532): 픽셀 = 은하, 밝기 = 밀도 (stat() / 723MB). NVMe에서 300만 번의 stat() 호출은 10~30초 소요 — 백그라운드에서 PNG 이미지 생성.

은하 지도: 723MB 순차 읽기(_NVMe 기준 240ms_) 또는 희박한 경우 7MB(2~3ms) 처리. Google Maps처럼 타일 렌더링: 섹터별 무효화, 검은 타일은 정적이다.

Project "ECHO"와 비교

| 요소 | "ECHO" | 새로운 아키텍처 |

|--------|--------|-------------------|

| 규모 | 2.5억 | 9조 (36개 은하계 분량) |

| 인덱스 | 메모리 내 JSON | 좌표 = 주소 |

| 구조 | 수동 | Morton 곡선 |

| 인증 | PIN | GUID + Argon2 |

핵심 포인트

• 좌표 기반 주소 체계로 인덱스와 레지스트리가 필요 없음.
• 희박한 파일 + Z-순서로 낮은 밀도에서도 O(1) 접근 가능.
• 100대 장치만으로 트리리온 레코드를 관리할 수 있음.
• CRC32 + WRITING 비트로 잠금 없이 무결성 보장.
• stat()과 타일을 통한 시각화는 은하 단위까지 확장 가능.

— Editorial Team