재미있게 살자~

Readings in Database Systems, 5th edition

Bart — Tue, 8 Dec 2015 10:03:51 +0900

http://www.redbook.io/

Readings in Database Systems는 M. Stonebraker가 87년부터 정리해왔던 DB 분야 중요 논문 모음집으로,

일명 레드북으로 불려지는, 대학원 수업 보조재로 주로 활용되는 책입니다.

이번에 새로 5th ed.이 나왔네요.

새 집필진에는 Stanford에 새로 합류한 tx 분야의 신성 Peter Bailis 박사가 참여

(라 쓰고, 잡일좀 하라고 두 대가들한테 쪼여 참여한듯한...)

그런데 방식이 좀 바뀌었네요.

예전에는 논문 묶음으로 보면 되었는데, 간단하게 요약식으로...

그나저나 집필진들끼리도 의견 통일이 안된 글이 있다는데...

2015년을 보내며

Bart — Mon, 7 Dec 2015 21:01:27 +0900

블로그를 쉰지도 거의 3년이 다 되어 간다.

블로그를 이렇게 오래 쉰 이유가 몇가지가 있었다.

하나는 이직으로 인해 내가 하던 분야를 오래도록 손댈 여력이 없었던 이유가 첫번째요

두번째로는 결혼과 출산 등 갖가지 이유로 정신적 여유가 없었다고나 할까.

몇년간 사회생활로 인해 너무나 많은 에너지를 썼다.

마음대로 안되는게 원래 인생사라고 하지만 몇년을 헛돈 느낌이다.

하고싶은걸 맘대로 할 수 있는 자유를 잃고 바쁘게 살았다.

돈을 많이 못벌어도 하고싶었던 걸 할 수 있었던때가 좋았던 듯 하다.

이제는 가정을 꾸리고 애가 태어나서 그렇게 살라고 해도 못살겠지.

바쁘게 살았음에도 성취감은 크지 않았다. 2번의 이직을 거치고 나서 이제사 좀 사유할 수 있는 여유가 생겼다 할까.

헌데 벌써 2015년이 지나가려 하네 헐..

HadoopXML: A Suite for Parallel Processing of Massive XML Data with Multiple Twig Pattern Queries

Bart — Tue, 23 Oct 2012 14:59:13 +0900

이번 ACM CIKM'12에서 발표될 HadoopXML이라 명명한 저희 시스템입니다.

HadoopXML은 대량의 XML 데이터에 대한 다중 XML 질의 처리를 수행하기 위한 Hadoop 기반의 시스템입니다.

A poster version of HadoopXML from Kyong-Ha Lee

XML은 루트 엘리먼트를 루트로 하는 labeled, ordered tree라는 데이터 모델이라는 특성이 있고,

이 XML 문서에 대한 질의는 가지 패턴 질의(twig pattern query)라는 특성이 있습니다.

예를 들어 //A//B[C]//D와 같은 질의는 A밑에 B 엘리먼트가 있고, 이 B 엘리먼트는

C를 포함하여야 하며, D 엘리먼트는 이러한 B 엘리먼트 밑에 존재하여야 한다는

구조 정보를 기술합니다.

가장 간단한 XML 질의 처리 방법은 XML을 트리 형태(DOM)로 모델링하고 이를 모두 메모리에 올려둔 후 트리의 노드 순회를 통해서 이러한 패턴을 찾는 방법입니다. 하지만, 이런 식의 방법은 트리 내 모든 노드를 순회하여야 하는 문제점이 있지요.

해서 XML 분야에서는 labeling scheme을 이용해서 각 엘리먼트에 레이블을 부여하고, 이들의 레이블 값을 비교함으로써 이러한 패턴 검사를 수행하게 합니다. 예를 들어, A(1:150, 1) B(3:5, 2)

