어제 회사에서 미디어 컨텐트에 대한 세미나가 있었다. 인하대학교의 김대호 교수께서 발표하셨다. 몇 가지 인상 깊었던 내용을 정리해 보면 다음과 같다.
새로운 미디어에 기존 컨텐트를 올려라. 보통 많은 이들이 실수하는 것이 새로운 미디어에 걸맞는 새로운 컨텐트가 성공 포인트라고 생각하는 것이다. 위성 DMB가 대표적 사례이다. 위성 DMB에 기존 지상파 컨텐트를 올리지 못한 게 실패 요인이다. 사람들은 기존 컨텐트에서 쉽게 벗어나지 못한다. 새로운 미디어에 최적화된 새로운 유형의 컨텐트가 언젠가는 자리 잡히겠지만 이는 시간을 요한다.
새로운 미디어가 자리 잡히는 데는 오랜 시간이 걸린다. 케이블TV의 사례를 들면서 IPTV도 자리 잡히는데 최소 5년은 걸릴 것이라 얘기했다. 케이블TV가 이제 자체 컨텐트를 생산하며 자리를 잡아가고 있지만 여기까지 오는데에도 십수년이 걸렸다.
점차 컨텐트 소비에 대한 비용이 낮아지고 있다. (다들 인식하고 있는 바이다.) 인터넷의 활성화와 더불어 블로그, UCC 등 prosumer에 의해 컨텐트 생산과 유통이 쉬워지고 이로 인해 컨텐트 소비에 대한 비용 지불이 인색해 지고 있다. 이를 타게하기 위한 방법으로 현재로선 광고가 유일하다. (개인적 생각에, 광고 시장 자체도 한계가 있을 터이고 컬러링과 같은 무언가 새로운 비즈니스 모델이 나와야 한다고 생각된다.)
지상파가 한계에 다다르고 있다. 새로운 미디어들의 출현으로 지상파의 경쟁력이 위협 받고 있다. 방송사들은 이를 위한 방어책으로 그들이 가장 경쟁력이 있는 드라마에 올인하고 있다. 그러나 드라마 시청률도 점차 감소하고 있는 상황이다. 앞으로 지상파의 영향력은 감소할 것이다.
이올린에 북마크하기
이올린에 추천하기
현 블로그가 당초 목적과 다른 방향으로 진행되고 있어 (^^;) 스윙댄스를 위한 블로그는 별도로 만들었습니다.
http://lindycamp.tistory.com
현 블로그는 당초 목적인 Mobile Web, Personalization 등에 대한 글로 채워 나가겠습니다.
Trackback : http://mobileweb.tistory.com/trackback/50
HBase는 Hadoop에서 개발 중인 분산 데이터베이스 시스템이다. 구글의 BigTable과 같은 부류라 생각하면 되겠다. HBase가 BigTable을 본따 개발되었고 따라서 내부 아키텍춰도 매우 비슷한 것으로 알려져 있다. BigTable의 논문을 보면 HBase에 대해 이해할 수 있다.
몇 일전 옆 팀 미팅에 초대되어 같이 자리를 한 적이 있다. 미팅의 목적은 HBase가 현재 구현되어야 하는 업무에 적합한 지를 검증하는 것이었다. 서울대 심규석 교수님, Nexr의 한재선 대표님이 참석하셨다. 한재선 박사님은 학교 졸업 이후 약 2년 만에 뵙는 듯 하다. 당시 사업 구상을 하시던 차였는데 이렇게 착착 진행하고 계신 모습을 보니 좋기도 하고 부럽기도 하다.
HBase의 목적은 scalability에 있다. Cloud computing이 보편화 됨에 따라 DB 처리에 대한 높은 scalibility 요구는 당연지사이다. HBase는 데이터 모델을 기존 full-fledged DB에 비해 매우 단순화 시켜 분산 구조에서도 효율적으로 동작하도록 하였다. SQL, concurrency control, transaction 이런 것들을 HBase에서 기대하지 말아야 한다. Indexing에 대해서도 제약이 많아 인덱스를 통한 range selection은 할 수가 없다.
그럼에도 불구하고 HBase (그리고 BigTable)가 조명을 받는 이유는 이렇다. 대다수 웹 애플리케이션에게 간단한 OLTP 질의 처리면 충분하다는 것이다. 마치 grid computing의 현실적 대안이 cloud computing이듯 distributed database의 현실적 대안이 HBase가 아닌가 쉽다. Distributed database는 오래된 주제이나 여러 비효율적이며 복잡한 로직으로 인해 상업적으로는 실패한 분야이다.
HBase를 보며 한 가지 의문이 생겼다. HBase와 BigTable은 column by column으로 데이터를 저장한다. 이런 방식은 Date Warehousing (DW) 시스템이 주로 채택한다. 특정 컬럼에 대해 통계적 수치를 빈번히 구하는 DW 시스템에서 column 위주의 저장 구조는 매우 효율적이다. 그런데 왜 HBase와 BigTable에서 이러한 방식을 채택했을까? 주 타겟인 웹 애플리케이션의 경우 OLTP 질의가 대부분이고 이 경우 row 단위의 접근이 대부분일 것이다.
-
c0d3h4ck 2008/10/30 13:32
Bigtable 의 주 목적은 data size 에 대한 scalability 입니다. 이를 위해 clustering 환경에서 동작하도록 고안되었습니다. 그리고 분산 시스템에서 비용이 크고 복잡한 join 같은 연산을 배제한 simple data model 을 채택했습니다. join 을 없앤 대신에 denomalized 되어진 데이터를 저장하기 위해 column 을 무한히 가질 수 있는 디자인을 택했구요.
잘 아시다 시피 기존 RDB 는 row-based storing 을 합니다. 즉 하나의 row 을 저장 단위로 하여 여러 disk block으로 저장되어 집니다.
Bigtable 은 매우 wide 하고 sparse 합니다. 그런데 대부분의 어플리케이션들이 column 이 수천여개가 있어도 해당 어플리케이션에서 필요한 column은 소수에 불과하게 됩니다. 이런 Bigtable 에서 만약 row-based storing 하게 된다면 소수의 column 을 읽어야 할지라도 one row 에 대한 큰 I/O read가 필요하게 됩니다.
따라서 Bigtable 은 column-family 단위로 column storing 을 하여 I/O 면에서 큰 이득을 보게 됩니다. 특히 sequential read 에서요.-
dbdb 2008/10/31 16:39
리플 감사합니다^^ 여전히 의문이 있는 건, 소수의 column을 읽더라도 row-based storing에서는 한 번의 I/O만 필요하겠지만 column-based storing에서는 column 개수 만큼의 I/O가 필요하다는 것입니다.
게다가 일반 웹 애플리케이션에서 동일한 column에 대해 sequential read를 하는 경우가 빈번한가요?
-
-
c0d3h4ck 2008/11/21 11:57
조금 늦었네요 :)
논문에서는 명시적으로 말하고 있지는 않지만..
제 생각은 다음과 같습니다. (논문에서 명시적으로 말하지 않은 부분들이라 어디까지나 제 생각입니다.)
구글이 일반 웹 어플리케이션을 위해 BigTable 을 디자인 했다고 생각하지는 않습니다.
일반 웹 어플리케이션을 위해서 이런 분산 스토리지까지 필요하지 않았을꺼라는 생각 입니다.
crawling 이나 pagerank 분석이 최초 목적이었을 꺼라 생각합니다. 이 같이 batch-oriented processing 이 주가 되는 어플을 위해 고안되었기 때문에 sequential read 가 우선적으로 고려되었고 그 결과 column store 를 기반으로 했다고 생각되어 집니다.
또한 join 을 억제하기 위해 denomalized 되어진 데이터를 저장하기 위한 wide table 도 고려 요소 었을 꺼라 생각 합니다. -
죠커 2009/01/12 23:05
BigTable 때문에 구글의 어플리케이션 제작이 많이 바뀌었다는 이야기를 들었습니다. 대량의 데이터 뿐만 아니라 희박한 데이터 처리하기에 적합한 속성 때문에 구글의 엔지니어들은 희박한 데이터가 필요한 요구가 어디에 있을까를 생각하게 되었다고 들었습니다. 어쩌면 이런 자극이 구글 엔지니어들에게는 매우 도움이 될 것 같습니다. 정규화된 자료를 만지던 사람과 다른 생각을 한번이나마 더 해보게 되니깐요.
Trackback : http://mobileweb.tistory.com/trackback/38
Recent Comment