행운개발자의 기술블로그

파일을 생성하거나 파일을 전송하면 이 파일은 physical disk에서 특정 영역을 차지한다. 그리고 이 파일을 특정한 file type을 가진다TypeSymbolDescriptionNormal-Normal fileDirectorydNormal directoryHard link-Additional name for existing fileSymbolic linklShortcut to a file or directorySocketsPass data between 2 processesNamed pipepLike sockets, user can't work directly with itCharacter devicecProcesses character hardware communicationBlock devic..

GFS 논문에는 아래와 같은 내용이 나온다. Linux의 buffer cache를 믿고 file data를 cache하지 않는다고 한다.Neither the client nor the chunkserver caches file data. Client caches offer little benefit because most applications stream through huge files or have working sets too large to be cached. Not having them simplifies the client and the overall system by eliminating cache coherence issues. (Clients do cache metadata, howev..

File Storage와 Object Storage를 조금이나마 사용해보면서 Storage의 성능 측정을 어떤 기준으로 해야하는지 불명확하게 알고 있었다. 우연히 접한 RocksDB의 Possibilities of Performance Bottlenecks에서 관련된 내용을 발견해서 정리해본다.System Metrics들어가기에 앞서.. Write는 Bandwidth, READ는 IOPs로 구분해서 접근하는 것부터 신선하다..!Disk Write Bandwidth : SSD drive가 허용하는 것 이상으로 write를 시도할 수 있다. 이 때에는 주로 compaction에서 문제가 발생한 것일 수 있다. 무리한 write는 read까지 느리게 만들 수 있다. write가 read까지 영향을 줄 수 있는..

개략적인 규모 추정구글 엔지니어 Jeff Dean에 따르면 개략적인 규모 추정이란 보편적으로 통용되는 성능 수치상에서 사고 실험을 행하여 추정치를 계산하는 행위로서, 어떤 설계가 요구사항에 부합할 것인지 확인해보는 과정을 이야기합니다.2의 제곱수분산 시스템에서 사용하는 데이터의 양은 크게 커질 수 있으나, 데이터 볼륨의 단위를 2의 제곱수로 어떻게 표현하는지 알아야 합니다.위와 같은 제곱수에 대한 어느정도의 감을 머릿속에 집어넣어두는 것은 꽤 중요합니다.예를 들어, 이전 포스팅에서 GFS에서 가정한 Individual STREAMING READ operation size는 대략 수백 KB ~ 1MB라고 했습니다."넉넉 잡아 1MB라고 생각하고 2^20정도이구나" 정도의 숫자에 대한 감을 기억해두면 개력적..

IntroductionGFS에서는 시스템 디자인을 할 때 기존의 방식을 재검토했던 4가지를 소개합니다.First, component failures are the norm rather than the exception.File System은 비싸지 않은 수많은 머신에서 수많은 Client의 요청을 받기 때문에 시스템 결함은 일반적인 현상이다.Second, files are huge by traditional standards. Multi-GB files are common.여러개의 객체를 다루어야할 때, 작은 여러개의 파일로 나누어서 관리하기보다, 일반적으로 하나의 큰 파일을 생성해서 관리한다.Third, most files are mutated by appending new data rather tha..

What is CAP Theorem분산 시스템을 설계할 때에는 CAP 정리를 이해하고 있어야 한다. CAP 정리는 일관성(Consistency), 가용성(Availability), 파티션 감내(Partition Tolerance)라는 세 가지 요구사항을 동시에 만족하는 분산 시스템을 설계하는 것을 불가능하다는 정리다. 우선 각 요구사항의 의미부터 명확히 정리하고 넘어가자.일관성 Consistency : 분산 시스템에 접속하는 모든 클라이언트는 어떤 노드에 접속했느냐에 관계없이 언제나 같은 데이터를 보게 되어야 한다.가용성 Availability : 분산 시스템에 접속하는 클라이언트는 일부 노드에 장애가 발생하더라도 항상 응답을 받을 수 있어야 한다.파티션 감내 Partion Tolerance : 파티션은..

예시 코드는 깃허브에서 확인하실 수 있습니다 https://github.com/hwanseok-dev/lucky-developer-tutorial/tree/main/io.lucky.java.thread Java Thread Tutorial STEP 1. 메인 쓰레드, 백그라운드 쓰레드 자바 프로그램을 실행하면 쓰레드가 항상 실행됩니다. GC 등을 위해서 백그라운드에서 실행되는 쓰레드도 존재합니다. class HelloWorld { // main 메서드를 실행시키는 하나의 쓰레드가 반드시 동작함 public static void main(String[] args) { System.out.println("Hello World"); } // GC 등 백그라운드 쓰레드도 함께 실행됨 /** * Hello Wor..

아키텍처에 관심을 가지게된 이유 결론적으로는 개발하는 프로젝트의 복잡도가 증가하면서 수정하는 비용이 커졌기 때문입니다. 비즈니스 요구사항이 점점 복잡해지면서 사용자 관점의 유즈케이스를 코드만 보고 파악하기 어려워졌습니다. 기능 하나를 수정하면 영향을 받는 코드가 많아서 수정하기 어렵기도 하고 수정한 결과에 대한 심리적 안정감도 많이 떨어졌습니다. “수정하기 쉽도록 프로젝트를 구성하려면 어떻게 해야할까?”라는 의문에 답을 찾기 위해서 클린 아키텍처를 떠올렸고, 구체적인 예제 코드를 제공한다는 이야기를 듣고 책 ‘만들면서 배우는 클린 아키텍처’를 읽어보게되었습니다. 이번 글은 책 ‘만들면서 배우는 클린 아키텍처’를 2번 정독하고, 토이프로젝트를 직접 진행해보면서 배우고 느낀 것들에 대해서 이야기합니다. 수정..

2장 데이터 웨어하우스만이 아닌 데이터 플랫폼인 이유 요약 정형 데이터와 반정형 데이터를 모두 대응해야하는 경우, 데이터 플랫폼을 구성해야 한다 웨어하우스방식은 수집된 데이터를 바로 웨어하스에 저장하지만, 플랫폼 방식은 블롭 스토리지와 데이터브릭스를 사용해서 수집, 임시저장, 처리의 계층을 분리하였다 웨어하우스 방식과 달리 플랫폼 방식은 입력 스키마 변경에 자유로울 수 있다 웨어하우스 방식과 달리 플랫폼 방식은 JSON과 같은 반정형 데이터가 분석 될 때에도 모듈화, 테스트, 유지보수성을 제공할 수 있다 플랫폼 방식에서 수집, 임지 저장, 처리의 계층을 분리한 덕분에 스키마 변경에 대해서 더욱 자유로울 수 있고, 스파크와 같은 분산 데이터 처리 엔진을 사용할 수 있게 된다 데이터 플랫폼을 사용하는 사용자..

0.0. 요약 데이터 분석의 목적 : 비즈니스 행위의 방향을 결정하기 위함 데이터 웨어하우스 + 데이터 레이크 = 데이터 플랫폼 데이터 플랫폼의 3가지 문제점 : 규모, 다양성, 속도 데이터 웨어하우스 → 클라우드 데이터 플랫폼으로 전환 수집 , 스토리지 , 처리, 서비스 계층의 분리 실시간 스프림 데이터와 배치 데이터의 분리 서비스 계층의 3가지 역할 비즈니스 부서 : 보고서, 대시보드, 가공된 데이터 분석가 : SQL, (가공된) 정형 데이터 개발자 : 익숙한 프로그래밍 언어, 원시 데이터 조회 공부할 개념 수집 계층 : 카프카 커넥트 (플러그앤 플레이 수집 기능) 처리 계층 : 스파크(잘 알려진 파일 형식 파싱) 수집 계층 클라우드 데이터 웨어하우스 구글 : 빅쿼리 AWS : 레드시프트 애저 : 시..