로 레이블된 두 엘리먼트 A, B가 있는 경우 두 값의 interval 값(1:150 vs. 3:5을 비교하고, 어느 한쪽이 다른 쪽의 interval을 포함하는지 등을 검사합니다. 이러한 labeling 기법을 이용하여 기존의 질의 처리를 위한 트리 순회를 레이블 값의 비교를 통한 조인 연산으로 변경한 거지요.

최근의 XML 문서의 크기는 굉장히 큽니다.

예를 들어서 UniProtKB라고 하는 단백질 정보와 단백질간의 관련 정보를 기술하는 XML 문서는 파일 하나의 크기가 108GB 를 넘습니다. 데이터 로깅에서도 Log4j 등을 이용해서 로그 포맷으로 XML이 사용될 수 있을텐데, 이런 경우에도 생성되는 XML 문서의 크기는 매우 크게 되지요.

결국엔 기존의 XML pub/sub 시스템이나 단일 노드에서 동작하는 XML DBMS로는 처리하기가 용이하지 못하게 됩니다. 실제로 저희가 대표적인 open-source XML DBMS인 eXist나 BaseX로 테스트한 경우나 XML pub/sub system인 YFilter로 테스트 한 결과도 그랬습니다.

HadoopXML은 이렇게 크기가 큰 XML 파일을 이들에 대한 질의 처리를 수행합니다. 이러한 작업 기본적으로 Hadoop을 기본으로 수행됩니다. 하지만, 그대로 Hadoop을 가지고 하기엔 여러 가지 문제점들이 있지요.

첫번째 문제는 하나의 큰 XML 문서를 여러 개의 블록들로 분할하게 되면, 각 블록들만 봤을 때는 엘리먼트들의 구조 정보를 알 수 없다는 점입니다. 하나의 트리에 있는 노드를 단순히 같은 수의 노드를 가지는 블록들로 나누는 경우에 한 블록내 노드를 봐서는 이것의 부모나 조상 노드가 뭐였는지 파악하기 힘들죠. HadoopXML은 간단한 테크닉으로 이를 가능하게 합니다.

그리고 또, 하나의 질의를 처리하기 위해 한 MR job을 수행한다면 큰 낭비이겠죠. HadoopXML은

수천개의 질의를 한번의 MR job으로 처리하게 합니다. 이때 여러 가지 최적화를 수행하는데, 첫째는 서로 다른 가지 패턴 질의들 간에 서로 공유되는 경로 패턴들이 존재한다는 점을 착안해서

가지 패턴들을 먼저 경로 패턴들로 분할하고 경로 패턴들에 대한 질의 결과를 먼저 추출합니다.

이때도 서로 다른 경로 패턴들이 문서 상에서 유일한 경로 패턴들로 매칭되는 점을 착안하여

유일한 경로 패턴들의 결과들만 추출하게 하는 최적화를 수행합니다.

다음으로는 이러한 경로 패턴의 결과들을 가지고 조인을 통해 원래의 가지 패턴 조인에 대한 결과를 추출하는데 있어 많은 조인 연산들을 어떻게 지정된 reducer들에 분배하는 것이 효과적이냐입니다. 예를 들어 4,000개의 가지 패턴 조인을 16개의 리듀서에 분배하기 위해서 어떻게 grouping

하는 것이 효과적이냐 하는 문제입니다. 예를 들어 A join B join C와 A join B join D와 같은

유사한 입력을 갖는 조인은 같은 reducer에 두는 것이 좋을 것입니다.

만약에 그렇지 않다면, 서로 공유되는 A 와 B 입력은 두 리듀서에 중복해서 전달됨에 따라 I/O

낭비를 초래하겠죠. 그래서 결국엔 query들의 grouping을 어떻게 효과적으로 수행하는가에 대한

최적화 문제가 있겠고, 이때 고려될 것은 리듀서에 전달되는 경로 패턴의 결과들이 서로

같게 전달되면서, 조인 비용이 최소가 되도록 배분하는 문제가 되겠습니다.

HadoopXML은 이러한 문제를 해결하도록 고안된, 즉 런타임 시에 데이터 뿐만 아니라 질의도

적절히 배분하여 전체 질의 처리 비용을 최소로 하는 방안을 적용하였습니다.

이렇게 해서 HadoopXML은 108GB 크기의 실제 사용되고 있는 XML(UniprotKB/XML) 파일에 대한

16,000개의 가지패턴 질의들을 단지 2개의 M/R job만으로 30 분 이내에 처리합니다.

실험에 이용된 시스템 환경은 Intel i5, 8GB memory, 7200RPM HDD를 가지는 대당 50만원 정도의 일반 PC 9대(1대 master, 8대 slave) 입니다. 이정도의 규모의 저가의 PC로도 좋은 성능을 보여주었습니다.

MapReduce에서 조인 문제는 매우 재밌는 주제입니다. Map과 Reduce라는 고정된 dataflow를 갖는 시스템에서 다양한 조인 연산들, 다중 조인 연산들을 어떻게 효과적으로 지원하는지는 아직도 할 분야가 많아보입니다. 저희는 이러한 문제를 풀고 있고 다른 저널 논문들로 이에 대한 해결 방안들을 순차적으로 곧 보일 겁니다.

HadoopXML: A Suite for Parallel Processing of Massive XML Data with Multiple Twig Pattern Queries from Kyong-Ha Lee

MapReduce 정보과학회 SIGDB 워크샵 발표 자료.

Bart — Mon, 9 Jul 2012 21:42:12 +0900

KIISE:SIGDB Workshop presentation.

View more PowerPoint from Kyong-Ha Lee

Hadoop에서 네트워크가 성능에 미치는 영향.

Bart — Mon, 11 Jun 2012 08:28:17 +0900

근래 KAIST에서 수행하는 연구 중에는 Hadoop을 이용한 비정형데이터 처리가 있다.

그래서 작게나마 9대의 PC들을 가지고 연구실에서 Hadoop cluster를 구축하였다.

1대는 이미 실험실에 존재하던 서버로 이를 Name node로 설정하였고

나머지 8대는 새로 구입한 것으로 i5 quadcore CPU + 8GB 메모리, 1TB 7200RPM HDD와 256GB SSD를 탑재한 것이다. 이들은 data node로 설정하였다. 그리고 이들 모두를 Gigabit switching hub로 연결하였다.

수행하다보니 꼭 reduce task 에서 임의로 노드들의 eth0 네트워크 인터페이스가 죽어버리는

현상을 경험하였다. 처음엔 Hadoop 세팅 자체의 문제이거나 ulimit 등의 사소한 문제로 생각하였으나 아니었다.

수차례의 닭질 끝에 결국엔 Cent0S에 제공하는 Realtek 네트워크 드라이버가 2.x대로

현재의 8.0대에 비해 현저히 버전이 낮은 상태였고, 옛날 버전의 드라이버가 무언가 문제를 일으킨

것을 찾아내었다.

이것을 파악한 것은 나중의 일이고, 처음엔 이것저것 테스트해보았다. 그중에는 스위칭허브를 100Mbps로 교체해 본 일도 포함되었다. 그런데 교체해보니 느리지만 reduce가 죽어서 100% 완료에 도달못하는 문제는 사라졌다.

해서 이번에는 네트워크 드라이버들을 모두 업그레이드를 하고, 100Mbps와 1Gigabit switching hub를 교체해서 달아보면서 네트워크 성능이 어떻게 M/R job의 성능에 영향을 미치는지 간단히 측정해 보았다. 물론 이것은 어떠한 데이터를 가지고 어떠한 작업을 수행하느냐에 따라 크게 달라질 것이다.

필자의 데이터는 text 포맷이고, M/R job은 간단히 언급하자면, text에서 유일한 token들을 추리고,

이들이 전체 데이터에서 얼마나 반복되어 나타나는지 count하여, 원 text와 같이 출력하는 일이다.

실험 결과는:

--------

11GB 데이터 적재 시

1 Gigabit : 222.449s

100Mbps: 1,369.204s

으로 약 6.15배 차이

11GB에 M/R 작업 수행 시

1 Gigabit : 3분 48초

100Mbps : 9분 11초

으로 약 2.41배 차이

를 보여주었다.

이를 Amdahl's law(http://bart7449.tistory.com/244) 에 대입시켜 보면,

data loading의 경우 1/( (1-p) + p/10 ) = 6.15 이고

p ~= 0.93

M/R 작업 수행 시의 경우를 보면,

1 / ( (1-p) + p /10 ) = 2.41

p ~= 0.65

이라는 결과가 나온다.

즉, 데이터 로딩의 경우 네트워크가 Hadoop 시스템에서 차지하는 비율이 약 93% 에 이르고,

M/R 작업의 경우에는 그 비율이 낮아지지만 그래도 과반이 넘는 약 65% 에 이르렀다.

이는 Hadoop 시스템에서 네트워크 성능이 Hadoop 시스템의 전체 성능에 엄청나게 영향을 미치는

요인이라는 얘기가 된다. 우리가 보통 시스템에서 I/O를 얘기를 할 때는 디스크 I/O만을

크게 고려하는데, Hadoop 시스템에서는 오히려 네트워크 I/O가 더 큰 영향을 미치는 것으로

판단된다.

네트워크 쪽 하는 사람들은 Hadoop을 network traffic log 등을 분석하는데 이용하는 것으로 아는데,

bulk data transmission이 많은 이러한 Hadoop 환경에서

네트워크 성능 개선을 통한 Hadoop 시스템 개선이나 또는 Hadoop에 특화된 네트워크 구축 방법이나 개발 등이 좋은 주제가 될 수 있지 않을까?

혹 이와 관련하여 좋은 아이디어 있다면 연락주기를 희망한다. :)

