CS 전공/논문 쓰기2010. 2. 6. 03:31
 논문을 읽는데 있어 블로그 주인장이 여태까지 여러 분들에게 들은 주요 discipline들이 있는데, 이들을 정리해 보면 다음과 같다.

1) 논문의 내용은 본인이 직접 읽고 판단해야 한다.
논문을 읽다보면 나타나는 수많은 참고 문헌들. 
혹자는 논문에 주어진 참고 문헌들을 읽지 않고 다른 논문에서의 관련 연구들을 보는 것만으로 끝내는 경우도 있는데,  이것은 장님이 코끼리 다리 더듬으면서 이것은 뭐네라고 하는 것과 마찬가지다. 
남이 읽고서 정리한 내용은 그 사람이 이해한 바대로만 쓰여져 있는 것이기 때문이다.

2) 한번 읽은 논문은 그 개념과 주요 내용을 정리하여 기록해 둔다.
  (EndNote, JabRef, Reference Manager 등 많은 도구들이 있다.) 
  암만 기억력이 좋아도 시간이 지나면, 내용은 커녕 예전에 그 논문을 읽었는지도 잊어버린다.

3) 읽을 논문 선정에 있어 Abstract와 Conclusion을 먼저 읽어보라. 
  시간 관계상 모든 논문을 다 읽어볼 수는 없다. 내 분야만 해도 한해에 주요3대 conference에만 출간되는 논문 편수가 800편이 넘는다. 하루에 1개씩 읽어도 도저히 다 못 읽는다. 때문에, 읽어야 할 논문을 선정할 때는 abstract를 먼저 읽어 이 논문이 어떤 문제를 풀려고 하는지를 보고, 다음으로 Conclusion을 보아서 해당 논문이 주어진 문제를 어떻게 풀거나 개선했는지를 파악한다. 이렇게 하면, 논문을 잘못 선정하여 읽다가 보니 '이 산이 아니올시다' 같은 사태를 피할 수 있다.

4) 이해가 안되면 다섯 번은 읽어라.
 여러 학자들이 오랜 기간 동안 고안한 자신들의 복잡한 연구 내용을 12-20 page 의 문서로 작성하는데 들인 시간을 생각해 보라. 그걸 한 번에 읽고 이해하는 것은 당연히 쉬운 일이 아니다. 논문을 한 번에 이해할 수 있는 경우는 경험에 비추어 보면, 이미 그 분야에서 많은 일을 해왔거나 또는 관련하여 많은 논문들을 봐둔 경우 뿐이다. 새 연구 분야의 논문이라면 처음에 그만큼이해하기 어려운 건 당연한 거다. 그러니 한번에 이해하지 못한다 좌절말고, 반복해서 읽어봐라. 

5) 논문에서 설정해 둔 가정이 무엇인지 파악해 두라.
 그 가정을 벗어나는 환경에서 그 논문의 문제 해결 방식은 전혀 쓸모가 없을 수 있다. 때문에 저자들의 가정이 실제 환경에 위배하는지를 잘 파악해 둘 필요가 있다. 

6) 주요 컨퍼런스, 저널에 최근 출간된 논문을 읽어라.
 동일한 연구 주제를 다룬 논문이라도 해당 분야에서 게재되기 제일 까다롭다는 컨퍼런스, 저널에 출간된 논문들을 읽어라. 경쟁이 심하지 않거나, 제출하면 다 게재해주는 컨퍼런스, 저널에 게재된 논문들은 그만큼 연구 방법이나 내용 또한 허술하기 짝이 없다. 물론 주요 컨퍼런스에 게재된 논문 중에서도 연구 방법이 잘못되거나 중요성이 떨어지는 경우도 있지만, 많은 경우에 있어 훨씬 나은 연구 방법과 내용을 보인다. 또한, 같은 연구 주제라도 최신의 연구 방법이나 내용을 습득하기 위해 최근에 출간된 논문을 읽는 편이 좋다.

7) 인용 횟수가 높은 논문을 선택해서 읽어라.
 당신이 봐 두어야 할 논문일 것이다.

