MariaDB는 오라클이 MySQL을 인수한 이후 MySQL 포크로 출발했지만, 시간이 지나면서 스스로의 길을 개척해왔다. 오픈소스 RDBMS인 MariaDB는 최근 몇 차례의 주요 개정판을 거치며 독자적인 기능을 추가하고 MySQL과의 호환성을 강화하는 한편 오라클 SQL 사용자가 마이그레이션을 고려할 만한 다양한 동작을 도입했다. 이번 기사에서는 MariaDB의 가장 강력하고 유용한 새로운 기능 몇 가지를 살펴본다.

옵트인 오라클 호환성

MariaDB는 오라클을 현재 상태 그대로 MariaDB로 더 쉽게 이식할 수 있도록 버전 10.3부터 꾸준히 오라클 호환 기능을 추가해왔다.

오라클 호환성은 옵트인 방식이다. 특정 SQL 문 집합에 대해 호환성을 활성화하려면 SET SQL_MODE='ORACLE' 명령을 실행하기만 하면 된다. 가능한 경우 기존 MariaDB 동작도 유지된다.

대부분의 오라클 호환 기능은 오라클 SQL 구문을 지원하는 데 주력하며, 특히 ANSI SQL 또는 MariaDB와의 차이점에 집중한다. 예를 들어 오라클 SQL에서는 CALL 키워드 대신 저장 프로시저 이름만으로 저장 프로시저를 호출할 수 있다.

그러나 최근 오라클 호환 모드의 변경 사항 중에는 구문뿐 아니라 내부 동작과 관련된 부분도 있다. MariaDB 12.0부터는 하나의 트리거가 여러 INSERT/UPDATE/DELETE 이벤트에서 실행될 수 있는데, 이는 수동으로 구현하기 어려운 오라클 SQL 기능이다.

MariaDB(회사)는 오라클 SQL DDL 내보내기 파일(실제 데이터가 아닌 데이터 정의만 포함)을 분석하고 MariaDB의 오라클 호환 모드에서 얼마나 잘 실행되는지를 평가하는 마이그레이션 툴도 제공한다.

AI 기능 : MCP 서버와 벡터 타입

AI 기능은 거의 모든 데이터 중심 소프트웨어 제품에 도입되고 있다. MariaDB도 마찬가지지만 AI 기능이 단순한 마케팅 수사가 아니라 실제 툴에 가깝다.

MariaDB 11.8은 텍스트 유사성에 대한 정보를 데이터베이스에 내장하기 위한 수단으로 네이티브 VECTOR 데이터 타입을 추가했다. 이를 통해 자연어 쿼리, 추천 시스템, RAG 솔루션, 범용 머신러닝 작업 등을 구축하기 위한 엔진으로 MariaDB를 활용할 수 있다. 이와 같은 작업의 상당 부분을 데이터베이스 내에서 직접 수행해서 외부 애플리케이션과의 왕복을 피할 수 있다.

최근에 추가된 또 다른 AI 기능은 MariaDB를 기존 AI 에이전트의 확장으로 만들어주는 기능이다. 모델 컨텍스트 프로토콜(MCP)은 LLM이 예를 들어 웹 검색과 같은 외부 툴과 상호작용하기 위한 공통된 방법을 제공한다. MariaDB는 이제 자체 MCP 서버 구성요소를 제공해서 LLM이 MariaDB 인스턴스를 대상으로 더 쉽게 질의할 수 있도록 한다. 또한 오픈AI, 제미나이, 개방형 허깅페이스 모델을 통해 임베딩을 사용해서 데이터베이스에 저장된 문서에 대한 시맨틱 검색을 수행하는 것도 가능하다.

더 많은 JSON 기능

NoSQL 데이터베이스는 개발자에게 JSON 문서로 정의된 개방형 스키마를 사용해 데이터를 저장할 자유를 제공했다. 이후 전통적인 SQL 데이터베이스도 자체적인 네이티브 JSON 기능을 추가해 기존 SQL의 정형적 스키마를 버리지 않으면서 NoSQL의 유연성을 얻을 수 있도록 했다.

MariaDB에는 JSON 형식의 텍스트를 허용하는 JSON 컬럼 타입이 있으며 JSON_VALID CHECK 제약 조건을 통해 자동으로 유효성을 검증할 수 있다. JSON 데이터가 엄격한 데이터 타입을 따르도록 하려면 특정 키에 대해 제약 조건을 추가하면 된다(예: key year는 항상 유효한 INTEGER여야 한다는 조건).

SELECT 쿼리는 다음과 같이 키를 기준으로 JSON 컬럼에서 데이터를 추출할 수 있다.

SELECT id, name, JSON_QUERY(attr, '$.dates.release') AS release_year FROM movies

값 기준 필터링도 가능하다.

SELECT id, name FROM movies WHERE JSON_VALUE(attr, '$.dates.release') = 1981