자전거 타기

Bart — Fri, 9 Mar 2012 12:30:58 +0900

따로 시간 내서 운동하기는 뭣하고, 헬쓰한답시고 돈 내놓고 안가서 돈 허비하는 것도 마눌님한테 미안하고 했다.

뭔가 일상 생활 패턴에 녹아들어갈 수 있는 운동이면서 좀 재밌는 건 없을까 하다가 갑자기 튀어 나온 것이 자전거 타기.

6-7Km 정도 되는 출근 길을 자전거로 타고 다니면 운동도 되고 요새 뛰는 기름값에도 대응할 수 있지 않을까라는 생각에 점심 먹고 인근 자전거 매장에 들러보았다. 이른바 MTB 전문점이라는 것도 모른채..

처음에는 20만원 정도 되는 생활 자전거(하지만 그 자체로도 이미 일상생활하는데 있어 충분히 좋은 자전거)를 구입하려고 갔었지만, '1층 매장에 전시된 자전거는 45만원부터이고 그 이하는 지하로 내려가야 한다'는 말에 지하로 내려가기 귀찮고 그걸 또 자존심의 스크래치로 느낀 이상한 성격 탓에 한번 1층부터 둘러보다가 고르게 된 좀 비싼 자전거. ㅠ 유압식 디스크 브레이크가 달린 시마노 데오레 급. 조립 브랜드 자체가 국산이라 좀 저렴함. (어차피 부품은 다 외제),
전문으로 타는 분들에게야 입문용 정도에 지나지 않겠지만 나에게는 본체만으로 한달 생활비를 말아먹고도 남은 녀석이다.