8) 주요 컨퍼런스에서 요새 학자들이 무슨 연구들을 하는지 들여다 보라.
 최신의 연구경향을 파악할 수 있다. 오래된 연구 주제들은 이미 남들에 의해 많이 연구되어서, 그만큼 읽어야 할 참고문헌 수는 많으면서 아직 풀리지 않은 문제들의 수는 적다. 때문에 논문 주제를 잡기가 보다 어렵다. 가급적 최신의 연구 주제를 선정한다.

9) 절대 저자가 논문에서 얘기하는 바를 처음부터 믿지 말라.
  논문은 교과서가 아니다. 우수한 컨퍼런스와 저널에 높은 경쟁률을 뚫고 게재된 논문이라도 오류가 있을 수 있다. 일단은 그 논문에 쓰여진 모든 내용에 대해 의구심을 가져야 한다.

10) 잘 쓰여진 논문을 통해, 논문의 스타일과 작성법을 습득하라.
 모방은 창조의 어머니이다. 나중에 본인의 논문 작성 시 도움이 된다. 하지만, 스타일은 참조하되 문장을 베끼지는 말아라(3-4단어 이상이 연속으로 다른 논문의 문장과 일치한다면 표절로 간주된다.)

11) 저자들이 누구인지 보라.
 그 분야에 어떤 사람들이 무슨 일을 하고 있는지 아는 것은 연구 경향 파악과 나중에 혹 있을 자문 의뢰, 공동 연구 등에도 도움이 된다. 
 
Written by bart7449
Posted by Bart
CS 전공/리뷰2010. 1. 8. 12:03

  블로그 주인장은 모 단체에서 DB 및 데이터 처리 기술 관련한 자료의 분석 추천및 검토를 담당하고 있습니다. 
이 분석 자료는 클라우드 컴퓨팅에서의 데이터 관리 이슈와 데이터 처리에 있어 MapReduce와 병렬 DBMS의 비교 분석을 중심으로 클라우드 컴퓨팅에서의 데이터 관리를 설명합니다.
이 자료의 분석은 고려대학교 대학원의 최현식씨께서 수고해 주셨습니다.

아래는 서문과 차례입니다. * 해당 자료의 열람 또는 다운로드는 www.kosen21.org에 가입 후 분석자료 메뉴에서 다운로드 하실 수 있습니다.


1. 분석자 서문 

최근 클라우드 컴퓨팅(cloud computing) 패러다임이 산업계뿐만 아니라 학계에서도 많은 관심을 받고 있다. 이와 더불어 데이터베이스 학계에서는 클라우드 컴퓨팅 환경에서 데이터관리에 대한 집중적인 연구들이 진행되고 있다. 본 분석은 현재 많은 관심을 받고 있는 비공유 구조(shared-nothing architecture) 기반 클라우드 컴퓨팅 환경(아마존 EC2와 같은)에서 유발되는 데이터 관리 이슈들과 이 환경에서 수행되는 데이터 관리의 한계점 및 가능성에 대해 살펴본다. 본 분석은 트랜잭션 데이터 처리보다는 대용량 데이터에 대한 분석 처리가 클라우드 환경에 적합하다는 것을 보인다. 그리고 대용량 데이터 분석을 위해 DBMS에 요구되는 기능들을 제시하고 이 기능들을 바탕으로 기존 오픈 소스 프로그램들과 상용 병렬 DBMS들을 평가한다. 추가적으로, 실험을 통해 두 계열 시스템의 성능을 비교 평가한 논문의 결과를 분석하여 성능 비교에 대한 추가적인 근거를 제시한다. 

2. 목차 

1. 개요 

2. 클라우드 환경에서의 데이터 관리 
2.1 클라우드 환경의 특성 
2.2 클라우드 환경에 적합한 데이터 관리 어플리케이션의 유형 

3. 클라우드 환경에서 데이터 분석용 어플리케이션 
3.1 클라우드 DBMS를 위한 필요기능 
3.2 MapReduce 계열 소프트웨어 
3.3 비공유 구조 기반의 병렬 DBMS 

4. MapReduce와 병렬 DBMS 시스템의 비교 
4.1 질의 시작 비용 
4.2 압축 기능 
4.3 데이터 적재 및 레이아웃 
4.4 실행 전략 
4.5 내고장성 모델 

5. 토론 
5.1 효율성의 비교 
5.2 입력 데이터 형식 
5.3 하이브리드 시스템 

Reference 


