NDC Replay

너무너무 훌륭한 MySQL
주경호
네오플
현재 네오플 DB팀에 근무 하고 있으며, Oracle, Mysql 등의 DBA 업무를 수행 하고 있음 (관련 도서 2권 출간 하였음)
오픈소스의 확장과, 모바일 게임의 폭발적인 증가에 따른 DB 저장소의 유연성을 위해 MySQL 을 도입 하거나, 검토중인 회사 또는 개인이 점차 증가 하고 있습니다. 하지만 MySQL 이 가지고 있는 특성에 대한 이해 부족 과 상용 DBMS 가 가지고 있는 다양한 기능과의 단순 비교를 통해, '허접' 하다는 선입관을 가지다 보니, MySQL의 특징과, 특성에 맞는 정확한 사용이 되고 있지 않고 있습니다. 뿐만 아니라 실제 운영에 사용 중인 많은 회사 들이 다양한 기능의 활용을 통해 상용 DBMS 못지 않는 성능과, 운영이 가능 함에도 단순한 In/Out 기능만을 사용 하고 있는 경우를 많이 보게 됩니다. 이러한 현실을 단순 하게 사용자의 학습 부족이라고 평가 할 수는 없습니다. 상용 DB에 비해 부족한 레퍼런스와 관련 도서, 운영 및 개발과 관련 한 다양 한 커뮤니티 및 지식이 부족 하다 보니, 늘 같은 테두리 안에서만 움직이고 있습니다. 본 세션은 MySQL DB를 사용 하여 OLTP 환경의 대용량 데이터 베이스를 운영 하고 있는 경험을 바탕으로 상용 DB의 대표 주자인 Oracle 과 비교 하여 MySQL 과의 차이점, 장/단점을 냉정히 비교 하며, MySQL의 도입을 통해 성공이 가능한 케이스는 어떠한 부분인지에 대해 고민 하고, 그간 오픈 소스의 의미를 잊고, 상용 DB 처럼 생각 하고, 사용 해 왔던 MySQL 에 대해 다같이 공유 하고 실제 안정적이고, 혁신 적으로 운영 하고 있는 사례를 소개 하여 생각의 전환이 이루어지는 기회를 만들어 보고 싶습니다.
[새 창에서 슬라이드 보기]
안녕하십니까? 저는 너무너무 훌륭한 MySQL 이라는 세션 제목을 가지고 발표하게 될 Neople 1팀에서 근무하고 있는 주경호라고 합니다. 반갑습니다. 이제 발표를 진행하기에 앞서 저에 대해서 간략하게 알고 가는 차원에서 소개를 드려보겠습니다. 우선 저는 신세계 I&C E마트 팀에서 E마트 DBA을 했었고요. 그 다음에 구 한미은행이죠. 시티은행에 먹혔는데, 한미은행에서 DBA를 했고 SK broadband에서 통신사 DBA를 했습니다. 그리고 지금은 여러분들이 많이 알고 계실 텐데요 Neople이라는 회사에서 Neople DB팀 팀장으로써 DB팀을 이끌어 나가고 있습니다. Neople이 뭐하는 회사인지는 다 아시겠지만 MOPRG 게임의 최강이죠. 그렇게 동의하지는 않는 것 같습니다. 그렇지만 저는 최강이라고 생각하고 싶습니다. 던전 앤 파이터. 그 다음에 AOS 게임의 최강. LOL은 넘사벽이기 때문에 버리겠습니다. 사이퍼즈 쪽의 DB 관리를 하고 있습니다. 사실 살짝 낮 간지럽긴 하죠. 저는 회사원이니까. 대외적인 자리에서는 우리회사 최고라고 얘기할 수밖에 없겠죠. 사실 좋은 부분도 많이 있고요. 그 다음에 Oracle 튜닝과 관련된 책을 하나 저서를 했었고 그 다음에 Oracle, embedded sql c program책인 Pro*C 책을 저술했습니다. 그래서 이제 13년 외길 오직 DB만 했습니다. 아직 장인이라고 할 수는 없겠지만 나름 장인의 길을 걷고자 하도록 하는 사람입니다. 그래서 시작하기 앞서 여러분들한테 당부 드리고 싶은 말이죠. 이런 자리를 주로 저 같은 경우는 하게 되면 기업체 아니면 특정한 타겟을 가지고 발표를 해봤는데 이렇게 서로 공감대가 아직 완벽하지 않은 상태에서 발표를 할 때 당부를 드립니다. 학교 강의나 세미나 같은 경우는 굉장히 열심히 듣습니다. 서로 공감을 하죠. 또 교수님 말 안 듣게 되면 큰일나니까. 그런데 학교가 아닌 경우에는 저런 눈으로 보죠. 나보다 모르는 부분이 있으면 사단 내겠다는. 왜냐하면 앞에 있는 발표자에 대해서 신뢰감이 없기 때문에 그럴 수 밖에 없죠. 그래도 약간 경륜이 있는 발표자 같은 경우는 나름 필살기를 보여줍니다. 필살기를 보여주면 동경의 눈으로 바뀝니다. 그래서 서로가 인정을 하고 공감을 할 수 있는 자리죠. 그런데 이 자리는 여러분한테 제가 가지고 있는 지식을 알려드리는 자리는 전혀 아닙니다. MySQL이라는 기술 강의를 하는 것도 아니고요. 상용 DBMS에서 비교적 비밀의 세계라고 하죠. 왜 비밀의 세계냐면 상용 DBMS에 비해서 사용층이 아무래도 적죠. 그 다음에 다양한 travelocity reference를 갖고 있지 않죠. 그러다 보니까 비밀의 세계죠. 그래서 우리가 기업체에서 MySQL DB를 마음껏 쓰고 싶어할 때 과감히 얘기할 수 없죠. 기업체에서는, 예를 들어서 우리가 MySQL을 썼다. MySQL을 써서 문제가 나면 나가야죠. 우리나라 사회는 실패를 절대 용납하지 않습니다. 그래서 여러분과 저는 똑같습니다. 그래서 제가 Oracle만 쓰다가 MySQL을 쓰면서 적응했던 부분 그 다음에 느꼈던 부분. ‘아 이게 MySQL이 Oracle에 비해서 절대 뒤지지 않는 구나.’ 절대 뛰어넘지는 못하고요. 그래서 그런 부분들에 대해서 저의 MySQL 적응기를 설명 드리려고 합니다. 그러니까 편안한 마음으로, 아까 그런 독기 어린 눈빛이 아니라, 편안한 마음으로 ‘쟤가 저렇게 어렵게 살았구나.’ 라는 마음으로 들어주시길 바랍니다. 우선 본 세션을 진행하게 된 이유가 있겠죠. 왜 저걸 진행하게 되었냐? 저 역시도 그랬고요. MySQL에 대해서 주변에 한번 물어봅니다. ‘너 아냐?’ ‘어떻게 생각하냐?’ 그러면 딱 저 얘기밖에 안 나옵니다. “학생들이 쓰고, 들어는 봤다. 작은 회사나 작은 사이트에서 쓴다.” 그리고 다른 말 하는 애들이 있죠. “DB는 Oracle이 짱이다.” 그러니까 무조건 평가 절하를 합니다. 그 이유는 접근성이 떨어지기 때문이죠. 그, 다음에 자료가 부재하다. 자료가 부재가 무척 크죠. 상용 DBMS 같은 경우는 한글화된 문서도 많고요. travelocity reference를 많이 구할 데가 많죠. MySQL은 비교적 적죠. 그런 것이 떨어지기 때문에 접근하기가 어렵고 하니까 선입견이 생겨서 잘 사용하고 있지 않습니다. 저 역시도 Oracle 인생 13년하면서 나름 순탄하고 인정받고 저희 마을에서는 고수라는 소리를 듣고 살았는데 당연히 MySQL를 접하는 순간 좌절밖에 없겠죠. 그래서 ‘인생 헛 살았나. 나는 또라이었나.’ 그런 생각도 합니다. 그래서 이번 세션에서는 확산 되고 있는 Open Source 기반의 DBMS에 대한 인식의 변화. 비단 MySQL뿐만이 아니죠. postgreSQL도 있고 maria DB도 있고. 많이 있습니다. 그 다음에 이 세션이 끝났을 때 한번 써볼까? 하는 긍정적인 인식의 변화. 그 다음에 극단적인 거죠. Oracle은 몇 십억이죠. 돈이 한 푼도 안 들잖아요. 그렇기 때문에 큰 비용 절감을 하는데 이점을 얻을 수 있습니다. 그래서 이러한 인식의 변화하고 공감하는 다음에 제가 갖고 있는 생각을 전달하는 자리로 하겠습니다. 세션의 진행은 화면에 나와있는 챕터로 진행이 됩니다. 우선 DBMS업계에서 최강이라고 하죠. Oracle에 대한 부분. 최고를 잡아야 되니까요. 그 다음에 MySQL의 현실. 그러면 최고하고 우리가 허접하다고 생각하는 MySQL의 차이점이 뭐냐. 그러한 차이점을 가지고 간극을 어떻게 조절해 나갈 것인가? 그 다음에 이러한 MySQL을 실제 우리 업무에서 어떻게 적용이 될 것인가에 대해서 아래 챕터로 진행하도록 하겠습니다. Oracle. 다들 아시죠. 그러니까 Oracle은 그런 아이죠. 공부 잘하고, 잘 생기고, 싸움 잘하고, 운동 잘하고. 최고입니다. 말이 필요 없죠. 그래서 공공의 적이죠. 최고라고 합니다. 그리고 SYBASE 같은 경우는 따로 가고 있죠. SYBASE 같은 경우는 OLTP. DB ASA, SQL anywhere 을 따로 만들었고요. DW용은 ASE IP를 쓰고 있죠. 그 다음에 TERADATABASE는 OTLP 영역에 오지도 않습니다. 오직 DW만. 그래서 E마트나 롯데마트 같은 경우가 DW 용 DB를 TERADATABASE를 쓰고 있습니다. IBM은 메인 프레임 계에서는 강자지만 RDBMS에서는 뭐하고 있는지 모르겠습니다. 안타깝죠. SQL Server는, 제가 말하는 주류는 뭐냐면 사회에 근간이 되는 금융, 통신. 이런 쪽에 주류는 못 들어가고 있죠. 게임에서는 많이 쓰고 있지만. 안타깝죠. MS SQL이 그 한계를 가지게 된 건 사실 OS 때문이죠. 그래서 안타깝습니다. 뿐만 아니라 Oracle은 Sun을 먹었죠. 그래서 Sun 장비에다가 Oracle을 이식해서 엑사 데이터 베이스라고 해서 희한한 걸 만들었죠. 그래서 이번엔 “우리 카드 차세대 시스템을 소모적으로 오픈했다.” 라고 발표하고 있고. 메모리 기반 DBMS인 TimesTen이라는 회사를 먹어서 즉 ‘다해먹겠다. 내가.’ 라는 생각을 가지고 있습니다. 그러면 이제 Oracle이 세계 시장에서 최강의 기술을 가질 수 있었던 건 사실 이거였습니다. 알고 계신 분들도 있겠지만, RAC라는 기술이었습니다. 무정지죠. 24x35를 완벽하게 할 수 있는 시스템은 배가 아파도 Oracle 밖에 없습니다. 기존에는 저와 같이 액티브, 스탠바이를 운영하고요 액티브서버가 죽으면 스탠바이서버를 DBA가 올려서, IP 스위칭하고. 그렇기 때문에 DownTime이 발생하죠. 그런데 RAC로 구성하게 되면 액티브, 액티브로 운영하고 여기서 Select 하다가 죽으면 자동으로 넘어갑니다. 사용자는 전혀 못 느낍니다. DML을 하고 있으면 그냥 또 역시 DML도 자동으로 넘어가죠. 최강이죠. 써보지 않았어도, 말로만 들어도, 당연히 저희는 약장수가 아니니까요, 최강이겠죠. 뿐만 아니라 다양한 node. 2 node. KTH 같은 경우는 3 node. SK 같은 경우는 4 node RAC로 구성을 하죠. 그래서 가장 Oracle 사에서 자랑하는 게 SK Telecom 이 3 node RAC를 차세대로 오픈 했는데요. 오픈 첫 날 3번 node가 죽었어요. 그런데 아무도 몰랐어요. 그리고 일주일 있다가 알았어요. 그런데도 아무런 문제가 없었어요. 저하고 Oracle 사는 아무런 관계가 없습니다. 제가 생각해도 ‘대단하다.’ 라는 생각밖에 안 듭니다. 이 외에 당연히 무수히 좋은 기능들이 많이 있습니다. 말로 열거하기도 그렇고요. 그러다 보니까 우리가, 저도 학생 때 그랬고, 왠지 Oracle 한다고 하면 있어 보일 것 같고, 취업 잘 될 거 같고, 돈 많이 벌 거 같고. 그런 생각이 들어서 Oracle DBA를 많이 하려고 하죠. 그러면 MySQL에 대해서 우리가 한번 보면요. 비 상용 RDBMS의 선두주자죠. 돈이 전혀 안 들고, 작고 가볍다. 간편한 유지 관리를 할 수 있고, 손 쉬운 Scale Out이 가능하다. 다만 Oracle에서 인수가 되면 MySQL에서도 핵심 개발자가 나가서 Maria DB를 만들었죠. 그래서 추후에는 Maria DB를 쓸지, MySQL를 쓸지, 뭐를 쓸지 모르겠지만 근간 자체는 특별히 변하는 게 없을 거라고 봅니다. MySQL DB를 설치해 보면 프롬프트에 MySQL이 떠요. 아직도. 그 구조는 그대로 간다는 얘기죠. 제가 MySQL에 적응하는 과정이라고 했잖아요? 제가 MySQL을 접했을 때 저 생각밖에 안 들었습니다. 쿼리 작성에 제한도 있고요. 멀티 쓰레드 관리가 안 되니까 되게 허접하다는 생각이 들었죠. 그리고 쿼리 플랜을 못 보죠. 플랜이 되게 러프하게 나옵니다. 그래서 여러분들이 SQL Server 같은 것 쓰시다가, Oracle 쓰시다가 MySQL의 플랜을 보면 상당히 제한이 많습니다. 그 다음에 DML 쿼리는 플랜을 못 봅니다. 5.6부터는 볼 수 있고요. 그 다음에 멀티 쓰레드 관리가 부족하다 보니까 한 개 세션에서 대량의 I/O를 발생시키면 서버 전체가 다운되는 현상이 발생합니다. 그런데 이건 SQL Server 2005때도 그랬죠. multi parallel query 같은 거 잘못 만나게 되면 서버 전체가 다운되는 현상이 나오잖아요? 그 다음에 DBA나 개발자가 가장 중요하게 생각하는 Meta 정보가 미흡하고 아무튼 웬만한 건 다 별 볼일 없게 보이죠. 부정적으로 보일 수 밖에 없죠. 그래서 차이점에 대해서 하나하나 디테일하게 보면 통합 관제 툴을 제공하냐 라고 봤을 때 Oracle은 EM이라는 게 있죠. 좋죠. 돈 주고 삽니다. 엄청 비싸요. 우리 회사에 Oracle이 10대 있다. 그러면 10개를 다 사야 되요. 안 삽니다. 그래서 저도 여태껏 큰 대기업에서 근무를 했었지만 EM 사서 쓴 적 한번도 없어요. 돈 들어가니까. 결제 올렸다가 다 잘렸어요. 그래서 만들었습니다. MySQL 에서 당연히 만들어 쓰고요. 그 다음에 능동적 Clustering이나 데이터 이중화 솔루션의 경우에 보면 Oracle은 RAC를 제공하고 있죠. RAC 역시도 최고인데 돈이죠. Oracle은 장사 최고 잘합니다. 다 돈입니다. 그래서 RAC도 역시 돈이 있어야 하고, MySQL은 RAC는 없는데 일반적인 DBMS가 가져야 할 능동적인 Clustering과 데이터 이중화 솔루션 자체를 다 가지고 있습니다. 그 다음에 SQL 힌트라는 게 있는데요. Oracle. Oracle을 잘 모르는 분들은 Oracle에 힌트가 차고 넘칠 만큼 있으니까 많이 쓸 수 있다. 그래서 좋다고 생각합니다. 어쨌든 차고 넘칠 만큼 많이 있고요. MySQL의 경우에는 인덱스 사용 관련된 것만 힌트가 존재하고 있습니다. 힌트가 없지는 않다는 얘기죠. 그리고 실제 MySQL에서 힌트를 사용하게 되면 얼토당토않은 힌트가 아닌 이상 힌트가 적용이 됩니다. 그 다음에 다양한 분석 함수를 제공하고 있냐라고 되어있는데요 분석 함수라는 게 뭐냐면요 SQL로 다양한 업무를 처리해야 하는데 SQL로 다양한 업무를 처리하기가 어렵습니다. 그러다 보니까 튜닝의 가장 큰 적이 잦은 DBMS 콜과 디스크 I/O인데 SQL 여러 번 왔다 갔다 해야 하니까 성능이 떨어지고 그러다 보니까 WAS를 늘리고 어플리케이션 서버를 늘리고, 이런 문제가 나오게 됩니다. 그래서 Oracle에서는 8.6버전 이후부터, SQL Server는 2005버전부터 나왔죠, Analytic Function이라고 해서 SQL에 신세계를 열어주는 이상한 함수를 하나 만들어 줍니다. 되게 좋죠. 당연히 뒤에서 설명을 드릴 거고요. MySQL은 안타깝게 그런 게 없습니다. 하지만 역시 저것도 해결이 가능하고요. 그 다음에 고 성능 트랜잭션에 있어서 Oracle은 당연히 최고니까 최고라고 치고. MySQL은 그 트랜잭션 성격과 업무 성격에 맞는 다양한 엔진을 따로 제공합니다. 그래서 뒤에 간극 쪽에서 말씀을 드리겠지만 저는 이러한 부분에 있어서 Oracle을 많이 써봤지만 이게 더 강점이 있다고 봅니다. MySQL같은 경우는 다양한 스토리지 엔진을 통해서 다양한 업무의 성격을 다 맞춰나갈 수 있게 제공합니다. 그리고 그러한 것들이 실제 업무에서 잘 적용되어 쓰이고 있고요. 그리고 간극 조절이라고 해서 두 개의 차이가 있는데 ‘이런데도 불구하고 어떻게 MySQL를 쓸 수 있느냐?’가 아니라 ‘어떻게 해소해서 적용하여 쓸 수 있냐?’를 한번 알아보도록 하겠습니다. 통합 관제 툴은 만들어 쓰면 됩니다. 다른 회사도 다 만들어 쓰고 있죠. 그러면 아까 제가 서두에 MySQL은 Meta 정보가 미흡하다고 했죠. 그 미흡의 수준이 뭐냐면 SLQ Server나 Oracle 기준으로 미흡하다는 거죠. 그러니까 일반적인 수준의 운영에 있어서 Meta 정보의 수준은 그렇게 낮지 않습니다. 다만 Oracle이나 SQL Server처럼 시기별로 해서 특정 시점의 데이터를 분석하거나 이런 것은 떨어질 수 있습니다. 하지만 그런 것 아닌 상황에서는 만들어서 충분히 가능하고요. 그래서 실제 Neople에서 통합 관제 툴을 만들어 쓰고 있는 거를 간단하게 화면으로 보여드리면 저희는 이와 같이 웹으로써 만들어서 사용하고 있습니다. 그래서 이 옆에는 저희가 관리하는 서버가 있고요. 그 다음에 여기에는 관련된 메뉴가 있고요. 그 다음에 여기는 시스템, MySQL, 메모리 이런 것들의 사용률에 대한 것들이 쭉 나와있죠. 그 다음에 이쪽에는 신호등처럼 전 서버에 대해서 요약해서 파란불, 빨간불 들어오게 저희가 특정한 값을 세팅해서 쓰고 있습니다. 그리고 이와 같은 것들이 저희가 특이해서 한 게 아니라 기본적으로 제공되는 정보입니다. MySQL이. 그래서 이와 같이 CPU_LOAD랑 CPU_IDLE, IO_IN/OUT에 대한 정보도 확인할 수 있고요. 그 다음에 디스크를 관리함에 있어서 디스크에 대한 알림이라든지. 관리 매니지먼트가 필요하잖아요? 그래서 지정해서 파티션 별로 볼 수 있고 각 서버의 세팅을 여기서 알아 볼 수 있고요. 역시 여기는 요약된 정보를 볼 수 있습니다. 그 다음에 우리가 DBA로써, 아니면 관리나 개발이나 운영을 하다 보면 SLOW QUARY 라고 해서 오래 수용 되는 쿼리라든지 이런 거는 문제가 되는 거잖아요? 그래서 MySQL에서는 몇 초 이상이라든지 이런 것을 지정할 수 있죠. SLOW QUARY를 따로 지정해서 SLOW QUARY가 발생되면 여기가 이렇게 데이터 저장이 돼서 SLOW QUARY를 추후에 조회해서 튜닝이나 이런 것을 할 수 있습니다. 그러니까 저거만 봐도 일반 DBMS가 제공하고 있어야 될 기능은 다 제공하고 있는 거죠. 살짝 부족한가요? 물론 아주 완벽하지는 않죠. 몇 가지 부족한 부분은 있는데 간극 자체는 충분히 매워갈 수 있다고 보고요. 실제로 Neople이 던파나 사이퍼즈라든지 그런 대규모 게임들이 다 MySQL에 돼 있는데 저렇게 해서 운영하는데 전혀 ……이 없고 잘 운영 되고 있습니다. 그러면 실제 툴이 구성되는 것을 보면요. 실시간으로 이렇게 현재 데이터들이 나오고 있는 거죠. 실시간 정보가 다 나옵니다. 이전 스냅샷 데이터만 보는 게 아니고요. 그래서 이와 같이 시스템, 메모리, MySQL에 대한 걸 볼 수 있고요. 그 다음에 서버를 여러 개 선택을 한다고 하면 layered가 돼서 보이게 구성을 해놨습니다. 물론 이렇게 하라는 게 아니라 저희는 이렇게 운영을 하고 있다는 거죠. 그 다음에 요약 정보로써 특별히 graphical 하게 볼 필요는 없으니까 요약 정보로써 데이터를 확인하고 싶다고 한다면 이렇게 볼 수 있고. 디스크에 대한 부분도 역시 관리를 해야겠죠. 그 다음에 시기별 정보로써 특정 기간내의 시스템의 상황을 보고 싶을 수 있잖아요? 그래서 특정 시기별 상황의 시스템에 대한 각종 상황까지. 다음에 메모리 상황. 사용률이겠죠. 그 다음에 옆에 탭에 MySQL의 select, insert, update data 와 같은 이러한 지표를 다 볼 수 있게 돼있습니다. 그래서 여기를 보면 이 시점의 데이터가 갑자기 팍 튀었잖아요? 그래프가 올라갔잖아요? ‘이때 뭔가 있었겠구나.’ 그래서 이 때의 데이터를 가지고 추적을 한다든지 튜닝을 하는. 이렇게 해서 기본적인 부분만 아니라 심도 깊은 튜닝에 대한 정보를 우리가 MySQL에서 Meta정보가 미흡하다고 하지만 그래도 훌륭하게 얻어낼 수 있습니다. 그리고 실제로 저 정보를 가지고 튜닝을 함에 있어서 제가 기존 Oracle의 튜닝하는 방법과 비교했을 때 물론 과정이 좀 더 길기는 하지만 그렇게 많이 ‘부족하다, 모자라다.’ 라는 생각 자체를 하지 못했습니다. 괜찮다. 라는 거죠. 그 다음에 능동적 Clustering을 보게 되면요. 데이터 복제에 대한 얘기인데, 데이터 복제에 있어서도 역시도 저는 최고라고 생각을 해요. 왜냐하면 Oracle이나 SQL Server는 스토리지 박스 하나에다가 몇 테라를 묶었죠. 그러면 pull back을 받거나 incremental back을 받거나 restore를 할 때 되게 어려워요. 그런데 incremental은 처음부터 compactable하게 운영하게 되니까 보통 이와 같이 master, slave로써 간단하게 구성해서 운영이 됩니다. 그 다음에 master의 slave를 믿고 slave에 또 slave를 붙일 수가 있다. 서로 마지막에 multi-master가 됩니다. 다음에 이와 같이 master에 slave를 두 대 줄 수 있고. 당연히 엔드에 여러 개를 줄 수 있습니다. 다음에 master가 두 대인데 slave는 하나만 받을 수 있고 아니면 서로가 서로를 바라보고 있는 것도 가능합니다. 대단한 거죠 사실은. 왜냐면 Oracle이나 SQL Server도 이렇게 하려면 되게 힘듭니다. 사실. 그래서 일반적으로 많은 회사에서 운영을 할 때는 이와 같은 구조로 운영을 하다가요. 그래서 이와 같은 구조로 운영을 하고 slave쪽에서 select를 발생시키고 master에서 DBL을 발생시키는데 select가 많이 몰릴 것 같다. 예를 들어서 우리가 콘텐츠 큰 걸 올렸다. 특정 시간에 이벤트를 했다고 하면 이렇게 slave를 두대로 쓸 수가 있죠. 그래서 많은 회사들이 이렇게 하고 있죠. 게임 회사 뿐만 아니라 소셜 회사의 위메프나 카카오톡도 이런 식으로 운영하고 있습니다. 다음은 Data Storage Management를 보게 되면 Oracle은 ASM이라는 게 있습니다. Automatic, Storage, Management. 그리고 MySQL은 용도별 스토리지 엔진을 가지고 분리를 하고 있습니다. Oracle에서의 ASM은 자동으로 데이터의 추가와 분산관리를 해주는 막강한 무기입니다. 그래서 써보면 좋긴 좋습니다. 예를 들면 10테라짜리 스토리지 박스를 ASM으로 묶으면 Oracle이 자동으로 다 알아서 해줘요. 그래서 디스크 단편화를 다 막아주고요. 소프트웨어 mirroring을 해줍니다. 그 다음에 Hot spot도 관리를 해주고요. 그래서 140 페타 바이트까지 관리가 가능합니다. 돈이 많으면 됩니다. 그래서 ASM을 아직 정식으로 도입한 대기업을 못 봤어요. 왜냐하면 이게 워낙 비싸니까. Oracle 하나하나 라이선스를 가집니다. 그런데 MySQL같은 경우는 많은 스토리지 엔진을 가지고 이와 같은 Data Storage Management를 지원합니다. 그래서 우리가 많이 알고 있는 MyISAM 스토리지 엔진 같은 경우는 로그 데이터 같은 것을 일방적으로 쌓는다. 이럴 때 많이 쓰이죠. 대신에 테이블 레벨 락이 발생합니다. 그 다음에 OLTP환경에서 로그 레벨 락을 지원하는 환경에 쓰인다고 하면 당연히 Inno DB 엔진을 씁니다. SQL Server나 Oracle의 테이블 스페이스와 동일하게 관리가 되는 겁니다. 그 다음에 Hot Data. 서버를 내렸다 올리거나 서버가 다운이 되면 데이터가 날라가더라도 Hot Data나 인증 데이터 같은 거 올려 써야겠다. 라고 하면 Memory 기반을 쓸 수가 있고요. SQL Server의 분산 데이터 베이스나 Oracle의 DB Link처럼 쓰고 싶다라고 하면 Federated를 쓸 수가 있고요. 즉 용도별로 되게 달라요. 거기다가 이 MyISAM의 경우가 아주 훌륭하다고 느끼는 분이 MyISAM으로 테이블을 만들어 놓고 다른 데다 restore하고 싶다고 하면 그 파일 그대로 카피하면 되요. Oracle 같은 경우는 export 받아서 import 하거나, 아니면 CTAS를 받아서 sam 파일을 받아서 옮기거나 그래야 된다는 거죠. 그래서 엄청 막강하다라고 봅니다. 그래서 저는 이거 하나만 봤을 때는 MySQL이 최강이 아닌가라는 생각도 합니다. 왜냐하면 기존 DB를 운영하면서 이 부분에서 많이 고생을 했기 때문에 이렇게 스토리지 엔진을 분리함으로써 여러분들이 좀더 유연하게 쓰실 수 있습니다. 다음에 SQL 힌트에 대해선데요. SQL 힌트는 아까 Oracle은 차고 넘칠 만큼 많이 있다고 하고 Oracle을 안 써봤던 사람한테 SQL 힌트를 보여주면 신세계가 열린 것 같다라고 생각합니다. 그리고 MySQL은 이거밖에 없고요. 그러면 Oracle의 힌트가 좋은 거냐? 오라클의 힌트는 없어져야 할겁니다. 왜? Oracle을 쓰다 보면 이런 일이 많이 나옵니다. 어제는 1초가 걸렸어요. 그런데 갑자기 자고 일어났더니 모래시계. 화면 조회하면. 그러면 당연히 팀장이랑 과장이랑 부장. 누가 프로그램 짰냐 이거죠. 그러면 이게 왜 그렇게 됐냐 이거죠. 어제 장사가 좀 안 됐어요. 그런데 오늘은 장사가 잘 돼서 데이터가 많이 들어왔어요. 데이터 양이 변화함에 따라서 분포도가 달라지니까 길이 달라지는 거죠. 우리가 자동차에서 네비게이션 업데이트하고 나면 길 이상한 거 가리켜주잖아요? 똑같아요. 그래서 Oracle을 쓰게 되면 저놈의 실행 계획 때문에 어제는 1초였는데 오늘은 2초였어요. 이런 거 때문에 미쳐요. 그래서 실례로 하나로 텔레콤이 두루넷을 먹었을 때 두루넷 데이터를 마이그를 했어요. 마이그를 하고, 여기 DBA 분들이나 운영하시는 분들은 알겠지만, 통계정보 갱신한다고 하죠? 그걸 해야 되잖아요? 6개월 동안 안 했어요. 하면 다음날부터 사단나니까. 그래서 6개월 동안 프로그램 하나하나 다 고친 다음에 6개월 뒤에 통계정보 갱신했어요. 그만큼 Oracle을 쓰다 보면 어렵습니다. 그래서 Oracle이 왜그랬냐면 OLTP나 DW 업무를 모두 만족시키는, 뭐든지 잘하는 그런 DB를 만들고 싶었죠. 그런데 현실은 괴롭죠. 그런데 MySQL. OLTP에 적합한 실행 계획을 가집니다. 힌트가 필요가 없는 거에요. 어떠한 SQL을 날리더라도 OLTP에 적합한 실행 계획을 가지고 SQL이 시행되기 때문에 개발자나 DBA가 인덱스를 다른 거 타거나 이런 거 아니면 특별히 개입해야 될 여지가 많이 없습니다. 오히려 되게 편한 거죠. 그게 맞는 거고. 즉 어제 1초가 나오던 게 오늘 데이터가 더 들어왔다고 10초가 되는 그런 어이없는 문제는 안 나옵니다. 그래서 그런 실행 계획의 변화에 있어서는 MySQL나 SQL Server나 SYBASE나 이런 DB가 훨씬 낫다고 봅니다. Oracle을 쓰면서 괴로웠던 기억밖에 없었어요. 그 다음에 다양한 분석 함수. 결론은 MySQL은 없죠. 그런데 수학 SQL은 집합이죠. 집합은 절차형 언어가 아니기 때문에 수학을 잘하면 됩니다. 그래서 수학적 사고와 수학을 잘한다면 그냥 만들어 쓰면 됩니다. 그런데 하기 싫죠. 저도 사실은 국어가 싫어서 이과를 갔습니다. 그런데 이과 다니면서 수학 때문에 돌아버리는 줄 알았습니다. 그 다음에 전산과를 다니면서 공업수학 때문에 미쳐버리는 줄 알았습니다. 그런데 여기서 말하는 수학이라는 건 그러한 난이도 높은 수준의 수학이 아니라 집합. 집합적 사고만 가능할 수 있다면 가능하다라는 거죠. 그래서 절차형 사고에 익숙한 사람일수록 어려운데, 사고를 많이 바꿔야겠죠. 그래서 실제 예제를 보면 판매 관리 시스템이다 라고 보면 예를 들어서 대분류, 중분류 별로 해서 판매 일자를 정렬해서 보여 달래요. 판매 일자가 같으면 상품 코드를 정렬해서 그리고 수량과 누적 수량을 보여 달래요. 이거를 만약에 프로그래밍 한다고 하면, SQL 하나로 하고 싶다. SQL로 하는 게 가장 좋으니까요. 튜닝에. 그래서 그런 거만 하는 컨설턴트가 있잖아요? 그래서 우리가 DB에 관심 있는 분들은 알고 있는 엔코아, 비투엔 들어보셨죠? 그런 회사가 이런 것만 하고 다니죠. 이렇게 하면 됩니다. 저처럼 많이 접한 사람은 무척 간단해 보이고요. 이런 거 처음 봤으면 당연히 이렇죠. 그런데 이게 바로 SQL의 파라다이스였어요. 옛날에. 이게 뭐냐면, 간단하게 설명 드리면 아까 대분류에 중분류 별로 하라고 했잖아요? 그래서 대분류와 중분류 별로 파티션을 묶고요. 그 안에서 일자의 상품 코드를 정렬해서 누적해라, sum을 하라는 얘기입니다. 그래서 무척 직관적입니다. 그래서 쉽습니다. 물론 지금 처음 본 사람한테 쉽냐고 물어보면 당연히 안 쉽죠. 그런데 조금만 이해한다면 많이 어렵지 않습니다. 그러면 만약에 MySQL에서 없으니까 이걸 어떻게 해야 하냐? 이렇게 하면 됩니다. 조금 복잡한데 많이 복잡하지는 않습니다. 이렇게 해서 가능하다는 거죠. 그러면 이게 어떻게 해서 된 거냐? 누적이라는 것은 큰 집합 기준으로 해서 나보다 작은 집합의 데이터를 sum을 하면 되는 거잖아요? 나보다 작은 데이터. 그렇기 때문에 내가 나를 조인하는 거죠. 어떻게? 이 그림대로. 큰 집합 기준으로 해서 작은 집합 위쪽에 올 수 있게. 그래서 대분류, 중분류 해야 하니까 같은 대분류에 같은 중분류로 해서 상품 일자와 상품 코드가 큰 것. 그래서 B쪽이 큰 집합, A쪽이 작은 집합이 되죠. 그래서 이렇게 해서 select 하게 되면 이 모양이 나옵니다. 새우깡보다 작은 게 하나도 없으니까요. 새우깡만 나와요. 꼬깔콘 기준으로 봤을 때 꼬깔콘 보다 작은 게 꼬깔콘, 새우깡이니까 두 로그가 나오죠. 작은 집합의 수량이 나오고. 빼빼로 기준에서 세 개니까 작은 집합의 수량. 콘칩 기준으로 네 개니까 작은 집합의 수량이 4개가 나옵니다. 그래서 이걸 대분류, 중분류, 일자와 상품으로 sum을 하게 되면 아까와 같은 걸 할 수가 있습니다. 그래서 제가 한참 Oracle 할 때 DBA로써 큰 꿈을 이루고자 이 업계에서 나름 신이라고 부르는 이화식 씨하고 제가 식사할 수 있는 자리가 있었어요. 그때 그분이 저한테 이런 걸 설명하면서 SQL로 다 된다고 했어요. 그래서 제가 뭐라고 했을 것 같아요? 속으로. ‘뻥치시네.’ 왜냐면 제가 안 됐거든요. 그런데 막상 해보니까 많은 부분이 다 가능합니다. 그래서 만약에 이 자리 말고 다른 시간이 되면 SQL로 되는 다양한 사례를 보여드리고 싶어요. 어쨌든 다양한 분석 함수가 다 가능합니다. 그래서 이와 같이 MySQL이 절대 Oracle을 잡지는 못하죠. 그거는 당연하죠. 하지만 Oracle과 MySQL를 비교했을 때 많은 부분에서 기능 차이가 있고 부족한 부분이 있지만 그 부족함을 우리가 감내하지 못할 수준이 아니라는 거죠. 많은 부분에서 감내할 수 있고 실제 사례에서 운영할 수 있는 부분이라 이겁니다. 그래서 적용 가능 영역을 보면, 사실은 MySQL 홈페이지에 나와있는 거죠. 작고, 가볍고, 손쉬운 확장. 이런 부분이라고 합니다. 저 역시도 이런 부분은 동의합니다. Oracle 같은 경우는 돈이 많이 듭니다. 그래서 돈이 많아야 되요. 저도 옛날에 Oracle 쓰면서 Oracle 엔지니어하고 얘기를 할 때 엔지니어가 “이건 돈입니다. 이건 돈입니다.” 할 때 짜증났어요. 결론은 어쨌든 다 돈이에요. 비싸고 엄청난 스펙의 하드웨어가 필요하고요. 대용량 스토리지가 필요하죠. 그 다음에 SAN 장비도 필요하고, Giga Backbone에 네트워크 뭐 하고 N개의 스위치장비. 다 돈입니다. 돈. 그런데 MySQL은 단위 업무 별로, 특성 별로 나누어서 작은 스펙의 장비에 구성을 하면 됩니다. 그래서 저와 같이 특성에 맞게 장비에다가 DB를 구성하면 됩니다. 상대 비용이 적죠. 그리고 만약에 우리가 하나의 DB였는데 이 DB에 부하가 많이 걸리면 업무 특성에 맞게 테이블을 쪼개서 DB를 별도로 구성하면 됩니다. 손쉽게 확장이 가능하죠. 또 이렇게 옮기는 거에 있어서 우리가 과거에 Oracle이나 SQL Server를 쓰셨던 분들이 생각하는 그 수준이 아니에요. 되게 기초적인 수준이에요. 그냥 백업 데이터 갖다가 Insert하고 동기화만 맞추면 끝나요. 아주 간단하죠. 물론 여기서 관리해야 될 DB수가 늘어납니다. 막 쪼개다 보니까 그러면 관리해야 될 장비수가 늘어나니까 관리비용이 늘어나는 거 아니냐? 라고 반문할 수 있는데요. Oracle 같은 경우에는 장비수가 적어도 오라클 하나에 대한 메인터넌스를 하려면 하드웨어 엔지니어, Oracle 엔지니어, 저. 이렇게 많이 필요하고요. 그 다음에 Oracle 같은 경우에 버그가 발생하면 패치가 되게 크게 들어가야 되잖아요. 시퀀드도 마찬가지였고요. 그러면 그 비용 자체가 더 크다는 얘기죠. 그런데 MySQL는 대수는 많을 뿐이지만 메인터넌스 비용이 적죠. 짧게 짧게 가니까. 그렇기 때문에 장비가 많아지는 괴로움이 있지만 관리 비용 자체는 상대적으로 더 늘어나는 것은 아니다라는 거죠. 그래서 결론은 적용이 어려운 부분은 없다고 봅니다. 다만 비 상용 DBMS 특성상 기술 지원이 없죠. 우리가 다 알아서 해야 합니다. 그런데 지금 현재 MySQL에서 제공하고 있는 그 버전 만으로도, 특별한 수정 없이 그 버전 만으로도 많은 회사에서 적용해 쓰고 있고 특별한 문제가 발생하지 않고 쓰고 있다라는 거죠. 물론 저희 회사뿐만 아니라 많은 회사가 쓰고 있죠. 물론 제가 적용 가능에 불가능한 영역이 없다라고 해서 “은행에도 쓸 수 있습니다.” 라고 말하기는 사실 부담됩니다. 그래서 은행과 같은 데이터 무 손실이 아주 중요하다 라고 한다면 적용하기 부담이 되죠. 하지만 그 외 업무에 대해서는 가볍고 단순하기 때문에 쓰기 편하다는 거죠. 그래서 요즘에 많은 대기업에서 쓰고 있죠. 대표적으로는 통신 업계 1위인 무슨 회사 있죠. 거기 회서에서도 메인 DBMS는 Oracle로 가는데 그 외의 업무에 대해서는 MySQL나 postgreSQL로 넘어가고 있죠. 그래서 많은 대기업에서도 확장이 되고 있습니다. 그리고 근래에는 DW 영역에서도 그 능력을 발휘하고 있죠. 왜? DW 자체라는 게 데이터 양은 큰데요. 빠르게 데이터를 가져와서 복구하고 데이터를 많이 해서 보여줘야 되는 업무에 있어서는 작게 가는 것도 오히려 편할 수 있기 때문에 Neople 같은 경우도 통계업무에 있어서 MySQL이 큰 역할을 하고 있습니다. 아까 설명 드린 대기업들도 오픈 소스 기반의 DBMS에 대한 투자를 많이 늘리고 있습니다. 그래서 요즘에 통신회사라든지. 주로 통신회사에서 많이 움직이고 있고요. 그 다음에 유통회사라든지. 이런 쪽에서 주요 메인 DBMS를 제외하고는 MySQL이나, 사실 윈도우 기반의 DBMS는 고려를 안하고 있더라고요. 대부분 리눅스 기반이겠죠? 많이 확장되고 있습니다. 그래서 일할 곳이 많이 늘어나고 있죠. 사실 시장이 Oracle이나 SQL Server DBA는 많이 있는 반면에 MySQL은 많이 없죠. 그래서 점점 몸값도 올라가고 있지 않나 라는 생각도 들고요. 그래서 정리를 하면 ‘오픈 소스는 공짜다.’ 가 아니죠. 사실은 오픈 소스의 의미 자체는 소스 코드를 공개해서 모든 인들이 참여를 통해서 발전하고 상용 제품처럼 딱 맞추어진 틀이 아니라 나의 환경에 맞춰 재구성을 한다는 건데요. 제가 여기 있는 분들한테 “MySQL의 소스를 직접 보고 소스를 쓰세요.” 라고 는 못하죠. 왜냐하면 저도 그렇게 하고 있지는 않습니다. 원래 그렇게 해야 하는 게 맞죠. 저희 같은 경우도 그렇게 하려고 노력은 하고 있지만 걸음마 단계고요. 하지만 MySQL이 현재 나와있는 배포버전을 가지고 사용함에 있어서도 실 업무에 적용함에 있어서도 특별히 어려움이나 부족함이 전혀 없다는 거죠. 앞서 보여드렸던 사례들 저희가 별도로 메인터넌스 한 버전이 아니라 실제 배포버전을 가지고 운영을 하고 있다는 거죠. 안정적이라는 얘기입니다. 그래서 사실 손발이 조금만 고생하면 엄청난 비용을 절감할 수 있고요. 다양한 기능을 통해 완벽한 업무용 DB로 사용이 가능하다는 겁니다. 그래서 본 세션에서 제가 전달하고 싶었던 부분은 바로 이 부분이죠. MySQL이 우리가 겪어보지 못했기 때문에 ‘허접하다. 로우하다.’ 라고 생각을 했는데 사실은 그게 아니라 메인 업무에 DBMS로 사용함에 전혀 부족함이 없고 저런 레퍼런스가 있다는 거죠. 그렇기 때문에 여러분들 역시도 앞으로 돌아가셔서 실 업무를 하실 때 많은 부분에서 사용하시고 확산이 됐으면 합니다. 이렇게 해서 본 세션의 발표를 마치겠고요. 제 발표를 들으시면서 궁금했던 부분이나 그런 부분에 대해서 잠시 질문을 받도록 하겠습니다. 
Q. 강연 중에 MySQL로도 리플리케이션으로 구성해서 쓰고 있다고 했는데 저도 예전에 게임 만들었을 때 MySQL 리플리케이션을 사용했었는데 5.5 버전까지의 기준으로는 slave들이 다 싱글 쓰레드로 돌기 때문에 select가 많을 경우 상관이 없는 게 DML이 많을 경우에 master랑은 싱크가 깨져서 딜레이가 많이 발생하는 경우가 있는데, 분명히 Neople 게임들은 제가 만들었던 게임보다는 훨씬 동적 ……이 높을 텐데 그런 경우에 대해서는 어떻게 해결했는지 궁금합니다. 
A. 그러니까 저희가 대부분의 MySQL을 쓰는 회사들이 방금 질문하신 분처럼 Master, slave를 하고 select는 slave에서 발생을 시킵니다. 저희 역시도 그렇게 하고 있고요. 그런데 다만 방금 말씀하신 것처럼 master에 엄청난 DML이 들어오고 slave로 가는 시간이 있을 것 아닙니까? 거의 실시간으로 싱크가 맞춰지는데요. 약간의 차이가 발생할 수 밖에 없습니다. 그래서 뭔가 엄청난 대안이 나올 것 같죠? 게임 서버의 경우에는 master를 무조건 보게 합니다. Master 쪽에 select하고 insert 할 수 있게 해줍니다. 왜냐하면 이 싱크 자체를 맞춰주는 방법이 없지 않습니까? 기술적으로 싱크를 빨리 당겨라 이게 아니라 데이터가 master에서 DML이 발생이 되고 발생된 데이터에 대해서 로그가 생겨서 slave로 넘어가는 거잖아요? 그렇기 때문에 그걸 어떻게 우리가 세팅이나 기술적인 방법으로 해결하지는 않고요. 그렇게 싱크를 무조건 맞춰야 되는 업무에 대해서는 master쪽을 바라볼 수 있게 하고 있습니다. 그래서 로그인을 해야 한다 라거나 게임 서버라든지 그 다음에 Hot Time에 이벤트를 한다든지. 이럴 경우에는 master DB를 바라보게 해서 그런 문제를 막고 있습니다. 
(질문자)_제가 알고 지내는 Neople 사람들 듣기로는 Neople DB에 게임에서 쓰는 바이너리 데이터를 그대로 넣어서 운영하고 있는 걸로 알고 있거든요. DB를 그렇게 사용하는데 있어서 관련된 이슈들과 좀더 특별한 관리 방법이 있는지 그런 것들이 궁금합니다.
(발표자)_게임 회사에 계신 분들은 알겠지만 인벤토리 이런 데이터죠. 장비, 아이템이 되게 많잖아요? 그래서 그거를 바이너리를 씁니다. 바이너리를 쓰는 이유는 딱 하나입니다. 확장이 더 편하게 된다는 거죠. 왜냐하면 1byte는 8bit 잖아요? 그 만큼 예를 들어서 10byte의 바이너리 데이터를 쓰게 되면 더 많은 데이터를 쓸 수 있고요. 그 다음에 바이너리 데이터니까 압축도 가능하고요. 그런데 이렇게 되게 되면 문제가 있죠. 데이터 select 아무것도 볼 수가 없습니다. 그래서 항상 뭔가 데이터를 select하고 거기 있는 데이터를 꺼내와야 할 때는 별도로 뭘 하는 작업을 해야 합니다. 바이너리 파일을 만들어서. 그래서 저희 회사에서 운영하면서 가장 어려운 부분이 방금 말씀하신 그 부분이에요. 예를 들면 어떠한 아이템을 갖고 있는 데이터를 찾고 싶다 했을 때. 볼 방법이 없다는 거죠. 그래서 그걸 select해서 봐야 하는 부분이 있는데 그러면 반대로 그걸 풀어놓으면 해결되는 거 아닙니까? 라고 얘기할 수 있죠. 그런데 풀어 놓으면 데이터 양이 엄청 많아지겠죠. 그래서 어느 쪽을 선택해서 가는 거냐? 라고 했을 때 저희는 게임 안정성이 우선이기 때문에 바이너리 데이터를 쓰고요. 그 데이터에 대해서 대응을 할 때 저희는 무조건 한발 늦습니다. 그럴 수 밖에 없겠죠. 그래서 별도의 데이터를 풀어헤치는 툴을 통해서 확인해서 처리하는 것을 하고 있고요. 물론 점차적으로 텀을 줄이는 작업을 하고 있지만 그런 식으로 사용하고 있습니다.
(질문자2)_아까 말씀하신 managed 보면서 엔진 종류가 여러 가지가 있고 사용 장단점이 있다고 하셨는데 기존에 게임에 사용 되었던 엔진 종류에는 어떤 걸 사용했고 거기에 대한 장단점이 어떤 것이 있었나요?
(발표자)_사실 엔진종류는 많이 있는데 실제 우리가 업무에서 많이 쓰는 엔진은 한정되어 있습니다. 저희 같은 경우는 MyISAM과 InnoDB. 그 다음에 Memory 기반 정도로 사용하고 있는데요. MyISAM이라는 엔진 같은 경우는 테이블 레벨을 나뉘는데 쓰게 됩니다. 그렇기 때문에 동시 트랜잭션을 보장받아야 되는 업무는 당연히 못 쓰겠죠. 그러다 보니까 게임 내 로그라든지, 이런 걸 기록하는 DB에 있어서는 MyISAM을 쓰게 됩니다. 대신에 MyISAM같은 경우는 아까 말씀 드렸다시피 파일 단위니까 restore가 편하죠. 그 다음에 그게 아닌 동시성을 보장받아야 하는 업무에서는 InnoDB엔진을 씁니다. 그래서 InnoDB 엔진을 쓰게 되면 일반 데이터베이스의 테이블 스페이스 관리하는 것처럼 관리가 되고요. 로우 레벨 락이 정리가 되기 때문에 동시성도 업무가 강합니다. 그리고 메모리 기반 같은 경우는 거의 많이 쓰이는 부분이 적긴 한데요. Hot이죠. 그냥. 데이터 기동에 대해서 select 하게 되면 데이터가 올라가고요. DB를 내리거나 내렸다 올리게 되면 사라집니다. 데이터가. 그러니까 일반 상용 DB에 있는 temporary 테이블하고 똑같습니다. 그래서 그렇게 정도 사용하고 있습니다. 
(질문자3)_요즘 MySQL쪽 개발 방향을 주로 보다 보면 마치 NoSQL 쓰는 것처럼 memcached 플러그인이나 아니면 그 외에 다른 종류의 기능들을 통해서 프로젝트 엔진에 직접 접근해서 훨씬 빠르게 데이터 액세스 하는 방법이 굉장히 많이 나오고 있는데 혹시 Neople에서도 그런 종류의 기능들을 사용하고 있거나 사용하실 의향이 있는지.
(발표자)_실 그러한 기능을 쓰는 게 우리가 NoSQL에 있는 몽고 DB나 hadoop에 있는 샤딩 기능 자체가 너무 어렵고 직관적이지 않다 보니까 RDBMS쪽에 자동으로 분산되는 그런 기능을 쓰자라고 나왔는데요. 저한테 만약에 그런 부분을 도입한다 라고 하면 저 역시도 그 쪽을 쓸 것 같아요. 왜냐면 저희도 작년에 hadoop을 내부적으로 프로젝트를 해봤는데요. nosql big data의 가장 큰 문제는 샤딩이고요. 샤딩 된 데이터에서 데이터를 어떻게 꺼내올 거냐가 가장 큰 문제잖아요? 그래서 저희가 아직 구체적으로 계획을 잡고 있지는 않습니다. 그런데 만약에 저희 팀에서 빅데이터에 관련된 프로젝트를 진행해야 된다고 하면 작년 경험을 바탕으로 했을 때 가장 현실적이고 빠르게 할 수 있는 게 MySQL을 이용한 샤딩 기능이 아니겠나. 그렇게 되면 RDBMS 데이터로 적재가 되는 거 기 때문에 데이터 수집이 더 편하잖아요? 저희도 아마 그렇게 접근할 것 같습니다.
TITLE	TITLE	TITLE	TITLE
TITLE	TITLE	TITLE	TITLE
전체보기