암튼 요새 애를 타고 신나게 출퇴근하고 주말에 갑천변에서 운동하고 있다.
하루 왕복 12km, 약 400kcal정도가 소비되는 것으로 보이고 있고, 주말엔 좀더 멀리 타고 동네 어귀 등을 돌아다니고 있다.
틈틈히 자전거 동호회나 자전거 잡지 홈페이지도 읽어보고 있고...

단순 계산으로는 자전거 가격만큼 기름값을 뽑으려면 10달은 넘게 출퇴근을 해야 하지만, 이러한 기회비용 이상으로 자전거 타면서 좋다고 느껴지는 점이 많다.

1. 먼저 몸이 건강해지는 것 같고, 그만큼 피곤을 덜느끼게 되는 것 같다.
2. 걷거나 차로는 구경할 수 없었던 풍경들을 보게 되었다. 동네 오솔길이나 갑천변들의 작은 길들은
걷기엔 멀고 차로는 들어갈 수 없는 곳들인데 그런 것들을 구경할 수 있다.
3. 근처 맛집을 찾아다닐 수 있다. 운동 뭐빠지게 하고 땀닦으며 식당에 앉아서 밥 먹으면 밥이
그렇게 맛있을 수가 없다.
4. 출퇴근에 화석연료 대신 체력을 에너지원으로 함으로써 환경보호에 동참할 수 있다(음?)

문제는 자전거를 타다보니 자꾸 장비 욕심이 난다는 거다(이른바 장비병). 좀더 고급 장비, 고급 자전거에 눈이 간다는 거. 무게는 좀더 가벼웠으면 좋겠고, 쇼바가 좀더 튼튼하면 좋겠고, 클릿페달을 해볼까... 등등등.
더구나 자전거가 자동차처럼 수리나 교체에 장비나 전문 인력이 들어가는게 아니다보니 부품 교체가 상당히 용이하다. 그러다 보니 페달을 바꿔볼까, 안장을 바꿔볼까 휠을, 아니야 프레임부터? 뭐 이런식이 되어간다.
거기에 중고시장에 부품 교환이 활성화 되어 있다 보니...