Posted by Bart
CS 전공/리뷰2010. 1. 6. 15:13
Univ. of Wisconsin-Madison(이 대학은 CS 특히 컴퓨터 구조 분야에서 아주 독보적인 위치에 있다.)의 Mark D. Hill 교수가 IEEE Computer 2008년 7월호에 기고한 글이다. HPCA'08 에서 키노트로, 또 2009년 2월에는 Google techtalk에서도 발표를 하였다.[Paper][Slides]




 이 논문은 멀티코어 환경에서의 병렬화를 통한 속도향상을 설명하기 위해 멀티코어의 종류와 특징을 설명하고, 이를 위해 자신들의 수정된 암달의 법칙에 대해 설명한다. 사실 암달의 법칙이 바뀐 것은 아니다. 다만, 멀티코어에 맞추어서 암달의 법칙을 보완한 정도이다. 컴퓨터 아키텍트를 주대상으로 발표한 듯 싶지만, 나같은 SW업자에게도 좋은 내용이라 생각된다.

 멀티코어는 크게 대칭형(symmetric)과 비대칭형(asymmetric)으로 구분할 수 있는데, Core2Duo 같은 것이 대칭형이고, Cell Broadband Engine  또는 셀 프로세서라 불리는 것이 비대칭형이다. 이들 각각에 환경에 있어 프로그램 내 병렬 실행 부분(F)에 따른 속도향상의 한계를 보인다. 
식을 간단하게 하기 위해 BCE(Base Core Equivalent)라고 하는 논리적 구성 요소를 가지고, 각 코어는 1개 이상의 BCE를 가진다고 가정하고, r개의 BCE로 구성된 한 코어의 성능을 perf(r)이라고, 정의하고 암달의 법칙을 설명한다.  자세한 내용은 식을 직접 참고하는 편이 낫다. 여기에서는 간단하게 정리만 하자면 결과는:

대칭형 멀티 코어의 경우:
  • 암달의 법칙은 멀티코어 환경에서도 그대로 적용된다. 즉 멀티코어의 성능은 코어 수에 따라 선형으로 증가되지 못하고 제한된다.
  • f 값의 증가, 즉 병렬화 부분을 증가시키는 것이 멀티코어 환경에서도 중요하다. f 값이 충분히 크지 않으면 그냥 CPU 하나의 성능을 증가시키는 것이 더 나은 속도 향상을 보인다.
  • 많은 경우 각 코어에 BCE는 여러개 있는 것이 효과적이다.(즉 코어 수를 많이 늘리는 것보다, 코어 성능을 개선하는 것이 나을 수 있다.) (F=90~99%)
  • 프로그램의 99% 이상이 병렬화 되었다면, 한 칩에 코어가 많은 것이 더 낫다.

비대칭형 멀티 코어의 경우: 
  • 언제나 대칭형 멀티코어보다 더 나은 성능을 보인다. (그래서 셀 프로세서가 인기있는가 보군)
  • r-BCE 코어 하나의 성능을 논할 때, r 값을 클수록 좋은 성능이 나왔다.
  • 상대적으로 작은 F값에 대해서도 주목할만한 속도향상이 있다.

이외에 동적(dynamic) 멀티코어를 논했는데, 이는 필요에 따라 제한된 BCE를 가지고 코어 수를 맘대로 변경할 수 있는 멀티코어를 의미한다. 시뮬레이션 결과는 이것이 가장 좋은 성능을 보인다. 하지만, 아직 존재하지 않으므로 컴퓨터 아키텍트들에겐 최종적인 골이 되어야 한다고. 물론 이 논문은 off-chip bandwidth에 따른 성능 저하나 cache hit에 따른 성능 향상을 고려하지는 않는다.

발표 또한 아주 훌륭하다. 사실 발표 후반부 가면 논문에는 없는 구글의 데이터 센터의 병렬성의 평가를 위한 Karp-Flatt metric도 잠깐 소개한다. 클라우드를 구성하는 노드들 중 성능이 좋은 노드를 r-BCE 코어로 생각함으로써. 이들 간의 연관성을 찾아볼 수 있다. 사실 멀티코어나 mapReduce 같은 비공유 구조의 병렬 컴퓨팅은 크게 다른게 아니다. 요새는 참 좋은 강의들을 인터넷으로 구할 수 있는 좋은 시대인 거 같다. 

