2015.07.27

기고 | MySQL의 8가지 단점

Peter Wayner | InfoWorld
MySQL은 설치가 간편하고 상대적으로 빠르며 다양한 기능을 지원한다. 유명한 오픈소스 프로젝트 중 하나이기도 하다. 하지만 직접 사용해 본 사람이라면 여러 가지 이유로 놀라움을 감추지 못했을 것이다. 이를테면 인터넷에서 쓸데 없는 것들만 모으고 아무런 시도도 하지 않는 기술처럼 여겨지기도 한다.

많은 이들이 선택하는 이 오픈소스 관계형 데이터베이스와 관련해 불편하거나 당황스러운 8가지 특성을 정리했다. 단 아래의 모든 이유가 비단 MySQL에만 국한된 것은 아니다. 일부는 일반적인 관계형 데이터베이스에 모두 적용되는 이야기이다.

하지만 관계형 데이터베이스와 MySQL에 대해 명확하게 생각하지 않는다면 1990년대에 영원히 갇히게 될지도 모른다. 쌓기 위해서는 먼저 무너뜨릴 필요가 있다. (또는 이런 목록을 작성할 수 있을 정도로 오래 되지 않은 새로운 데이터베이스로 전환해야 할 필요가 있을 것이다.)



깊숙이 자리 잡은 버그와 특이함
대형 소프트웨어 패키지는 버그가 있게 마련이다. 하지만 좀 더 깊이 파보면 MySQL의 버그는 고질적이다. NULL이 늘 언제나 동일하게 동작하거나 외부 키 제약이 강제되거나 자동 증가가 올바르게 진행되는지 알 수 없기 때문에 주의해야 한다.

수십 가지의 작은 문제들이 존재하며 이런 문제가 항상 해결되는 것은 아니다. 이 때문에 사람들이 이와 같은 갓차(gotcha) 리스트를 유지하는 것이다. MySQL이 상시 버그 보고 시스템을 유지하는 점만 보아도 문제가 실제로 존재한다는 사실을 알 수 있다. 다른 사람들도 같은 불만감을 느끼고 있다.

관계형 테이블의 비유연성
테이블은 원칙을 제공하며 원칙은 좋은 것이다. 하지만 프로그래머가 강제로 데이터를 조작하거나 스키마(Schema)로 정의한 불가변 행에 데이터를 넣을 때는 그렇지 못하다.

NoSQL이 인기를 얻고 있는 이유 중 하나는 프로그래머가 상황에 따라 데이터 모델을 개선할 수 있는 유연성 때문이다. 주소에 1줄을 추가해야 하는 경우 NoSQL 문서에 손쉽게 추가할 수 있다. 누가 무엇을 알고 있는지에 관해 새로운 블록을 추가하고 싶은 경우에도 문서 모델은 데이터 자체를 있는 그대로 수용할 준비가 되어 있다.

우편번호가 모두 정수로 저장되어 있는 테이블을 구축한다고 생각해 보자. 매우 효율적이며 규칙도 잘 시행한다. 그리고 누군가 하이픈이 들어 있는 9자리 우편번호를 보낸다. 또는 캐나다의 고객이 글자가 섞여 있는 우편번호를 보내올 수 있다.

그러면 모든 것이 엉망이 된다. 상사는 수 시간 이내에 웹 사이트의 정상 동작을 원한다. 솔루션을 다시 설계할 시간이 없다. 이 때 프로그래머는 무엇을 할까? 캐나다의 우편번호를 Base64 번호로 취급하거나 기본 10으로 다시 변환하는 핵(Hack)을 만들까? 아니면 실제 우편번호가 다른 곳에 있다는 것을 나타내는 특수 이스케이프(Escape) 부호가 있는 보조 테이블을 구성할까?

누가 알겠는가? 수십 가지의 핵(Hack)이 존재할 수 있으며 모두 위험하다. 하지만 문제는 시간이 부족하다는 것이다.

MySQL의 관계형 규칙 때문에 모든 사람이 솔직하고 신중해지지만 핵과 닷지(Dodge)를 통해 문제를 숨기는 것 밖에 다른 방도가 없을 수 있다.

JOIN
한 동안 컴퓨터 공학 분야에서는 데이터를 복수의 테이블로 분할하는 것이 최고라는 생각이 팽배했었다. 결과 테이블이 훨씬 작을 뿐 아니라 간결함을 제공했기 때문이다. 그러나 그런 원칙과 명쾌함의 대가는 JOIN 성명의 형태로 뒤따른다.

개발자들은 복잡한 JOIN 시퀀스를 구성하다가 절망을 맛본다. 그리고 스토리지 엔진은 JOIN을 효율적으로 풀어낼 최적의 방법을 찾아야 한다. 개발자들은 정교한 쿼리(Query)를 개발하고 데이터베이스가 이를 풀어낸다.

이 때문에 속도를 원하는 많은 개발자들이 이 엄청난 실험을 단념하고 자신의 테이블을 비정규화하고 있다. 항목을 분리하는 대신에 그들은 하나의 크고 방대한 테이블에 쑤셔 넣어 복잡성을 우회한다. 모든 것이 빠르며 서버의 메모리는 (그리 쉽게) 떨어지지 않는다.

오늘 날 디스크 용량은 저렴하다. 시장에는 8TB의 드라이브가 존재하며 더 큰 것들이 개발되고 있다. 사실 우리는 더 이상 JOIN 때문에 머리를 쥐어 뜯을 필요가 없다.

CIO의 프리미엄 콘텐츠입니다. 이 기사를 더 읽으시려면 개인정보 등록이 필요합니다. 이미 등록하신 분은 '본인확인'을 해주십시오.



