지난 며칠 동안 많은 분들이 최신 MySQL 5.6 릴리스에 대한 제 의견을 물어보셨습니다. 아직 뉴스를 보지 못하신 분들을 위해 Oracle 2년 만에 첫 번째 주요 MySQL 릴리스 발표. MySQL이 역사적으로 강세를 보였던 주요 시장에서 NoSQL이 빠르게 성장했기 때문에 오라클이 NoSQL의 약점을 해결하는 데 많은 관심을 집중한 것은 당연한 일입니다. MySQL 엔지니어링 부사장인 Tomas Ulin은 "MySQL은 두 데이터베이스의 장점을 결합할 수 있다"며 "더 이상 두 개의 데이터베이스가 필요하지 않다"고 말할 정도입니다.
관계형 기술이 모든 것을 할 수 있고 모든 요구 사항에 적합한 기술이라는 것이 지난 40년 동안의 데이터베이스 세계와 크게 다르지 않을 것이라는 것이 Tomas와 MySQL의 관점인 것 같습니다.
저희는 그렇게 생각하지 않습니다. 애플리케이션 개발자가 다양한 데이터베이스 기술을 사용할 수 있는 시대로 빠르게 이동하고 있으며, 특정 사용 사례와 요구사항에 적합한 데이터베이스를 선택할 것이라고 믿습니다. 각 기술에는 고유한 장단점이 있으며, 선택할 수 있는 절충안도 매우 다양합니다. 때로는 MySQL과 같은 관계형 기술이 더 적합할 수도 있습니다(관계형 기술이 사라질 것이라고는 생각하지 않습니다). Couchbase와 같은 문서 데이터베이스가 적합한 경우도 있습니다.
그렇기 때문에 MySQL 5.6이 NoSQL의 빠른 성장에 영향을 미치지 않을 것이라고 생각합니다. NoSQL이 급부상하고 있는 이유는 한두 가지 인기 있는 기능 때문이 아닙니다. 많은 앱 개발자가 현재 개발 중인 애플리케이션 유형에 대해 선호하는 근본적으로 다른 아키텍처 선택과 장단점을 제공했기 때문입니다. 사람들이 NoSQL에 대해 좋다고 말하는 것에 대한 응답으로 관계형 데이터베이스에 기능을 추가한다고 해서 이러한 근본적인 차이점이 바뀌지는 않습니다.
예를 들어 관계형 기술은 기본적으로 테이블, 행, 열로 이루어진 스키마 기반 기술입니다. 스키마 변경을 더 쉽고 빠르게 할 수 있도록 MySQL 5.6의 새로운 온라인 데이터 정의 언어(DDL)와 같은 기능을 추가한다고 해서 관계형 데이터베이스의 스키마가 없어지는 것은 아닙니다. 또한 많은 개발자가 관계형 데이터베이스의 테이블보다 문서 데이터베이스의 문서(객체)로 작업하는 것이 훨씬 더 직관적이고 생산적이라는 사실도 고려하지 않습니다. 따라서 이 기능은 근본적인 절충점 때문에 관계형 기술을 선택한 개발자에게는 도움이 될 수 있지만, 근본적인 절충점 때문에 문서(또는 다른) NoSQL 데이터베이스로 이동한 개발자의 물결을 늦추는 데는 아무런 도움이 되지 않을 것입니다.
마찬가지로 MySQL 5.6의 새로운 멤캐시드 API를 사용하면 개발자가 기존의 get 및 set API를 사용하여 데이터에 더 쉽게 액세스할 수 있지만, 구현은 표면적인 수준에 불과합니다. 저장되는 데이터는 여전히 스토리지 계층에서 테이블과 열에 매핑됩니다. 개발자는 여전히 이러한 API를 사용하기 전에 테이블 스키마를 정의해야 하므로 웹 애플리케이션에 필요한 스키마 유연성을 얻지 못합니다. 구조가 비정형이고 구조가 계속 바뀌는 데이터를 테이블과 열에 맞추기 위해 파쇄하는 것은 강제적이고 비효율적인 접근 방식입니다.
참고로, MySQL 팀이 오라클의 다른 부분과 보조를 맞추지 못하는 것 같다는 점이 궁금합니다. MySQL 팀은 MySQL이 모든 것을 할 수 있다고 확신하는 것 같지만, 오라클의 NoSQL 팀은 생각이 다른 것 같고 자체 NoSQL 제품을 통해 Couchbase, MongoDB, Cassandra와 같은 NoSQL 리더를 따라잡기 위해 바쁘게 움직이고 있습니다. 관계형 기술이 만능 기술이라면 오라클은 왜 자체 NoSQL 제품 개발에 그렇게 큰 투자를 하고 있는 것일까요?
불과 몇 년 전의 애플리케이션과는 매우 다른 요구 사항을 가진 완전히 새로운 애플리케이션이 등장하고 있습니다. 대부분 클라우드 기반이고, 동적으로 변화하는 수많은 사용자를 지원해야 하며, 엄청난 양의 데이터를 저장해야 하고, 급변하는 데이터 캡처 요구사항에 적응하고 수많은 반정형 및 비정형 데이터를 처리할 수 있는 매우 유연한 데이터 모델이 필요합니다. NoSQL 기술에 내재된 근본적으로 다른 아키텍처 결정은 쉬운 확장성, 일관되게 높은 성능, 유연한 데이터 모델의 장점(다른 모든 장단점과 함께)과 함께, 점점 더 많은 애플리케이션에 더 적합한 것으로 밝혀지고 있습니다.
그렇다고 해서 MySQL(또는 관계형 데이터베이스)이 사라지거나 향후 데이터베이스 업계에서 중요한 역할을 하지 않을 것이라는 의미는 아닙니다. 단지 개발자에게 선택의 폭이 넓어지고(항상 좋은 일입니다) 일부 매우 강력한 트렌드가 NoSQL 기술의 강점과 매우 잘 맞아떨어진다는 의미일 뿐입니다.
(SQL 계층 없이 스토리지 엔진에 액세스할 수 있는) 핸들러소켓은 두 세계를 연결하는 완벽한 NoSQL과 같은 다리였습니다. 기본 엔진의 트랜잭션 기능을 유지하면서 객체에 대한 더 빠른 액세스 속도를 제공하고자 하는 제품들의 간극을 메워줍니다. 오라클의 \"NoSQL\" 시도는 꽤 형편없습니다. 특수 데이터베이스에서 객체 저장소에 대한 매핑을 수동으로 생성/설정해야 하며, 이러한 특수 테이블은 특정 방식으로 정의해야 합니다. 이는 매우 제한적입니다.
핸들러 소켓을 사용하면 원하는 DB/테이블을 열고 실행하기만 하면 됩니다. 가장 큰 단점은? Handlersocket은 5.6에서 컴파일되지 않으며, 컴파일될 때까지는 Oracle이 InnoDB 수준에서 개선한 이점을 누릴 수 있는 방법이 없습니다.
또 다른 단점은 새로운 memcache nosql 인터페이스의 성능입니다. 5.6을 실행하는 제 박스에서는 초당 500,000행의 읽기를 처리합니다. 같은 박스에서 5.5를 사용하는 핸들러소켓은 동일한 데이터 프로파일에 대해 800,000개를 관리합니다. 오라클이 그냥 핸들러소켓을 채택하고 그 대신 실행했으면 좋았을 텐데요.