PS. 암달의 법칙 자체에 대한 설명은 이 블로그의 http://bart7449.tistory.com/244 를 참고하세요.

written by bart7449 
Posted by Bart
CS 전공/생각?2010. 1. 3. 17:44

얼마 전 결정 난 사항 중에 우리나라 모바일 뱅킹에서도 PC 인터넷 뱅킹과 동일한 수준의 보안체계를 마련한다는 얘기가 있다.(인증서, 키보드 보안, 방화벽, 바이러스 백신 등등등)
현재까지 알려진 플랫폼만 해도,  iPhone, Google Android, MS Windows Mobile, Symbian, Blackberry OS, WIPI, BADA 등 정말 많은 모바일 플랫폼들이 있는데, 이들 모두에 어떻게 모바일 뱅킹을 위한 SW들을 다 지원하겠다는 건지 모르겠다.

작년 9월의 오픈웹 상고심 판결에서도 웹브라우저의 점유비율은 변동성이 있고 수많은 운영체제와 웹브라우저에 호환되는 가입자설비를 제작, 운영, 업그레이드하는 데는 많은 비용이 소요된다"며 "어떤 웹브라우저 환경에 최적화된 가입자설비를 제공할지는 금융결제원 및 금융기관 등 등록대행기관 스스로의 사업적 판단에 맡겨둘 수밖에 없다"라고 했다. 
이 판결의 의미는 법적으로 어떤 브라우저를 지원하는지를 강제할 수는 없다는 의미이겠다.
결국엔 업자들 스스로 알아서 결정해야 한다는 취지로 법원은 판단한 것으로 생각된다.

현재 대표적인 PC 기반 웹 브라우저는 MS IE 7,8, Firefox, Google Chrome, Opera 등 그 수가 모바일 플랫폼에 비해 절대 많은 게 아니다.  
모바일 뱅킹을 위해서 저 위에 있는 모든 플랫폼을 위한  보안 SW를 만들어야 한다면, 모바일 뱅킹 사용자 수보다 훨씬 많은 PC 인터넷 뱅킹 사용자부터 먼저 배려해야 할 일이다. 오히려 역차별인 셈이다. 당장 전세계적인 FIrefox의 점유율은 30%를 넘는다. 기업 입장에서는 이들에 대한 접근성부터 먼저 보장해야 할 일이다. 
설마 모바일 뱅킹에서도  MS 윈도우즈 모바일 하나만 지원할 셈인가? 만약 그렇다면 정말 어처구는 없는 일이다. 
웹 표준 기술로만 인터넷 뱅킹이나 모바일 뱅킹을 지원하게 하면 모든 문제가 다 해결된다. 우리만 그렇게 하자는 것도 아니고 ,다른 나라들은  다 그렇게 하는데 왜 우리나라만 이렇게 하는지 도통 모르겠다. 왜 키보드도 없는 스마트 폰 사용자가 키보드 보안 프로그램을 설치해야 하고, 방화벽 기능이 내장된 Windows vista나 Wiindows 7 사용자가 따로 방화벽을 설치해야 하고, 백신 프로그램 설치되어 있는 PC에 악성 소프트웨어 설치를 또 해야 하는지 모르겠다. 한마디로 보안 과잉이다. 

한쪽 브라우저나 한쪽 플랫폼만 지원할 수 있게 하는건 공정거래에도 위배되는 거 아닌가? 암만 생각해도, 우리나라 웹 보안을 결정하는 사람들은 모두가 "이해당사자"들인 듯 싶다. 

'CS 전공 > 생각?' 카테고리의 다른 글

