컬럼/인터뷰
제공 : 한빛 네트워크
저자 : Brian Aker
역자 : 홍창우
원문 : Brian Aker on post-Oracle MySQL
Brian Aker는 선이 오라클에 인수될 때 선 마이크로시스템즈와 결별하면서 MySQL 주요 개발일선에서 물러났다. 요즘은 MySQL 파생 프로젝트들 중의 하나인 Drizzle에서 일하고 있다. MySQL Conference & Expo 행사에 즈음하여 Oracle이 Sun을 산 목적(동기)과 NoSQL의 부상 등 몇 가지 주제에 대하여 Aker와 논의하였다.
선을 인수한 핵심 요인? 하드웨어:
Brian Aker: 시장에서 일어나는 상황들을 보다 보니 몇 가지 생각이 들더군요. IBM이 데이터센터 영역에서 Sun의 하드웨어를 밀어내고 그들의 P Series 로 대체해 왔습니다. 제 생각으로는 오라클에서 이걸보고 자문했을 겁니다. "IBM의 다음 행보는 무엇일까?" 간단합니다. IBM은 DB2와 나머지 소프트웨어 군들을 그 환경으로 밀어 넣기 시작할 겁니다. 그들이 성공할지 말지 저로선 지금 모르겠습니다. 제 추측으로는 Oracle이 확장성을 위한 하드웨어의 필요를 고려해 보았다면, 하드웨어 비즈니스에 뛰어들 필요성을 느꼈을 겁니다. 분명 Apple의 하드웨어에서의 이윤을 주시하고, Sun의 하드웨어 사업에서 같은 가능성을 보았을 겁니다. Sun이 소유한 다른 모든 것들도 분명 괜찮고 훌륭하지만, Oracle은 하드웨어 때문에 Sun을 인수한 거라고 확신합니다.
오라클과 MySQL 커뮤니티와의 관계:
BA: 전 오라클에서 아직 자신들이 무엇을 인수했고 어떤 인력을 확보했는지 알아내고 있는 중이라고 생각합니다. 지금까지 같이한 모든 인터페이스 작업들에 있어서 매우 우호적이었습니다. Drizzle 에서는 임베디드 버전으로 옮겨가고 있는 중이지만 아직도 InnoDB 플러그인을 사용하고 있습니다. 지금까지는 모든 것이 순조롭게 잘 진행되어 왔습니다. MySQL 생태계에는 MariaDB 와 다른 배포판 들이 있습니다. 그들은 Ubuntu가 Debian에 했던 것처럼 기존에 있는 걸 가지고 새로운 제품을 만들어 내고 있습니다. 하지만 본질적으로 완전히 같은 제품입니다. 제 생각으로는 MariaDB의 몇몇 패치들이 MySQL 쪽으로 거꾸로 유입되고 있거나 최소한 그런 징후를 몇 번 보였습니다. 그래서 지금으로서는 모든 것들이 앞으로도 그럴 것처럼 협조적인 것으로 보입니다.
NoSQL은 유행인가 아니면 큰 변수인가?
BA: "그냥 GDBM이나 Berkeley DB를 쓰자"고 하는 사람들이 있습니다. 그사람들이 근본적으로 이해하지 못하고 있는 것은 어느 정도 규모의 데이터가 되면 여러대의 컴퓨터를 다루어야 한다는 것입니다. 무한대로 확장할 수는 없다는 것이지요. 그런 대답은 어느 정도 이상 규모의 데이터를 다루기에는 모든 것들이 한 대의 컴퓨터로는 어렵다는 것에 대해 충분히 이해하지 못했기 때문에 나오는 것입니다. 한 대의 컴퓨터로 한계에 다다르면 여러 노드에 데이터를 분산시킬 수 있어야 하며 일종의 확장(Scaling) 솔루션이 필요합니다.
카산드라(Cassandra)와 비슷한 솔루션에 유일한 이슈는 데이터의 사용 패턴에 들어맞지 않는 경우 입니다. 데이터분석학 같은 경우가 해당됩니다. 그리고 여전히 "여러 상관적인 엔티티들에 걸쳐 쓸 수 있는 표현(방법)이 필요한" 경우가 있습니다. 명백히 값을 이용한 키를 사용하는 시스템이 해결할 수 없는 부분이죠. 이들 시스템에는 주어진 두 아이템의 관계에 대한 아무런 정보가 없습니다. 그럼 어떻게 될까요 ? MapReduce를 쓰는 것으로 결론지을 수도 있습니다. 만약 조악한 컴퓨터들을 많이 갖고 있고 응답 속도에 대해서 그다지 신경쓰지 않는다면 괘찮습니다. 구글 정도의 상당한 양의 데이터에 대하여 쿼리를 하다면 MapReduce는 괜찮은 솔루션입니다. 하지만 구글 정도의 데이터를 가지고 있는 회사는 많지가 않죠. 평균 10-20 G(기가) 정도의 데이터가 보통이죠. 20 G, 1-2 T(테라) 정도의 데이터 때문에 MapReduce 솔루션으로 옮긴다는건 말이 안되죠. MapReduce 와 NoSQL 솔루션을 작은 사이트에 적용하는 것이요 ? 그건 사람들이 적절한 도구를 선택할 줄 모르기 때문이죠.
MySQL과 위치 데이터:
BA: SQL은 임시적인 데이터에 대해 상당히 잘 동작합니다. 범위 데이터에 대해서도 아주 좋습니다. 하지만 오늘날의 위치 기반 데이터에 대해서는 상당히 취약하다고 말하고 싶습니다. 하지만, 아마 밖에서는 최고죠 ?여전히 전 누군가 위치 데이터에 대해서 진지하게 오랜 시간 고민하고 진정한 위치 정보 솔루션을 개발하기를 기다리고 있습니다. 전 SQL 데이터베이스 시스템이 미래의 위치기반 데이터에 대한 솔루션이라고 생각하지 않습니다. 위치 서비스는 지금 보다 훨씬 뛰어난 시스템을 필요로 합니다. 지금은 뒤죽박죽 어설픈 시스템밖에 없기 때문입니다.
MySQL의 미래:
BA: 아직 MySQL의 로드맵을 위한 시간이 한 번도 없었습니다. Sun에서 MySQL을 인수하기 전에도 시간만 질질 끌고 있었고 Sun에서는 MySQL을 비중있기 취급하지 않았기 때문에, MySQL의 자료구조(Canonical Tree)는 더욱 망가졌습니다. 전 MySQL 컨퍼런스에서 Oracle이 어떤 것을 발표할지 주시하고 있습니다. Oracle에서 지금의 5.5 계획을 정리하고 실질적인 로드맵을 가지고 나오기를 바랍니다. 아마 그다지 혁신적인 것은 아니겠지만, 사용자들의 시선을 끌 수 있는 안정적인 것일 거라고 생각합니다.
MySQL의 여러 버전들에 대해서 기대(excitement)가 많다는 것을 알 수 있는데, 이로 인하여 각기 다른 배포판들이 차별화되는 혁신이 이루어 질 수 있기를 바랍니다. 여러 MySQL 배포판들은 결국은 모두 각기 다른 갈래(folks)로 나누어 질 것입니다. 드리즐(Drizzle) 에서는 다른 종류의 플러그인이나 그 밖에 다른 것들을 개발 할 기회가 있다는 것이 좋습니다. 레플리케이션(replication) 시스템 그리고 다른 시스템과의 연동을 위한 많은 노력을 해 왔고, 지금은 Drizzle로 RapidMQ, Cassandra, Gearman, Voldemort, Memcached 그 외 다른 데이터베이스 시스템을 레플리케이션 연동할 수 있는 플러그인이 개발 되었습니다. 시작부터 플러그인이 가능하도록 설계된 레플리케이션 시스템의 출현은 어떤 기업에게는 완전히 판도를 뒤집는 일이 될 것입니다.
Drizzle의 미래요? 전부 오픈소스로 두고 커뮤니티에서 무엇을 선택할지 지켜 볼 겁니다. 앞으로는 데이터 버스 아키텍처에 좀 더 관심을 둘 생각입니다. 예를 들자면 Geographic Replication[1] 같은 것이 있겠죠. 과거에는 레이플리케이션이라는 것은 대부분 어떻게 규모를 확장(scale out)하느냐에 대한 것이었지만, 이제 달라졌습니다. 레플리케이션을 통해 확장을 하려는 것은 스스로 무덤을 파는 격입니다. 제가 정말로 바라는 건 데이터센터 간에 어떻게 데이터를 주고 받느냐 하는데 대해 사람들이 좀 더 관심을 가져주는 것이죠. 그리고 비공유(Shared-Noghing) 구조 시스템[2]에 대해서도 더 많은 연구가 이루어 졌으면 합니다. MySQL을 가지고 한두번 정도 시도가 있긴 했지만 아직까지 성공하지 못했습니다. 코드의 수준도 높지 못했고 쓰기도 어려웠기 때문이지요. 전 지금까지 개발된 어떤 시스템보다도 뛰어난 새로운 비공유 솔루션을 보게 될 거라고 생각합니다.
[1] Geographic Replication지리적으로 분산된 클러스터 간의 비동기 레플리케이션. 주로 재난 복구용으로 사용됨
[2] Shared-Nothing Architecture (SN)1986년 UC Berkeley Michael Stonebraker의 논문으로 공식적으로 처음 사용된 용어로. 반대되는 개념으로는 Shared-Disk, Shared-Everything 방식이 있다.
저자 : Brian Aker
역자 : 홍창우
원문 : Brian Aker on post-Oracle MySQL
Brian Aker는 선이 오라클에 인수될 때 선 마이크로시스템즈와 결별하면서 MySQL 주요 개발일선에서 물러났다. 요즘은 MySQL 파생 프로젝트들 중의 하나인 Drizzle에서 일하고 있다. MySQL Conference & Expo 행사에 즈음하여 Oracle이 Sun을 산 목적(동기)과 NoSQL의 부상 등 몇 가지 주제에 대하여 Aker와 논의하였다.
선을 인수한 핵심 요인? 하드웨어:
Brian Aker: 시장에서 일어나는 상황들을 보다 보니 몇 가지 생각이 들더군요. IBM이 데이터센터 영역에서 Sun의 하드웨어를 밀어내고 그들의 P Series 로 대체해 왔습니다. 제 생각으로는 오라클에서 이걸보고 자문했을 겁니다. "IBM의 다음 행보는 무엇일까?" 간단합니다. IBM은 DB2와 나머지 소프트웨어 군들을 그 환경으로 밀어 넣기 시작할 겁니다. 그들이 성공할지 말지 저로선 지금 모르겠습니다. 제 추측으로는 Oracle이 확장성을 위한 하드웨어의 필요를 고려해 보았다면, 하드웨어 비즈니스에 뛰어들 필요성을 느꼈을 겁니다. 분명 Apple의 하드웨어에서의 이윤을 주시하고, Sun의 하드웨어 사업에서 같은 가능성을 보았을 겁니다. Sun이 소유한 다른 모든 것들도 분명 괜찮고 훌륭하지만, Oracle은 하드웨어 때문에 Sun을 인수한 거라고 확신합니다.
오라클과 MySQL 커뮤니티와의 관계:
BA: 전 오라클에서 아직 자신들이 무엇을 인수했고 어떤 인력을 확보했는지 알아내고 있는 중이라고 생각합니다. 지금까지 같이한 모든 인터페이스 작업들에 있어서 매우 우호적이었습니다. Drizzle 에서는 임베디드 버전으로 옮겨가고 있는 중이지만 아직도 InnoDB 플러그인을 사용하고 있습니다. 지금까지는 모든 것이 순조롭게 잘 진행되어 왔습니다. MySQL 생태계에는 MariaDB 와 다른 배포판 들이 있습니다. 그들은 Ubuntu가 Debian에 했던 것처럼 기존에 있는 걸 가지고 새로운 제품을 만들어 내고 있습니다. 하지만 본질적으로 완전히 같은 제품입니다. 제 생각으로는 MariaDB의 몇몇 패치들이 MySQL 쪽으로 거꾸로 유입되고 있거나 최소한 그런 징후를 몇 번 보였습니다. 그래서 지금으로서는 모든 것들이 앞으로도 그럴 것처럼 협조적인 것으로 보입니다.
NoSQL은 유행인가 아니면 큰 변수인가?
BA: "그냥 GDBM이나 Berkeley DB를 쓰자"고 하는 사람들이 있습니다. 그사람들이 근본적으로 이해하지 못하고 있는 것은 어느 정도 규모의 데이터가 되면 여러대의 컴퓨터를 다루어야 한다는 것입니다. 무한대로 확장할 수는 없다는 것이지요. 그런 대답은 어느 정도 이상 규모의 데이터를 다루기에는 모든 것들이 한 대의 컴퓨터로는 어렵다는 것에 대해 충분히 이해하지 못했기 때문에 나오는 것입니다. 한 대의 컴퓨터로 한계에 다다르면 여러 노드에 데이터를 분산시킬 수 있어야 하며 일종의 확장(Scaling) 솔루션이 필요합니다.
카산드라(Cassandra)와 비슷한 솔루션에 유일한 이슈는 데이터의 사용 패턴에 들어맞지 않는 경우 입니다. 데이터분석학 같은 경우가 해당됩니다. 그리고 여전히 "여러 상관적인 엔티티들에 걸쳐 쓸 수 있는 표현(방법)이 필요한" 경우가 있습니다. 명백히 값을 이용한 키를 사용하는 시스템이 해결할 수 없는 부분이죠. 이들 시스템에는 주어진 두 아이템의 관계에 대한 아무런 정보가 없습니다. 그럼 어떻게 될까요 ? MapReduce를 쓰는 것으로 결론지을 수도 있습니다. 만약 조악한 컴퓨터들을 많이 갖고 있고 응답 속도에 대해서 그다지 신경쓰지 않는다면 괘찮습니다. 구글 정도의 상당한 양의 데이터에 대하여 쿼리를 하다면 MapReduce는 괜찮은 솔루션입니다. 하지만 구글 정도의 데이터를 가지고 있는 회사는 많지가 않죠. 평균 10-20 G(기가) 정도의 데이터가 보통이죠. 20 G, 1-2 T(테라) 정도의 데이터 때문에 MapReduce 솔루션으로 옮긴다는건 말이 안되죠. MapReduce 와 NoSQL 솔루션을 작은 사이트에 적용하는 것이요 ? 그건 사람들이 적절한 도구를 선택할 줄 모르기 때문이죠.
MySQL과 위치 데이터:
BA: SQL은 임시적인 데이터에 대해 상당히 잘 동작합니다. 범위 데이터에 대해서도 아주 좋습니다. 하지만 오늘날의 위치 기반 데이터에 대해서는 상당히 취약하다고 말하고 싶습니다. 하지만, 아마 밖에서는 최고죠 ?여전히 전 누군가 위치 데이터에 대해서 진지하게 오랜 시간 고민하고 진정한 위치 정보 솔루션을 개발하기를 기다리고 있습니다. 전 SQL 데이터베이스 시스템이 미래의 위치기반 데이터에 대한 솔루션이라고 생각하지 않습니다. 위치 서비스는 지금 보다 훨씬 뛰어난 시스템을 필요로 합니다. 지금은 뒤죽박죽 어설픈 시스템밖에 없기 때문입니다.
MySQL의 미래:
BA: 아직 MySQL의 로드맵을 위한 시간이 한 번도 없었습니다. Sun에서 MySQL을 인수하기 전에도 시간만 질질 끌고 있었고 Sun에서는 MySQL을 비중있기 취급하지 않았기 때문에, MySQL의 자료구조(Canonical Tree)는 더욱 망가졌습니다. 전 MySQL 컨퍼런스에서 Oracle이 어떤 것을 발표할지 주시하고 있습니다. Oracle에서 지금의 5.5 계획을 정리하고 실질적인 로드맵을 가지고 나오기를 바랍니다. 아마 그다지 혁신적인 것은 아니겠지만, 사용자들의 시선을 끌 수 있는 안정적인 것일 거라고 생각합니다.
MySQL의 여러 버전들에 대해서 기대(excitement)가 많다는 것을 알 수 있는데, 이로 인하여 각기 다른 배포판들이 차별화되는 혁신이 이루어 질 수 있기를 바랍니다. 여러 MySQL 배포판들은 결국은 모두 각기 다른 갈래(folks)로 나누어 질 것입니다. 드리즐(Drizzle) 에서는 다른 종류의 플러그인이나 그 밖에 다른 것들을 개발 할 기회가 있다는 것이 좋습니다. 레플리케이션(replication) 시스템 그리고 다른 시스템과의 연동을 위한 많은 노력을 해 왔고, 지금은 Drizzle로 RapidMQ, Cassandra, Gearman, Voldemort, Memcached 그 외 다른 데이터베이스 시스템을 레플리케이션 연동할 수 있는 플러그인이 개발 되었습니다. 시작부터 플러그인이 가능하도록 설계된 레플리케이션 시스템의 출현은 어떤 기업에게는 완전히 판도를 뒤집는 일이 될 것입니다.
Drizzle의 미래요? 전부 오픈소스로 두고 커뮤니티에서 무엇을 선택할지 지켜 볼 겁니다. 앞으로는 데이터 버스 아키텍처에 좀 더 관심을 둘 생각입니다. 예를 들자면 Geographic Replication[1] 같은 것이 있겠죠. 과거에는 레이플리케이션이라는 것은 대부분 어떻게 규모를 확장(scale out)하느냐에 대한 것이었지만, 이제 달라졌습니다. 레플리케이션을 통해 확장을 하려는 것은 스스로 무덤을 파는 격입니다. 제가 정말로 바라는 건 데이터센터 간에 어떻게 데이터를 주고 받느냐 하는데 대해 사람들이 좀 더 관심을 가져주는 것이죠. 그리고 비공유(Shared-Noghing) 구조 시스템[2]에 대해서도 더 많은 연구가 이루어 졌으면 합니다. MySQL을 가지고 한두번 정도 시도가 있긴 했지만 아직까지 성공하지 못했습니다. 코드의 수준도 높지 못했고 쓰기도 어려웠기 때문이지요. 전 지금까지 개발된 어떤 시스템보다도 뛰어난 새로운 비공유 솔루션을 보게 될 거라고 생각합니다.
[1] Geographic Replication지리적으로 분산된 클러스터 간의 비동기 레플리케이션. 주로 재난 복구용으로 사용됨
[2] Shared-Nothing Architecture (SN)1986년 UC Berkeley Michael Stonebraker의 논문으로 공식적으로 처음 사용된 용어로. 반대되는 개념으로는 Shared-Disk, Shared-Everything 방식이 있다.
TAG :
최신 콘텐츠