헬멧, 복장 등도 맞추는데 돈이 솔찬히 들어간다. 아무래도 부품과 관련용품을 사면서 기름값을 벌 목적이다라고 마눌님한테 핑계되는 것은 저 멀리 안드로메다로 내보내야 겠다.

램클라우드(RAMCloud)

Bart — Tue, 17 Jan 2012 23:06:30 +0900

지난 40년간 마그네틱 디스크는 가장 주요한 저장공간이었다. 대용량 데이터들은 디스크에 기록되고 읽혀졌으며, 상대적으로 용량이 작았던 메인 메모리 때문에 데이터 버퍼링 및 메모리의 효율적 사용이 매우 중요하였다.
때문에 Jim Gray의 5분의 규칙(five-minute rule) 과 같이 데이터 버퍼링 또는 캐싱에 대한 경험적 규칙이 얘기되어 왔다. 실제 디스크에 기반한 DBMS에서도 이 버퍼의 성능이 엄청나게 큰 영향을 미쳐왔다.

5분의 규칙은 1987년, 짐 그레이가 SIGMOD Record에서 언급한 것^[각주:1]으로 디스크와 메모리의 접근 시간과 용량을 간단히 수식화하여 약 5분 내 다시 참조될 데이터는 메모리에 올려두는 것이 좋다라고 언급한 것이다.
해당 논문이 쓰여지고 10년뒤 97년에 그레이는 다시 그당시의 저장 계층의 특성에 의해 이 규칙이 어떻게 변화되었는지 다시 소개^[각주:2]하였고, 또다시 10년 뒤 2008년에는 고츠 그라페(Goetz Graefe)가 SSD의 출현에 의해 이 규칙이 어떻게 변화되는지를 소개하였다^[각주:3].(2007년에 짐 그레이가 실종되서 그는 쓰지 못하였다.)

디스크는 세월이 지남에 따라 그 저장용량(capacity)은 엄청나게 개선되어 왔다. 하지만, 저장 용량에 비해 접근 지연시간(latency)은 크게 개선되지 못하여 왔다. 아래 표를 보자.

이 표를 보면 디스크의 용량은 80년대 중반에 30MB인것이 2009년에는 500GB로 약 16,667배정도로 크게 늘어났다. 지금은 데스크탑의 경우 하드디스크의 용량이 1TB는 기본이다. 전송속도 또한 개선되었으나, 저장용량에 비해서는 크게 개선되지 못하였다. 가장 개선이 못된 것은 접근 지연시간이다. 마그네틱 구조의 특성상 회전하는 디스크 위에서 디스크 암이 움직여야 하므로 랜덤 I/O를 위핸 접근 지연시간은 현 HDD 구조에서는 피할 수 없는 특성이다. 그리고, 이것은 크게 개선되지 못하였다.

따라서 저장용량을 bandwidth로 나누어보면, 용량에 비해 bandwidth 개선이 턱없이 부족함을 보이는 것을 확인할 수 있다. 80년대 중반 15초면 다 읽을 수 있던 것을 지금은 직렬 읽기만 해도 5,000초가 걸리고, 랜덤 읽기인 경우에는 약 58일이라는 엄청난 시간이 요구한다.

이에 따라 연구자들은 기존의 HDD를 대체하기 위해 SSD를 연구해 왔고, SSD는 이제 울트라북을 포함한 여러 PC에 널리 이용되고 있다. 하지만, 데이터센터 스케일에서도 SSD를 적용할 수 있을까?

스탠포드대의 연구자들은 램클라우드라는 프로젝트를 통해 SSD나 디스크보다 이제는 DRAM을 주요 저장공간으로 활용해야 한다고 역설한다. 이들은 인터넷 스케일 서비스의 제공에 있어 HDD를 전혀 이용하지 않고, 수백, 수천대의 노드 컴퓨터들을 연결하여 이들의 메인 메모리들에 모든 데이터를 저장, 관리하는 것을 목표로 한다.