학회에는 어떻게 참석하는가?  (0) 2010.10.04
구글은 지금도 "Don't be evil"일까.  (2) 2010.02.12
개발 프로젝트의 실패 요인의 분석.  (1) 2009.12.15
논문 심사  (0) 2009.10.05
한국이 노벨상 없는 이유  (0) 2009.07.31
Posted by Bart
CS 전공/리뷰2010. 1. 3. 17:23
2009년 11월 16일자 기사로 나온 이 기사는 엔터프라이즈 컴퓨팅에 중요한 역할을 할 10가지 기술을 소개한다.  (http://www.infoworld.com/d/infoworld/infoworlds-top-10-emerging-enterprise-technologies-378?page=0,0)

1. MapReduce
2. Desktop Virtualization
3. Data Deduplication
4. I/O Virtualization
5. NoSQL Databases
6. Solid State Disks
7. Many Core Chips(CMP; Chip-based Multi Processor) 또는 Multi-core
8. Hardware Power Conservation
9. Cross-Platform Mobile Application Development
10. Whitelisting

확실히 MapReduce와 CMP에 따른 Shared-Nothing, Shared-Memory 환경에서의 병렬화가 대세인 듯 싶다.  MapReduce와 Key-Value Store의 부각에 따른 NoSQL Database 의 부각 또한 유심히 거리이다. 특히 OLAP 쪽에서 기존 Parallel DBMS와의 경쟁 및 협력 관계가 볼만해 질 것이다. (OLTP 업무에서의 SQL DBMS 입지는 절대 줄어들지 않을거다.)
SSD는 이제 Enterprise 급에서도 HDD를 대체해 나갈 가능성이 크다. 단순히 HDD를 SSD로 교체하는 것만으로 Latency와 Power 문제를 크게 해결해 볼 수 있다.
그리고, 갈수록 보다 많은 Mobile app.이 개발될 것이다.


Posted by Bart
CS 전공/리뷰2009. 12. 30. 14:23
Google Fellow이자 우리에겐 MapReduce-OSDI'04와 BigTable-OSDI'06의 저자로 알려진 Jeff Dean이 WSDM'09 에서 keynote로 발표한 발표자료. (Jeff Dean은  두 시스템 덕분에 상당히 젊은 나이임에도 불구하고 올해 ACM Fellow로 임명되었다.)
Google이  어떻게 자기네 정보 검색 시스템을 운영하는데 필요한 대량의 데이터 처리를 지원하는지 그리고 시간이 지남에 따라 감당해야 할 작업량이 증가함에 따라 이를 어떻게 개선해 왔는지에 대해 잘 설명하고 있다. 올해에 행해졌던 technical speech 중 꼭 한 번 봐야 할 것 중 하나라고 생각된다.
 

Posted by Bart
CS 전공/리뷰2009. 12. 27. 09:41
NoSQL Movement에 대한 기사를  읽어 내려가던 중에 다음과 같은 내용을 보았다.
(언제 기회가 되면 요새 MapReduce, Key-Value Store, NoSQL Movement 에 대한 내용을 싹 정리해서 글로 쓰고 싶다. survey paper를 내던, 블로깅을 하던.)

아무튼 기사를 보던 중에 이런 글귀가 눈에 띄었다.
 
예를 들어, 페이스북은 기존 데이터베이스인 MySQL이 아니라 카산드라(Cassandra) 데이터 스토어를 개발해 새로운 검색 기능을 추가했다. 페이스북 엔지니어인 아비나시 락시먼의 프리젠테이션에 따르면, 카산드라는 0.12ms 만에 50GB에 이르는 데이터 스토어를 디스크에 기록할 수 있는데, 이는 MySQL보다 2,500배 빠른 것이다."

우아~! 대단하다. 50GB를 0.12ms만에... 가만 그런데 이것이 가능한 일인가? 
도대체 어떤 기술을 썼길래... 갑자기 궁금해져서 NoSQL discussion에서 있었던 TP를 찾아 보았다. (http://static.last.fm/johan/nosql-20090611/cassandra_nosql.pdf)
  • MySQL > 50 GB Data
    Writes Average : ~300 ms
    Reads Average : ~350 ms

    •Cassandra > 50 GB Data
    Writes Average : 0.12 ms
    Reads Average : 15 ms

실제 위와 같이 써 놓았다. 0.12ms만에 50GBytes에 이르는 데이터를 디스크에 기록한다면,
1ms에 약 416GBytes (=50/0.12ms)를 디스크에 기록할 수 있다는 얘기이다. 
이게 말이 되는가? 이게 말이 된다면, 페이스북은 물리 법칙을 초월한 디스크를 가지고 운영되고 있다는 말이 된다 왜?

모든 디스크의 스펙을 보면 1)seek time, 2) rotational delay time, 3)transfer time이 나와 있다. 
1) seek time은 디스크 암을 움직여서 원하는 트랙으로 움직이는데 걸리는 시간이고,
2) rotational delay time(또는 latency)은 이 암이 트랙상에 위치한 임의 블럭 섹터를 만나는데 까지 걸리는 시간이고,
3) transfer time은 암이 실제 디스크로부터 데이터를 읽거나 쓰는데 걸리는 시간이다.
즉 데이터를 디스크에 기록하는데 있어 걸리는 시간은 1)+2)+3)이다.
그리고 이 중 2),3)은 모두 disk의 RPM에 의해 제한되는 물리적인 한계값을 가진다. 또한 1의 값은 디스크의 크기에 제한된다.(디스크 직경이 클수록 디스크 암이 움직이는 거리도 길어지며, seek time은 그만큼 늘어난다.)