JSON을 대상으로 한 작업 성능을 더 높이려면 문서의 키에 매핑되는 가상 컬럼을 생성하고 이러한 가상 컬럼을 기반으로 인덱스를 구축하면 된다.

ALTER TABLE movies ADD COLUMN    release_year SMALLINT AS (JSON_VALUE(attr, '$.dates.release'));CREATE INDEX releaseyears ON movies(release_year);

JSON을 추출해 조작하지 않고 데이터를 수정할 수도 있다. JSON_INSERT(), JSON_ARRAY_APPEND(), JSON_REMOVE()를 사용하면 이와 같은 인플레이스 변환을 MariaDB 외부에서 수동으로 데이터를 다루는 방식보다 더 빠르고 안정적으로 수행할 수 있다.

확장된 옵티마이저 힌트

숙련된 데이터베이스 개발자는 쿼리 실행 방식을 세부적으로 제어할 수 있는 기능을 선호한다. MariaDB는 오래전부터 HIGH_PRIORITY와 FORCE INDEX. 같은 SELECT 문을 위한 힌트, 즉 “수정자(modifier)”를 제공해왔다.

MariaDB 12.0에서는 힌트를 전역, 그리고 특정 테이블이나 인덱스에 적용할 수 있는 방법으로 새로운 스타일의 옵티마이저 힌트가 도입됐다. 이러한 힌트는 /*+와 */ 구분자가 있는 인라인 주석 형식으로 사용된다.

확장된 힌트는 일상적으로 사용하는 기능은 아니다. 확장된 힌트가 강제로 활성화하거나 비활성화하는 동작은 일반적으로는 기본 상태에서도 잘 작동한다. 다만 특정 상황에서는 명시적으로 제어할 때 더 효과적이다. 예를 들어 여러 컬럼에 대해 인덱스 스캔을 수행할 때 INDEX_MERGE 힌트는 사용할 특정 특정 인덱스를 쿼리 옵티마이저에 알려준다. 이렇게 하면 인덱스가 많은 테이블에서, 또는 특정 쿼리를 처리할 복합 인덱스가 없는 상황에서 쿼리 속도를 높일 수 있다. 그러나 이러한 최적화가 실제 환경에서 이론대로 작동할 것이라고 막연히 전제하는 것은 금물이다. 쿼리 최적화와 함께 항상 EXPLAIN 문을 사용해서 실제 속도 개선이 있는지 확인하는 것이 좋다

성능뿐 아니라 문제 해결에 유용한 힌트도 있다. 예를 들어 MAX_EXECUTION_TIME() 힌트는 특정 밀리초가 지나면 쿼리를 중단할 수 있다. 이 힌트는 비정상적인 쿼리가 시스템을 점유하는 것을 방지하는 데 사용하거나 통제를 벗어나 실행되는 경향이 있는 기존 쿼리를 디버깅하는 과정에도 사용할 수도 있다.

새로운 XML 타입

아직 많은 역할을 하지는 않지만 미래 지향적인 개선 사항으로 MariaDB 12.3에서 도입된 XMLTYPE 컬럼 타입이 있다. 현재 이 타입이 하는 일은 최대 4GB 크기의 문자열을 허용하고 UPDATEXML 함수를 통해 XML의 선택적 대체를 가능하게 해주는 것이 전부다. XML을 검증하거나 스키마를 강제하는 특성은 현재로서는 없지만 향후 추가될 예정이며 오라클과 XMLTYPE의 기능적 호환성을 더 높이게 된다. 향후 확장을 위한 경로를 여는 역할이다.

아직 없는 기능

MariaDB는 MySQL과는 다른 독자적인 개발 경로를 개척하면서 동적 또는 가상 컬럼과 같이 MySQL에 없는 많은 기능을 도입했다. 그러나 그 반대도 사실이다. 일부 MySQL 기능은 적어도 아직은 MariaDB에 존재하지 않는다.

아직 없는 중요한 기능 중 하나는 MySQL 리소스 그룹으로, 제안은 된 상태지만 구현을 위해서는 여전히 작업이 필요하다. 또한 JSON에 대한 MySQL의 ‘패킹된(바이너리)’ 스토리지 형식과 같이 앞으로도 상호 호환되지 않을 가능성이 높은 기능도 있다.

또한 MariaDB와 MySQL은 전역 트랜잭션 ID에 대해 서로 다른, 호환되지 않는 방법을 사용하므로 MariaDB 서버를 MySQL 서버의 복제본으로 사용하는 것은 가능하지만 그 반대는 불가능하다. 긍정적인 면은 MySQL에서 MariaDB로 이전할 때 복제를 마이그레이션 전략으로 활용할 수 있다는 점이다. 단, 두 데이터베이스 버전이 서로 호환돼야 한다.|
dl-itworldkorea@foundryco.com