이러한 목표를 제시한 근거에는 여러가지가 있지만, 우선 위 표를 다시 보면 짐 그레이의 5분의 규칙에 따라 5분 이내 재참조될 데이터는 메모리에 올려두었던 것이 이제는 30시간 내에 재참조되는 데이터이라면, 메모리에 올려두는 것이 더 낫다라는 결과를 얻게 되었다는 점이다. 즉, 현재는 가급적이면 모든 데이터를 메모리에 올려두는 것이 효과적이라는 것이다. 사실 이러한 현실은 이전의 Jim Gray의 예측과도 일치한다. 그는 예전에 "Memory becomes disk, disk becomes tape, and tape is dead."라 언급하였다.
즉, 이제는 메모리를 이전의 디스크가 점유했던 주요 저장소로서 활용하고 디스크는 백업과 아카이빙을 위한 용도로 쓰자는 것이다. (사실 테입이 완전히 사라진 것은 아니다. 아직 테입은 여러 데이터 센터에서 데이터 백업의 마지막 보루로 사용되고 있다.)

메모리를 디스크처럼 쓰는 경우 가질 수 있는 많은 장점이 있다. 우선 접근지연시간(latency)가 현격하게 줄어든다. 현재의 데이터 센터를 통한 인터넷 서비스들은 인터넷-스케일이라는 규모가 큰 request들을 처리하는 것을 목적으로 한다. 때문에, 단일 노드로 구성되지 않고 데이터 센터에 많은 노드들을 네트워크로 연결하고 이를 통해 부하를 분산하는 분산 시스템이라는 특징을 가진다. 또한, 웹 서비스와 해당 서비스가 처리/제공하는 데이터가 서로 다른 노드에 위치하는 구조로 인해 접근지연시간이 단일 시스템 구조보다 느리다. 메모리를 디스크처럼 쓰는 경우 이러한 환경에서도 접근지연시간을 마이크로 세컨드 단위로 줄일 수 있다.
SSD를 디스크 대신 쓰는 경우에도 접근지연시간을 크게 줄일 수 있을 것이다. 하지만 저자들은 SSD의 접근지연시간은 디스크에 비해 훨씬 빠르지만, 그렇다하더라도 SSD보다 DRAM의 접근 지연시간 특히 쓰기지연시간이 훨씬 빠르므로 DRAM이 보다 경쟁성이 있다고 저자들은 얘기한다.
아래 그림은 디스크 드라이브, 플래시 메모리오 메모리의 특징을 그림으로 도식화한 것이다.
그림에서 보면 가장 덜 빈번하고, 한번에 요구되는 데이터 량이 큰 경우에는 디스크가 가장 경쟁력이 있고, 작은 크기의 데이터에 대한 매우 빈번한 질의에 대해서는 DRAM이 경쟁력이 있다. 그리고, 이들간의 경계는 시간이 지남에 따라 위쪽으로 이동하는 경향을 보인다. 이러한 경계의 이동은 DRAM의 경쟁력이 갈수록 커짐을 의미한다.

낮은 접근지연시간은 또한 온라인 트랜잭션 처리 비용을 줄이는데 큰 도움을 준다.
예를 들어 일관성을 보장하는데 드는 비용, 즉 특정시간에 동시 수행되는 트랜잭션의 수(overlapping transactions)를 O라고 할 때 이는 새 트랜잭션의 도착비율(arrival rate) R과 각 트랜잭션의 운용기간(duration) D의 곱으로 간략히 표현할 수 있다. O ~ R*D .
동시 수행되어야 할 트랜잭션의 수가 많을 수록 그만큼 트랜잭션들의 일관성을 보장하기위한 비용은 더 높아질 것이다.
R 즉 새 트랜잭션의 도착 비율은 시스템의 스케일이 커가면서 계속 커지게 된다.
하지만, D 각 트랜잭션의 운용기간은 접근지연시간이 낮아짐에 따라 크게 개선되며 따라서 동시수행되는 트랜잭션 수를 줄어줄 수 있다. 사실 이러한 아이디어는 이전부터 메모리 상주형 DBMS(memory-resident DBMS 또는 in-memory DBMS)라는 형태로 구현되어 왔다. 하지만, 메모리 상주형 DBMS가 단일 또는 몇개의 노드를 이용하는 것에 국한되었던 것에 비해 램클라우드는 최소 수백대의 노드들의 메모리를 하나의 virtual storage로 보고 여기에 데이터를 저장시킨다는 점이 차이가 있다.