RPM이 빠르면 빠를수록 delay time은 줄어들고 또한 그만큼 빨리 디스크로부터 블럭들을 쓰거나 읽을 수 있다. 하지만 현재 데이터 센터에서 이용되고 있는 디스크들이 갖는 가장 빠른 RPM은 15K이다.
RPM이 15K란 얘기는 디스크가 분당 15,000회 돈다는 얘기이다. 바꿔 말하면, 1회 회전하는데 60000/15000 =  4 ms가 걸린다는 의미이고, rotation delay는  평균 값으로 반바퀴 도는 시간을 재니 이의 절반인 2.0ms가 평균적으로 걸린다고 할 수 있다.  
실제 디스크의 스펙을 보면 더 명백해진다. Seagate의 Data center용 HDD인 Savvio '2.5Inch 15K의 스펙을  보자.
latency가 2ms이다. 

즉 ,어떠한 경우던지, 디스크에 데이터를 기록할 때에는 평균적으로 이 latency값이 먼저 먹고 들어가야 한다. 근데 Cassandra를 보면 seek time은 고사하고, 이 latency 값보다도 작은 값이 걸린다고 하고 있다.
물론 transfer time은 디스크를 병렬로 구성해서 병렬 I/O를 수행하는 식으로 개선할 수 있다. 
예를 들어 sequential write가 100MB/ms인 디스크 하나를 가지고 50GB를 저장하려면, 50*1,024/100= 512ms가 걸린다. 하지만, 50GB를 1000개로 쪼개어 1000개의 디스크에 병렬로 저장한다면 이상적으로 0.512ms가 걸리겠다. 하지만 이 때의 경우에도 각 디스크의 latency는 절대 피할 수가 없다. 결과적으로 평균적으로 걸리는 시간은 seek time + 2ms + 0.512ms이상이 나와야 물리 법칙을 깨지 않게 된다.

그러면, latency가 HDD에 비해 훨씬 낮은 최근의 SSD를 쓰는 경우는 어떠한가?  
요사이 SSD 중 성능이 우수하다는 Intel X25-E Gen2 160GB의 스펙을 보면, 
  • read/write latency가 각각 75/85um, 
  • Random 4K Read/Write는 35K/3.3K IOPS, 
  • Sequential Read/Write가 250/170MB/S
이다. SSD의 latency 85um은 0.12ms = 120us보다는 작다.  즉 SSD로는 0.12ms라는 writing time이 불가능한 것은 아니다. 
그런데, 이 값에서 latency를 제외한 transfer time만을 계산해보면, 45us동안만 데이터를 디스크에 썼다는 얘기가 된다. Sequential write transfer time도 170MB/S이니까 45us동안에는 약 7.84KBytes만을 쓸 수 있다. 그렇다면, 50GB 기록을 위해 50GB/7.84KBytes= 약 660여만개의 SSD가 필요하다는 얘기가 된다.
이게 말이 되는가? SSD 하나 가격이 50만원이라고 해도, 660여만개를 구비하려면  3조 3천억원이상이 필요하다.

결국엔 Cassandra를 만들었다는 저 엔지니어들은 잘못되거나 왜곡된 실험 결과를 내놓은 거라고 밖에 생각할 수가 없다. 우리나라에서도 학부 2-3학년에 배우는 디스크가 어떤 구조인지, 디스크의 cost model도 모른다는 얘기가 된다.
 필시 메모리에 50GB 데이터를 유지하는 상태에서 저렇게 얘기하는 것으로 밖에 보이지 않는다.
