<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>makgol's note – 스토리지·레이크하우스</title><link>https://docs.makgol.com/data/clickhouse/storage/</link><description>Recent content in 스토리지·레이크하우스 on makgol's note</description><generator>Hugo -- gohugo.io</generator><language>ko-KR</language><copyright>© 2026 Mont</copyright><lastBuildDate>Sun, 04 Oct 2026 00:00:00 +0900</lastBuildDate><atom:link href="https://docs.makgol.com/data/clickhouse/storage/index.xml" rel="self" type="application/rss+xml"/><item><title>부록 · EKS 범용 노드와 gp3에서 잰 ClickHouse 1억 행 실측</title><link>https://docs.makgol.com/clickhouse/a1-eks-gp3-benchmark/</link><pubDate>Mon, 05 Oct 2026 00:00:00 +0900</pubDate><guid>https://docs.makgol.com/clickhouse/a1-eks-gp3-benchmark/</guid><description>
&lt;h1&gt;부록 · EKS 범용 노드와 gp3에서 잰 ClickHouse 1억 행 실측&lt;/h1&gt;&lt;p&gt;4 vCPU 범용 노드 한 대와 기본 설정 gp3 100GiB에 Kubernetes 로그 1억 행을 넣으면 적재, 압축, 쿼리에서 어떤 결과가 나올까요? atomai의 &lt;a href="https://www.atomai.click/kubernetes-docs/ko/database/01-clickhouse-on-eks"target="_blank" rel="noopener"&gt;ClickHouse on EKS 실측 벤치마크&lt;/a&gt;는 이 조건을 서버 내부 적재와 코덱·인덱스별 쿼리로 나누어 측정했습니다. 이 글의 수치는 모두 원문 보고값이며 별도로 재실행하지 않았습니다.&lt;/p&gt;</description></item><item><title>스토리지 아키텍처 — 로컬 NVMe(i7i/i8g)</title><link>https://docs.makgol.com/clickhouse/02-storage-local-nvme/</link><pubDate>Mon, 13 Jul 2026 00:00:00 +0900</pubDate><guid>https://docs.makgol.com/clickhouse/02-storage-local-nvme/</guid><description>
&lt;h1&gt;스토리지 아키텍처 — 로컬 NVMe(i7i/i8g)&lt;/h1&gt;&lt;p&gt;로컬 NVMe를 ClickHouse 데이터 디스크로 쓰면 수 GB/s의 처리량을 얻을 수 있습니다. 대신 인스턴스가 사라질 때 그 디스크도 잃습니다. 따라서 노드 크기를 고를 때는 저장할 수 있는 TB보다, 노드 한 대 분량을 다른 replica에서 복구하는 데 걸리는 시간을 계산해야 합니다.&lt;/p&gt;</description></item><item><title>로컬 NVMe 하드 유저들 — 데이터스토어 횡단 벤치마킹</title><link>https://docs.makgol.com/clickhouse/07-local-nvme-datastore-patterns/</link><pubDate>Tue, 14 Jul 2026 00:00:00 +0900</pubDate><guid>https://docs.makgol.com/clickhouse/07-local-nvme-datastore-patterns/</guid><description>
&lt;h1&gt;데이터스토어별 로컬 NVMe 운영과 복구&lt;/h1&gt;&lt;p&gt;로컬 NVMe를 데이터스토어의 주 디스크로 쓰면 노드 장애 뒤에 데이터를 다시 채우는 작업이 따라옵니다. ClickHouse만의 문제는 아닙니다. ScyllaDB는 스트리밍 속도를 개선하고, CockroachDB는 작은 노드에 데이터를 분산하도록 권하며, 일부 TiDB 사용자는 복구 시간 때문에 EBS를 검토합니다.&lt;/p&gt;</description></item><item><title>Iceberg·레이크하우스 — 테이블 포맷이 뭐고, S3 메인의 답이 되는가</title><link>https://docs.makgol.com/clickhouse/09-iceberg-lakehouse/</link><pubDate>Wed, 12 Aug 2026 00:00:00 +0900</pubDate><guid>https://docs.makgol.com/clickhouse/09-iceberg-lakehouse/</guid><description>
&lt;h1&gt;Iceberg·레이크하우스 — 테이블 포맷이 뭐고, S3 메인의 답이 되는가&lt;/h1&gt;&lt;p&gt;S3에 Parquet 파일을 쌓으면 여러 엔진이 읽을 수 있습니다. 하지만 파일을 추가하거나 교체하는 중에 어떤 파일 집합이 하나의 테이블인지 정하는 규칙이 필요합니다. Iceberg는 스냅샷, 스키마, 유효한 데이터 파일 목록을 메타데이터로 관리해 이 문제를 다룹니다.&lt;/p&gt;</description></item></channel></rss>