그렇다면 디스크 전체를 메모리로 대체하는 경우 그 비용은 어떨까? 비현실적이지는 않을까?
여기에 저자들이 조사한 간단한 통계정보가 있다.

2009년 당시 Amazon과 UA에서의 데이터량과 그당시의 메모리 가격을 가지고 해당 데이터를 모두 메모리에 얹기 위해서 소요되는 비용을 계산해 보았더니, Amazon의 경우 적게는 2.4만불에서 24만불 정도가 소요될 거라 한다. UA의 데이터는 그보다 더 작을 것이라 한다.
즉, 메모리는 HDD나 SSD에 비해 빠를 뿐더러 I/O집중인 작업에 보다 싸면서 효과적일 수 있다는 것이다.

그렇다면 메모리 캐싱하고 이 램클라우드하고는 어떻게 틀린가? 인터넷 규모의 서비스를 제공하는 ISP들은 Memcached와 같은 분산 메모리 캐싱을 지원을 한다. 2009년 페이스북은 약 4,000개의 MySQL 서버를 이용해서 데이터 요청을 분산하였다 한다. 작업부하의 분산은 페이스북 자체의 코드로 이루어졌다고 한다. 그러다 이또한 바로 한계에 봉착해서 2,000개의 memcached 를 투입하였다고 한다. 사실 램클라우드는 인터넷 규모의 서비스 제공에 있어 확장성(scalability)을 제공하기 위해 분산 메모리 구조를 지원한다는 점이서는 memcached와 같은 기존 분산 캐싱 기술들과 크게 유사해 보인다. 차이점은 램클라우드는 캐싱이 아닌 아예 데이터를 통채로 메모리에 올리겠다는 것이다. 페이스북 사례와 같은 경우에는 캐쉬된 데이터와 MySQL에 저장된 실 데이터 간의 불일치에 따른 일관성 유지에 따른 관리의 복잡성이 대두될 수 있다. 또한, 데이터가 캐슁되지 않은 경우에는 결국에는 디스크 접근을 필요로 한다. 데이터 접근의 분데이터가 메모리에 캐싱되어 있다면 메모리 접근지연시간을 보장할 수있지만 만약 해당 데이터가 메모리에 캐싱되어 있지 않으면, 디스크에 접근을 하면서 그만큼 접근지연시간이 늦어질 것이라는 점 때문이다.

단일 사이트에서 동작하도록 설계된 DBMS의 제한된 확장성의 문제는 여러 곳에서 이미 지적된 바 있다. 이러한 문제를 해결하기 위한 현재의대표적인 기술은 NoSQL이라 볼 수 있다. 하지만 NoSQL은 확장성을 위해 기존의 DBMS가 가졌던 주요한 기능, 관계형 모델 대신 단순한 key-value model과 제한된 일관성 지원 정책 등의 한계를 또한 갖는다. 그리고 이들 또한 대부분 디스크에 기반한 저장소를 기준으로 설계되어 있으며, 관계형 DBMS만큼 범용적이지도, 호환적이지도 않다라고 저자들은 언급한다.

RAMCloud는 이러한 문제들을 해결하면서, 보다 큰 확장성과, 더짧은 접근지연시간을 제공하는 범용의 저장 시스템을 제공하기 위해 고안되었다.

하지만, 이렇게 모든 데이터를 메모리에 올려놓았을때 문제점은 메모리 자체의 휘발성에 따라 장애 시 데이터가 유실될 수 있다는 점이다. 이에 대한 해결책은 크게 다른 데이터 노드에의 메모리에 데이터를 복제해 두거나 디스크에의 로깅을 생각해 볼 수 있다.

데이터들을 복제해서 모두 메모리에 두는 방식은 synchronous I/O를 가지고도 고성능을 보장할 수 있는 장점이 있지만, 상대적으로 비싼 DRAM이라는 저장장치의 공간을 크게 낭비하게 된다.
반대로, 데이터의 복제나 로그를 디스크에 위치시키는 것은 디스크의 접근지연시간에 따른 비효율성을 피할 수 없다. 때문에 이들은 메모리에의 로그 복제와, 메모리에서 디스크로의 비동기적인 data flushing을 통해 이 문제를 해결하려고 하고 있다.