근데 여기서 다시 또 생각해보면, 디스크의 데이터를 메모리에 올리는데 걸리는 시간은 디스크 읽기 속도에 의존적일 수밖에 없다.  이때도 쓰기 때와 비슷한 속도가 나올텐데, 도대체 어떻게 저런 실험 결과가 나왔다고 주장할 수 있는지 참 궁금할 따름이다. 
Posted by Bart
CS 전공/논문 쓰기2009. 12. 24. 08:24


J. Hartman과 S. Koborov 교수 방문 앞에 걸려져 있던 두 개의 조그만 그래프를 그대로 그려봤다.
단순하고 모두가 아는 내용이지만 글을 쓰다보면, 이런 저런 이유로 문장이 길어지고 쓸데없는 말만 많아진다.  요는 최소한의 단어로 독자가 내용을 잘 이해할수록 하며, 이해를 위한 충분한 정보를 제공하면서도 간결하게 쓰는 것이 중요하다.
Posted by Bart
CS 전공/생각?2009. 12. 15. 02:27
 CACM Dec 2009을 보니 개발 프로젝트의 실패 요인에 대한 조사/분석 글이 실렸다.
(Why Did Your Project Fail by Narciso Cerpa and June M. Verner, DOI: 10.1145/1610252.1610286)
저자들은 설문 조사 방식을 통해 미국, 호주, 칠레 IT 업체의 235 개의 개발 프로젝트 중 70개의 실패한 프로젝트를 분석해서 과제의 실패 요인들을 분석했다. (이중 21개는 아웃소싱으로 수행된  프로젝트이다.)

재미있는 것은 PM들은 프로젝트가 실패해도 실패라 인정하지 않고, 과제에 찹여했던 개발자들이 주로 참여 프로젝트의 실패를 잘 얘기한다는 것. 프로젝트 종료 후 프로젝트에 대한 평가가 제대로 이뤄지지 않고 있다라는 것 그리고 프로젝트의 실패는 보통 하나의 문제가 아닌 아래와 같은 여러 요인들이 겹쳐서 발생한다 한다.

여러 요인중 실패한 개발 프로젝트에서 가장 빈번하게 발생하는 요인들은:

1. 개발 과정에 영향을 미치는 납기일
2. 개발 과정을 초기 쉽게 생각했던가
3. 위험요인들의 산정과 관리가 제대로 이루어지지 않았던가
4. 작업 시간에 대한 적절한 보상이 주어지지 않는 경우

이랜다. 요는 프로젝트 초기에 얼마나 요구사항들이 충분히 잘 정의되어지고, 충분한 개발 기간이 주어지느냐인 듯 싶다.  이런 문제는 비단 한국만의 문제는 아닌 듯...
여튼 프로젝트 개발 초기에 요구사항들이 잘 정의가 되고 고객과 잘 합의된 개발 기간을 가져야만 성공적인 프로젝트를 수행할 수 있겠다는 얘기인데, 아마도 이것이 PM이 가장 신경을 써야 하는 부분인 듯. 
  



'CS 전공 > 생각?' 카테고리의 다른 글

구글은 지금도 "Don't be evil"일까.  (2) 2010.02.12
꽉 막힌 한국의 웹 접근성  (0) 2010.01.03
논문 심사  (0) 2009.10.05
한국이 노벨상 없는 이유  (0) 2009.07.31
DB쪽 논문 인용 수 TOP5?  (2) 2009.07.29
Posted by Bart
CS 전공/리뷰2009. 11. 22. 15:06
XML이 출현하여 관심을 받아오던 99년, 그 때부터 시작된 이 연구는(까맣게 모르고 있었지만, 이 바닥의 빅 가이들은 이미 눈치채고 연구해왔던), 기존의 DBMS 코드들이 고안되었던 70,80 년대의 컴퓨터 시스템과 지금의 컴퓨터 시스템의 차이 때문에 기존 DBMS에서 널리 사용되던 알고리즘들을 다시 고려해야 한다는 생각에서 출발하였다.

이전의 컴퓨터 시스템과 현재의 컴퓨터 시스템의 차이를 들자면, 여러가지가 있겠지만 현재까지 누적되어온 중요한 차이점들은 다음과 같다.