2015.07.27

기고 | MySQL의 8가지 단점

Peter Wayner | InfoWorld
MySQL은 설치가 간편하고 상대적으로 빠르며 다양한 기능을 지원한다. 유명한 오픈소스 프로젝트 중 하나이기도 하다. 하지만 직접 사용해 본 사람이라면 여러 가지 이유로 놀라움을 감추지 못했을 것이다. 이를테면 인터넷에서 쓸데 없는 것들만 모으고 아무런 시도도 하지 않는 기술처럼 여겨지기도 한다.

많은 이들이 선택하는 이 오픈소스 관계형 데이터베이스와 관련해 불편하거나 당황스러운 8가지 특성을 정리했다. 단 아래의 모든 이유가 비단 MySQL에만 국한된 것은 아니다. 일부는 일반적인 관계형 데이터베이스에 모두 적용되는 이야기이다.

하지만 관계형 데이터베이스와 MySQL에 대해 명확하게 생각하지 않는다면 1990년대에 영원히 갇히게 될지도 모른다. 쌓기 위해서는 먼저 무너뜨릴 필요가 있다. (또는 이런 목록을 작성할 수 있을 정도로 오래 되지 않은 새로운 데이터베이스로 전환해야 할 필요가 있을 것이다.)



깊숙이 자리 잡은 버그와 특이함
대형 소프트웨어 패키지는 버그가 있게 마련이다. 하지만 좀 더 깊이 파보면 MySQL의 버그는 고질적이다. NULL이 늘 언제나 동일하게 동작하거나 외부 키 제약이 강제되거나 자동 증가가 올바르게 진행되는지 알 수 없기 때문에 주의해야 한다.

수십 가지의 작은 문제들이 존재하며 이런 문제가 항상 해결되는 것은 아니다. 이 때문에 사람들이 이와 같은 갓차(gotcha) 리스트를 유지하는 것이다. MySQL이 상시 버그 보고 시스템을 유지하는 점만 보아도 문제가 실제로 존재한다는 사실을 알 수 있다. 다른 사람들도 같은 불만감을 느끼고 있다.

관계형 테이블의 비유연성
테이블은 원칙을 제공하며 원칙은 좋은 것이다. 하지만 프로그래머가 강제로 데이터를 조작하거나 스키마(Schema)로 정의한 불가변 행에 데이터를 넣을 때는 그렇지 못하다.

NoSQL이 인기를 얻고 있는 이유 중 하나는 프로그래머가 상황에 따라 데이터 모델을 개선할 수 있는 유연성 때문이다. 주소에 1줄을 추가해야 하는 경우 NoSQL 문서에 손쉽게 추가할 수 있다. 누가 무엇을 알고 있는지에 관해 새로운 블록을 추가하고 싶은 경우에도 문서 모델은 데이터 자체를 있는 그대로 수용할 준비가 되어 있다.

우편번호가 모두 정수로 저장되어 있는 테이블을 구축한다고 생각해 보자. 매우 효율적이며 규칙도 잘 시행한다. 그리고 누군가 하이픈이 들어 있는 9자리 우편번호를 보낸다. 또는 캐나다의 고객이 글자가 섞여 있는 우편번호를 보내올 수 있다.

그러면 모든 것이 엉망이 된다. 상사는 수 시간 이내에 웹 사이트의 정상 동작을 원한다. 솔루션을 다시 설계할 시간이 없다. 이 때 프로그래머는 무엇을 할까? 캐나다의 우편번호를 Base64 번호로 취급하거나 기본 10으로 다시 변환하는 핵(Hack)을 만들까? 아니면 실제 우편번호가 다른 곳에 있다는 것을 나타내는 특수 이스케이프(Escape) 부호가 있는 보조 테이블을 구성할까?

누가 알겠는가? 수십 가지의 핵(Hack)이 존재할 수 있으며 모두 위험하다. 하지만 문제는 시간이 부족하다는 것이다.

MySQL의 관계형 규칙 때문에 모든 사람이 솔직하고 신중해지지만 핵과 닷지(Dodge)를 통해 문제를 숨기는 것 밖에 다른 방도가 없을 수 있다.

JOIN
한 동안 컴퓨터 공학 분야에서는 데이터를 복수의 테이블로 분할하는 것이 최고라는 생각이 팽배했었다. 결과 테이블이 훨씬 작을 뿐 아니라 간결함을 제공했기 때문이다. 그러나 그런 원칙과 명쾌함의 대가는 JOIN 성명의 형태로 뒤따른다.

개발자들은 복잡한 JOIN 시퀀스를 구성하다가 절망을 맛본다. 그리고 스토리지 엔진은 JOIN을 효율적으로 풀어낼 최적의 방법을 찾아야 한다. 개발자들은 정교한 쿼리(Query)를 개발하고 데이터베이스가 이를 풀어낸다.

이 때문에 속도를 원하는 많은 개발자들이 이 엄청난 실험을 단념하고 자신의 테이블을 비정규화하고 있다. 항목을 분리하는 대신에 그들은 하나의 크고 방대한 테이블에 쑤셔 넣어 복잡성을 우회한다. 모든 것이 빠르며 서버의 메모리는 (그리 쉽게) 떨어지지 않는다.

오늘 날 디스크 용량은 저렴하다. 시장에는 8TB의 드라이브가 존재하며 더 큰 것들이 개발되고 있다. 사실 우리는 더 이상 JOIN 때문에 머리를 쥐어 뜯을 필요가 없다.

CIO의 프리미엄 콘텐츠입니다. 이 기사를 더 읽으시려면 개인정보 등록이 필요합니다. 이미 등록하신 분은 '본인확인'을 해주십시오.

X