아래 그림은 초기에 저자들이 생각하는 내고장성을 지원하기 위한 방법을 도식화한것이다.
데이터에 대한 쓰기 연산은 마스터 노드의 메모리 상에서 바로 처리하고, 그에 따른 로그 엔트리들은 다른 노드들의 메모리에 임시적으로 위치시킨다. 그리고, 비동기적으로 각 노드의 메모리에 저장된 로그 데이터를 디스크에 기록한다.

하지만, 아직 어떠한 방식으로 장애에 대한 내고장성을 지원하는지에 대해서는 구체적으로 연구결과를 내놓았다고 보기 어렵다. 아직까지는 이 연구는 실제 적용된 시스템이라기 보다는 일종의 비전에 가깝다. 하지만, 기술의 트렌드는 저자들이 생각하는데로 변화해 나갈것이라 생각된다.

RamCloud에 대한 간단한 소개와 그들의 프로젝트 홈페이지는 아래와 같다.

https://ramcloud.stanford.edu/wiki/display/ramcloud/Home

written by bart7449

The 5 minute rule for trading memory for disc accesses and the 10 byte rule for trading memory for CPU time, ACM SIGMOD Record, 1987 [본문으로]
The five-minute rule ten years later, and other computer storage rules of thumb, ACM SIGMOD Record, 1997 [본문으로]
The five-minute rule 20 years later (and how flash memory changes the rules), ACM Queue, 2008 [본문으로]

MapReduce 소개 자료

Bart — Fri, 6 Jan 2012 10:49:16 +0900

MapReduce: A useful parallel tool that still has room for improvement

View more presentations from Kyong-Ha Lee

지난 1월 5일 SKKU에 가서 한 발표 자료입니다.
MapReduce의 기본 원리와 특성들, 그리고 해당 프레임워크의 장단점과
개선 연구들을 다루었습니다.
뒷부분의 저희 연구내용 소개는 아직 출판이 안된 관계로 일부 뺐습니다.

좋은 영어 선생님 소개 at Tucson

Bart — Thu, 6 Oct 2011 20:13:11 +0900

혹 이 블로그에 미국 투산 생활 정보를 얻기 위해 오신 분들을 위해 좋은 영어 선생님 한분을 소개합니다. Peggy Ford라는 할머니로 한국인들을 위한 영어 강의를 해오고 계십니다. 현재 6명의 한인 학생들을르치고 있고, 많을때는 15명까지 가르쳐봤다고 합니다. 젊었을 적에는 평화유지군으로 배속되어 남편과 같이 세계 일주를 한 경험도 있고, 자전거로 미대륙도 횡단한 활달한 분이십니다:) 굉장히 오랫동안, 한국인들을 대상으로 영어 튜터링을 했기때문에 한국인들의 언어나 발음에 대해 잘 알고 계십니다. 발음 교정에 특히 좋을 겁니다. 그룹 수업은 아닙니다. 1:1 튜터링입니다. 남편따라 같이 미국에 오셨으나, 영어가 아직 어려운 주부분들이나, 학교 들어가기 전후 또는 단기로 미국에 오신 분, 온지 얼마 안되 아직 대화에 부담 가지는 분들에게 좋을 겁니다.
UA campus 바로 앞의 First United Methodist Church, 915 East 4th Street의 도서관을 빌려서 수업을 하지만, 선교하지는 않습니다. 혹 회화 공부가 필요하신 분은 참고하시기 바랍니다.

Peggy Ford
Cell: +1-520-869-1940
email: pegetal AT ix.netcom.com
(스팸땜시 이렇게 표기합니다.AT을 @으로 대체해서 연락하세요. )

* 이글은 2011년도에 작성되었지만 2016년 6월 현재도 Peggy 할머니는 영어 튜터를 하고 계십니다. 며칠 전에도 연락했는데, 제 글을 보고 수업하는 학생이 있다고 얘기하는군요.

Chicken Chicken Chicken

Bart — Tue, 12 Jul 2011 23:53:17 +0900

Doug Zongker's "Chicken chicken chicken". Presented at the AAAS humor session, February 16, 2007
논문 발표를 해본 사람이라면 이게 왜 웃긴지 안다. 압권은 발표 후 질의 응답 시간.

다음은 이 역사적인 발표에 쓰였던 ppt와 논문.

chicken.ppt

chicken.pdf

심지어 Google Scholar에서 검색해보면 citation까지 있다.