1) 더 커진 메모리 용량(capacity) 하지만 그만큼 개선되진 못한 접근속도(latency), 그리고 메모리 접근속도의 개선속도보다 더 빠르게 상승한 clock speed의 CPU. 그리고 이러한 접근속도의 차이에 의해 발생한 이에 따른 메모리 벽(memory wall) 문제
 (메모리 벽 문제에 대해서는 일전에 올려둔 을 참고하세요) 
2) 더 커지고 계층화된 HW cache와 이에 따른 메모리 계층(memory hierarchy)
3) Supersclalar CPU(Out-of-Order Instruction Execution), branch prediction, SIMD, 그리고 SMT(Symmetric Multithreading)와 같은 CPU에서의 개선기능들.
4) Multicore(CMP; Chil-level MultiProcessor), Cell Processor, GPU등과 같이 달라진 구조의 CPU
5) Flash Memory
6) FPGA(Field Programmable Gate Array)

즉, 현재의 시스템은 위와 같은 여러 추가적인 기능들을 제공하게 되는데, 기존의 코드들은 이러한 기능들을 제대로 이용하고 있지 않는다는 사실이다.
그래서, 사람들은 Colume-oriented DBMS와 같은 data placement의 변경을 고안하기도 했으며,
또한 메모리 벽 문제를 해결하기 위한 Cache-conscious와 Cache-oblivious algorithm들을 고안하였다.
뿐만 아니라, CSB+-tree 처럼, B-tree와 같은 주요 자료구조들을 다시 바꾸기도 하였다. (Main-memory DBMS에서 이용하는 T-tree는 cache에 대한 고려가 전혀없는 구닥다리라나...) 또 칩 레벨의 멀티 프로세서를 지원하기 위한 여러 방법들이 고안되었고, GPU를 CPU 이외에 질의처리를 위한 보조 프로세서로 활용하기 위한 연구들도 2004년부터 소개되어왔다. 
최근에는 I/O 비대칭성과 in-place update가 안되는, 하지만, latency와 요구전력이 HDD에 비해 월등히 낮은 Flash memory를 위한 여러 연구들도 진행되어 왔다.
요새는 또 FPGA를 이용해 알고리즘을 HW로 구현하는 방식을 통해, 현재의 폰 노이만 방식의 컴퓨터 성능보다 몇십배 향상된 처리 성능을 보장하기도 한다. 

이러한 약 10년간에 걸친 HW 변화에 따른 DBMS 기능의 개선을 위한 연구들의 흐름을 따라가기가 참 버거웠는데, 이들을 한눈에 파악할 수 있도록 해주는 좋은 참고문헌들이 있어서 이를 소개한다.

1) Database Optimizations for Modern Hardware'' J. Cieslewicz and K.A. Ross Proceedings of the IEEE, 96(5), ..... Ken Ross kar@cs.columbia.edu. April, 2009 Paper

2) Database Architectures for New Hardware (invited tutorial), in the 30th International Conference on Very Large Data Bases, Toronto, Canada, August 2004. Also presented as a refereed seminar at the 21st International Conference on Data Engineering, Tokyo, Japan, April 2005.  Slides

3) Query Co-processing on Commodity Processors, in the 22nd International Conference on Data Engineering, Atlanta, Georgia, April 2006 Slides Part I [2.3MB], Part II [2.8MB]

이 쪽 관련해서는 콜럼비아대의 Kenneth Ross, CMU의 Anastasia Ailamaki, 그리고 네덜란드 CWI의 Peter Boncz와 S. Manegold 등이 대가이고, Column-oriented DB 관련해서는 Yale의 Daniel Abadi 등이 많은 연구를 수행하였다.
Flash Memory 관련해서는 여기 문 교수님과 성대 이상원 교수님이 또 좋은 연구를 하셨다.

FPGA를 이용한 알고리즘의 HW로의 구현은 최근에 연구들이 나오기 시작했는데, 제시하는 실험 결과들을 보면 정말 대단하다. dynamic programming 기법의 알고리즘들을 대상으로는 상대적으로 불리할 듯 싶지만, static하게 작성된 알고리즘들을 FPGA로 구현하는 경우에는 그 속도 향상이 엄청난 듯 싶다. 이미 Kickfire 등에서는 FPGA를 이용해 DB 알고리즘들을 구현하기 시작했다고. (http://dbmsmusings.blogspot.com/2009/09/kickfires-approach-to-parallelism.html)


Posted by Bart