2019.06.19

구식 데이터베이스에서 가능한 10 가지 트릭

Martin Heller | InfoWorld
이미 보유한 구식 오라클, SQL 서버, MySQL, 포스트그레SQL 데이터베이스에 숨겨진 ‘NoSQL’ 기능이 꽤나 강력할 수 있다. 어쩌면 꽤 놀랄지도 모른다. 



NoSQL 데이터베이스, 분산 데이터베이스, 데이터 웨어하우스 및 GPU 가속화 데이터베이스에 대해 열광하고 있는가? 그러나 어쩌면 기존의 관계형 데이터베이스가 여전히 핵심적인 정보를 저장하고 제공한다는 사실을 간과할 수 있겠다. 

오라클 데이터베이스, 마이크로소프트 SQL 서버, MySQL/마리아DB 및 포스트그레(Postgre)SQL은 그 시작이 1980년대까지 거슬러 올라가지만, 모두 여전히 활발하게 개발되고 있다. 단지 버그를 고치고 성능을 조정하는데 그치지 않는다.

이 기사에서는 기존의 SQL 데이터베이스가 개선되고 있는 여러 방식에 대해 살펴본다. 일부는 데이터를 사용하기 위한 색인 및 검색 기능과 함께 여러 종류의 데이터를 지원하는 것과 관련이 있다. 또 다른 것은 자주 사용하는 테이블들에 대한 엑세스 속도를 높이는 것에 초점을 맞춘다. 데이터베이스를 자신의 테이블, 단일 서버 및 SQL 쿼리를 넘어서 확장하는 것과 관련된 것들도 있다. 

전문(full-text) 검색
표준적인 관계형 데이터베이스 인덱스는 성능상의 이유로 간략한 필드나 심지어 해시를 사용하는 경향이 있다. 전문 검색은 다르다. 전문 검색은 일반적으로 단어, 기록 및 오프셋 위치의 뒤집어진 목록과 같이 다른 종류의 인덱스로 다뤄진다. 종종 무시되는 제외어의 목록과 각 단어의 다른 형태를 생성하기 위한 추출 알고리즘이 있다. 일부 전문 검색 엔진은 불리안(Boolean) 작업, 퍼지 검색 또는 인접 검색을 지원한다.

오라클 데이터베이스, SQL 서버, MySQL/마리아DB 및 포스트그레SQL은 (MySQL 용어를 사용하자면) 모두 FULLTEXT 인덱스가 있는 CHAR, VARCHAR 또는 TEXT 열과 같이 특별히 지정된 텍스트 필드에 대한 전문 검색을 제공한다. 또한 엘라스틱서치(Elasticsearch)나 솔라(Solr)와 같은 외부 전문 검색 엔진을 사용하여 데이터베이스에서 텍스트를 색인화하고 검색할 수 있다. 

제이슨(JSON) 데이터
제이슨(JavaScript Object Notation, JSON)은 웹용 자바스크립트가 각광을 받으면서 유명해졌으며, NoSQL 문서 데이터베이스의 표준 데이터 포맷 중 하나가 되었다. 그러자 뒤쳐지지 않기 위해서 많은 SQL 데이터베이스들은 제이슨에 대한 지원을 추가했으며, 반구조화 되어 있고 때로는 계층적인 제이슨 문서를 검색하는 데 필요한 부가적인 구문도 추가했다. 물론 각 데이터베이스들은 해당하는 제이슨 지원도 추가했다.  

예를 들어 SQL 서버에서는 텍스트 필드에서 제이슨 값을 명시적으로(explicitly) 조회할 수 있으며, 제이슨 문서를 테이블로 변환할 수도 있다. 텍스트 필드에 제약 조건을 추가하여 텍스트 필드가 유효한 제이슨으로 포맷되도록 할 수도 있다. 반면에, 포스트그레SQL은 제이슨 기능과 오퍼레이터뿐만 아니라 명시적인 제이슨 유형도 가지고 있다.

XML 데이터
제이슨과 마찬가지로 XML은 반구조화 된 데이터 유형이다. 지금은 많은 애플리케이션에서 제이슨으로 대체되어가고는 있지만, 웹 서비스와 AJAX 웹 콜백이 개발된 시대에는 널리 활용되었던 데이터 교환 형식이었다. XML 스키마는 XML 문서에 어떤 구조를 부여할 수 있으며, XPath는 XML 문서에서 탐색을 위한 경로식을 사용한다. 그리고 XSLT 변환 언어는 나름의 용도가 있는데, 예를 들자면 XML 데이터에서 웹 페이지를 생성한다.

앞서 언급한 모든 관계형 데이터베이스들은 어느 정도 XML 데이터를 지원한다. 아직 개발되지 않은 애플리케이션의 경우 제이슨보다 XML을 선택하는 경우가 많을 수도 있겠지만, XML 문서를 중심으로 구축된 기존 애플리케이션의 경우에는 XML을 관계 테이블에 저장할 수 있는 기능이 유용할 수 있다.

지리공간(Geospatial) 데이터
기하학 및 지리적 정보가 숫자 유형에 적합할 것처럼 보일 지도 모르지만, 공간 데이터에 대해 자주 실행되는 쿼리의 종류는 2차원 데이터를 인식하는 인덱스를 필요로 한다. 이것은 표준 B-트리 기능을 벗어난다. 

예를 들어, 두 공항 사이의 거리, LA 공항에서 가장 가까운 이웃 공항, 시카고에서 비즈니스 미팅 장소와 가장 가까운 호텔, 또는 맨해튼의 경계 안에 택시가 있는지 등등을 알고 싶은 경우가 있을 수 있다. 이러한 쿼리를 처리하기 위해서 R-트리, SP-GiST, 쿼드트리 또는 UB-트리 인덱스가 필요할 수도 있다. 

포스트그레SQL을 위한 포스트GIS와 같이 일부는 추가 기능을 필요로 하지만, 앞서 언급한 모든 관계형 데이터베이스는 공간 정보 및 인덱스를 지원한다. 구현 상세 내역은 종종 다르지만, 일반적으로 개방형 공간 컨소시엄 단순 기능(Open Geospace Consortium Simple Features) 사양 및 SQL/MM 공간 ISO/IEC 표준을 준수한다.

인메모리(In-memory) 테이블
인메모리 캐싱은 지원하지만 순수한 인메모리 테이블은 아닌 PostgreSQL를 제외하면, 앞서 언급한 모든 관계형 데이터베이스는 메모리에 테이블을 만들 수 있다. 인메모리 테이블은 주로 읽기가 매우 많은 시나리오에서 해당 테이블의 정보 작업 속도를 크게 향상시킨다. 때때로 언급되는 속도 개선치는 30배지만, 그것은 데이터베이스에 사용될 수 있는 다양한 종류의 디스크를 고려하지 않는 근사치에 불과하다. 

종종 인메모리 테이블에 적용되는 한도가 있다. 가장 중요한 것은 그 테이블을 고정하기에 충분한 램의 요구사항이다. 이 요구사항은 대신 캐싱과 조인스를 위해 사용될 수 있었던 것들이다. 그 다음으로는 특정 데이터베이스와 엔진에 대한 제한이 있다. 

MySQL MEMORY 스토리지 엔진은 일시적이고 내구성이 없으며(MySQL 서버가 중단되거나 중지될 때 사라짐), 트랜잭션·외래키·지리적 유형· 전문 검색 색인화 등이 부족하고, 쓰기가 많은 경우 제대로 작동하지 않으며, 테이블 수준에서 잠김이 발생하고, 파티션이 불가능하다. MySQL NDB 클러스터 엔진은 이러한 제약 조건 중 일부를 제거하지만, MySQL 데몬의 특수 버전을 실행해야 하며 클러스터에서 여러 종류의 노드가 활성화되어야 한다. 

SQL 서버 인메모리 OLTP는 메모리에 최적화된 테이블을 사용하는데, 내구성이 뛰어나고 트랜잭션을 지원한다. 또한, 종종 임시 테이블 대신 일시적인 데이터에 사용되는 내구성이 없는 테이블도 사용한다. 게다가 기본적으로 컴파일 된 T-SQL 모듈을 사용하여 작업을 처리하는 데 필요한 CPU 사이클을 줄임으로써 개별 트랜잭션에 소요되는 시간을 더욱 단축한다. SQL 서버 인메모리 OLTP 테이블은 쿼리 및 트랜잭션에서 디스크 기반 테이블과 결합될 수 있다. 

오라클 데이터베이스 인메모리는 실시간 애널리틱스(OLAP) 및 혼합 워크로드(HTAP)의 성능을 크게 향상시킨다. 인메모리 컬럼 스토어(IM 컬럼 스토어)는 오라클 데이터베이스 인메모리의 핵심 기능이다.

외부 데이터 소스
SQL 서버의 최근 버전들은 데이터베이스 자체 테이블의 외부에 있는 데이터 소스를 쿼리하는 메커니즘을 가지고 있다. 하둡, 블롭(Blob) 스토리지, 다른 관계형 데이터베이스 또는 샤드 맵 관리자에서 EXTERNAL DATA SOURCE를 생성할 수 있다. 그런 다음 데이터 로드 및 쿼리용 외부 데이터 소스에 대해 폴리베이스 또는 엘라스틱 데이터베이스 쿼리(애저 SQL 데이터베이스 v12+)를 사용할 수 있다.

포스트그레SQL 외래 데이터 래퍼로 포스트그레SQL 쿼리는 폭넓은 원격 데이터 소스에 대해 실행이 가능하다. 그 범위가 다른 SQL 데이터베이스, NoSQL 데이터베이스 및 빅 데이터 플랫폼에서 플랫 파일에 이르기까지 매우 넓다. 외래 데이터 래퍼는 SQL/MED(SQL Management of External Data) 표준을 따른다. 

빅 데이터 클러스터
마이크로소프트 SQL 서버 빅데이터 클러스터는 SQL 서버 2019 미리 보기를 시작으로 쿠버네티스에서 실행 중인 SQL서버, 스파크 및 HDFS 컨테이너의 확장 가능한 클러스터를 배치할 수 있도록 해준다. 이러한 구성요소는 Transact-SQL(PolyBase를 통해)나 스파크에서 빅데이터를 나란히 읽고, 쓰고, 처리하여, 고부가가치 관계 데이터를 대용량 빅데이터와 결합하고 분석할 수 있게 한다. 

오라클은 오라클 빅데이터 클라우드 서비스오라클 빅데이터 어플라이언스 온 프레미스에서 비슷한 기능을 제공한다.

복제본 읽기
MySQL, 마리아DB 및 포스트그레SQL은 모두 복제본 읽기 기능을 제공한다. 복제본 읽기는 직접적으로 읽기 처리율을 증가시키지만, 읽기/쓰기 서버의 읽기 로드를 줄임으로써 간접적으로 쓰기 성능도 높일 수 있다.

MySQL/마리아DB는 로그 파일 및 GTID 기반, 비동기식, 인메모리 NDB 클러스터를 사용하는 동기식, 반동기식 및 지연식, 문장 기반, 행 기반 및 혼합 기반 등의 다양한 종류의 복제본을 지원한다. 포스트그레SQL에는 다양한 복제 솔루션이 있다. 

아마존 오로라는 MySQL 및 포스그레SQL용 복제본 읽기 계획을 자체적으로 구현하고 있다. 오로라에서는 15개까지의 복제본이 가능하며, 동기화 지연시간은 20밀리초 미만이다.  

SQL 서버는 액티브-액티브 클러스터에서 보조 복제본 읽기를 지원한다. 오라클 데이터베이스는 읽기 전용 테이블 스냅샷을 사용하는 기본적인 한 방향 읽기 전용 복제 환경을 지원하고, 오라클 엔터프라이즈는 복제된 데이터베이스 시스템 전체에서 애플리케이션이 테이블 복제본을 업데이트할 수 있도록 하여 기본적인 읽기 전용 복제 기능을 확장시킨 고급 복제 기능을 지원한다.

샤딩(Sharding)
샤딩은 서버 간에 데이터를 나누는 방법이다. 수직 샤딩은 예를 들어 한 서버에는 인벤토리를 배치하고 다른 서버에는 주문을 넣고, 그리고 세 번째 서버에는 분석을 위해 집계된 테이블을 두는 등의 서로 다른 테이블의 분산과 관련이 있다. 

그것은 당신이 여러 서버의 테이블에 가입해야 할 때에만 문제가 된다. 수평 샤딩은 알파벳순으로 분할된 컨벤션의 등록 스테이션처럼 서버 간에 개별 테이블을 나누는 것과 관련된다. 수동 수평 샤딩은 골칫거리지만, 다행히도 자동 수평 샤딩을 위한 몇 가지 선택사항이 있다. 

시투스(Citus)는 프로트그레SQL의 자동 수평 샤딩을 한다. 시투스는 또한 데이터를 보관하는 작업자 노드에 대한 프런트엔드로써 코디네이터 노드도 제공한다.

마이크로소프트 에저 SQL 데이터베이스 v12는 자동 수평 샤딩을 위한 탄력적인 데이터베이스 샤드 맵을 지원한다. 또한, 수직 샤딩를 위한 데이터베이스 간 쿼리도 지원한다.

몇 가지 방법을 통해 아마존 RDS를 이용하여 MySQL 및 지원되는 다른 데이터베이스를 샤딩할 수 있다. 일반적으로 복제본 읽기를 사용하여 복제본을 만든 다음 복제본을 새 샤드로 삼을 수 있다. 오로라에는 이러한 용도의 clone database 명령이 있다. 복제 후 파티션 키 매핑 테이블에 따라 해당 샤드에 사용되지 않는 복제된 데이터는 삭제가 가능하다. 

SQL을 벗어난 보관 절차
역사적으로 모든 관계형 데이터베이스는 SQL 서버용 Transact-SQL 및 오라클용 PL/SQL과 같은 보관 절차를 위한 고유한 SQL 확장을 가지고 있었다. 최근 몇 년간 관계형 데이터베이스는 프로그래밍 언어 및 머신러닝 능력과 통합되어 왔다. 이것의 초기 예로는 오라클 데이터베이스에서 PL/SQL의 부속물로 실행되는 자바(Java)가 있다. 그 이후로 C, C++, C#, 펄(Perl), PHP, 파이썬(Python), R 언어 데이터베이스 확장이 등장했다. 

2009년 무렵 NoSQL 데이터베이스의 도입으로 SQL 호환성과 강한 일관성을 포기하는 대신 웹 애플리케이션을 위한 확장성이 높고 가용성이 좋은 데이터베이스의 필요성이 반영됐다. 지난 몇 년 동안 ‘고전적인’ SQL 데이터베이스는 일관성이나 호환성을 희생하지 않고서도 확장성과 가용성을 개선하기 위한 많은 옵션을 추가해왔다. 

해당 ‘NoSQL’ 작업을 위해 구식 SQL 데이터베이스를 무시하기 전에 문서를 확인하도록 하자. 양쪽 모두에서 최상의 결과를 얻을 지도 모른다. 

* Martin Heller는 인포월드 객원 편집자이자 리뷰어다. ciokr@idg.co.kr



2019.06.19

구식 데이터베이스에서 가능한 10 가지 트릭

Martin Heller | InfoWorld
이미 보유한 구식 오라클, SQL 서버, MySQL, 포스트그레SQL 데이터베이스에 숨겨진 ‘NoSQL’ 기능이 꽤나 강력할 수 있다. 어쩌면 꽤 놀랄지도 모른다. 



NoSQL 데이터베이스, 분산 데이터베이스, 데이터 웨어하우스 및 GPU 가속화 데이터베이스에 대해 열광하고 있는가? 그러나 어쩌면 기존의 관계형 데이터베이스가 여전히 핵심적인 정보를 저장하고 제공한다는 사실을 간과할 수 있겠다. 

오라클 데이터베이스, 마이크로소프트 SQL 서버, MySQL/마리아DB 및 포스트그레(Postgre)SQL은 그 시작이 1980년대까지 거슬러 올라가지만, 모두 여전히 활발하게 개발되고 있다. 단지 버그를 고치고 성능을 조정하는데 그치지 않는다.

이 기사에서는 기존의 SQL 데이터베이스가 개선되고 있는 여러 방식에 대해 살펴본다. 일부는 데이터를 사용하기 위한 색인 및 검색 기능과 함께 여러 종류의 데이터를 지원하는 것과 관련이 있다. 또 다른 것은 자주 사용하는 테이블들에 대한 엑세스 속도를 높이는 것에 초점을 맞춘다. 데이터베이스를 자신의 테이블, 단일 서버 및 SQL 쿼리를 넘어서 확장하는 것과 관련된 것들도 있다. 

전문(full-text) 검색
표준적인 관계형 데이터베이스 인덱스는 성능상의 이유로 간략한 필드나 심지어 해시를 사용하는 경향이 있다. 전문 검색은 다르다. 전문 검색은 일반적으로 단어, 기록 및 오프셋 위치의 뒤집어진 목록과 같이 다른 종류의 인덱스로 다뤄진다. 종종 무시되는 제외어의 목록과 각 단어의 다른 형태를 생성하기 위한 추출 알고리즘이 있다. 일부 전문 검색 엔진은 불리안(Boolean) 작업, 퍼지 검색 또는 인접 검색을 지원한다.

오라클 데이터베이스, SQL 서버, MySQL/마리아DB 및 포스트그레SQL은 (MySQL 용어를 사용하자면) 모두 FULLTEXT 인덱스가 있는 CHAR, VARCHAR 또는 TEXT 열과 같이 특별히 지정된 텍스트 필드에 대한 전문 검색을 제공한다. 또한 엘라스틱서치(Elasticsearch)나 솔라(Solr)와 같은 외부 전문 검색 엔진을 사용하여 데이터베이스에서 텍스트를 색인화하고 검색할 수 있다. 

제이슨(JSON) 데이터
제이슨(JavaScript Object Notation, JSON)은 웹용 자바스크립트가 각광을 받으면서 유명해졌으며, NoSQL 문서 데이터베이스의 표준 데이터 포맷 중 하나가 되었다. 그러자 뒤쳐지지 않기 위해서 많은 SQL 데이터베이스들은 제이슨에 대한 지원을 추가했으며, 반구조화 되어 있고 때로는 계층적인 제이슨 문서를 검색하는 데 필요한 부가적인 구문도 추가했다. 물론 각 데이터베이스들은 해당하는 제이슨 지원도 추가했다.  

예를 들어 SQL 서버에서는 텍스트 필드에서 제이슨 값을 명시적으로(explicitly) 조회할 수 있으며, 제이슨 문서를 테이블로 변환할 수도 있다. 텍스트 필드에 제약 조건을 추가하여 텍스트 필드가 유효한 제이슨으로 포맷되도록 할 수도 있다. 반면에, 포스트그레SQL은 제이슨 기능과 오퍼레이터뿐만 아니라 명시적인 제이슨 유형도 가지고 있다.

XML 데이터
제이슨과 마찬가지로 XML은 반구조화 된 데이터 유형이다. 지금은 많은 애플리케이션에서 제이슨으로 대체되어가고는 있지만, 웹 서비스와 AJAX 웹 콜백이 개발된 시대에는 널리 활용되었던 데이터 교환 형식이었다. XML 스키마는 XML 문서에 어떤 구조를 부여할 수 있으며, XPath는 XML 문서에서 탐색을 위한 경로식을 사용한다. 그리고 XSLT 변환 언어는 나름의 용도가 있는데, 예를 들자면 XML 데이터에서 웹 페이지를 생성한다.

앞서 언급한 모든 관계형 데이터베이스들은 어느 정도 XML 데이터를 지원한다. 아직 개발되지 않은 애플리케이션의 경우 제이슨보다 XML을 선택하는 경우가 많을 수도 있겠지만, XML 문서를 중심으로 구축된 기존 애플리케이션의 경우에는 XML을 관계 테이블에 저장할 수 있는 기능이 유용할 수 있다.

지리공간(Geospatial) 데이터
기하학 및 지리적 정보가 숫자 유형에 적합할 것처럼 보일 지도 모르지만, 공간 데이터에 대해 자주 실행되는 쿼리의 종류는 2차원 데이터를 인식하는 인덱스를 필요로 한다. 이것은 표준 B-트리 기능을 벗어난다. 

예를 들어, 두 공항 사이의 거리, LA 공항에서 가장 가까운 이웃 공항, 시카고에서 비즈니스 미팅 장소와 가장 가까운 호텔, 또는 맨해튼의 경계 안에 택시가 있는지 등등을 알고 싶은 경우가 있을 수 있다. 이러한 쿼리를 처리하기 위해서 R-트리, SP-GiST, 쿼드트리 또는 UB-트리 인덱스가 필요할 수도 있다. 

포스트그레SQL을 위한 포스트GIS와 같이 일부는 추가 기능을 필요로 하지만, 앞서 언급한 모든 관계형 데이터베이스는 공간 정보 및 인덱스를 지원한다. 구현 상세 내역은 종종 다르지만, 일반적으로 개방형 공간 컨소시엄 단순 기능(Open Geospace Consortium Simple Features) 사양 및 SQL/MM 공간 ISO/IEC 표준을 준수한다.

인메모리(In-memory) 테이블
인메모리 캐싱은 지원하지만 순수한 인메모리 테이블은 아닌 PostgreSQL를 제외하면, 앞서 언급한 모든 관계형 데이터베이스는 메모리에 테이블을 만들 수 있다. 인메모리 테이블은 주로 읽기가 매우 많은 시나리오에서 해당 테이블의 정보 작업 속도를 크게 향상시킨다. 때때로 언급되는 속도 개선치는 30배지만, 그것은 데이터베이스에 사용될 수 있는 다양한 종류의 디스크를 고려하지 않는 근사치에 불과하다. 

종종 인메모리 테이블에 적용되는 한도가 있다. 가장 중요한 것은 그 테이블을 고정하기에 충분한 램의 요구사항이다. 이 요구사항은 대신 캐싱과 조인스를 위해 사용될 수 있었던 것들이다. 그 다음으로는 특정 데이터베이스와 엔진에 대한 제한이 있다. 

MySQL MEMORY 스토리지 엔진은 일시적이고 내구성이 없으며(MySQL 서버가 중단되거나 중지될 때 사라짐), 트랜잭션·외래키·지리적 유형· 전문 검색 색인화 등이 부족하고, 쓰기가 많은 경우 제대로 작동하지 않으며, 테이블 수준에서 잠김이 발생하고, 파티션이 불가능하다. MySQL NDB 클러스터 엔진은 이러한 제약 조건 중 일부를 제거하지만, MySQL 데몬의 특수 버전을 실행해야 하며 클러스터에서 여러 종류의 노드가 활성화되어야 한다. 

SQL 서버 인메모리 OLTP는 메모리에 최적화된 테이블을 사용하는데, 내구성이 뛰어나고 트랜잭션을 지원한다. 또한, 종종 임시 테이블 대신 일시적인 데이터에 사용되는 내구성이 없는 테이블도 사용한다. 게다가 기본적으로 컴파일 된 T-SQL 모듈을 사용하여 작업을 처리하는 데 필요한 CPU 사이클을 줄임으로써 개별 트랜잭션에 소요되는 시간을 더욱 단축한다. SQL 서버 인메모리 OLTP 테이블은 쿼리 및 트랜잭션에서 디스크 기반 테이블과 결합될 수 있다. 

오라클 데이터베이스 인메모리는 실시간 애널리틱스(OLAP) 및 혼합 워크로드(HTAP)의 성능을 크게 향상시킨다. 인메모리 컬럼 스토어(IM 컬럼 스토어)는 오라클 데이터베이스 인메모리의 핵심 기능이다.

외부 데이터 소스
SQL 서버의 최근 버전들은 데이터베이스 자체 테이블의 외부에 있는 데이터 소스를 쿼리하는 메커니즘을 가지고 있다. 하둡, 블롭(Blob) 스토리지, 다른 관계형 데이터베이스 또는 샤드 맵 관리자에서 EXTERNAL DATA SOURCE를 생성할 수 있다. 그런 다음 데이터 로드 및 쿼리용 외부 데이터 소스에 대해 폴리베이스 또는 엘라스틱 데이터베이스 쿼리(애저 SQL 데이터베이스 v12+)를 사용할 수 있다.

포스트그레SQL 외래 데이터 래퍼로 포스트그레SQL 쿼리는 폭넓은 원격 데이터 소스에 대해 실행이 가능하다. 그 범위가 다른 SQL 데이터베이스, NoSQL 데이터베이스 및 빅 데이터 플랫폼에서 플랫 파일에 이르기까지 매우 넓다. 외래 데이터 래퍼는 SQL/MED(SQL Management of External Data) 표준을 따른다. 

빅 데이터 클러스터
마이크로소프트 SQL 서버 빅데이터 클러스터는 SQL 서버 2019 미리 보기를 시작으로 쿠버네티스에서 실행 중인 SQL서버, 스파크 및 HDFS 컨테이너의 확장 가능한 클러스터를 배치할 수 있도록 해준다. 이러한 구성요소는 Transact-SQL(PolyBase를 통해)나 스파크에서 빅데이터를 나란히 읽고, 쓰고, 처리하여, 고부가가치 관계 데이터를 대용량 빅데이터와 결합하고 분석할 수 있게 한다. 

오라클은 오라클 빅데이터 클라우드 서비스오라클 빅데이터 어플라이언스 온 프레미스에서 비슷한 기능을 제공한다.

복제본 읽기
MySQL, 마리아DB 및 포스트그레SQL은 모두 복제본 읽기 기능을 제공한다. 복제본 읽기는 직접적으로 읽기 처리율을 증가시키지만, 읽기/쓰기 서버의 읽기 로드를 줄임으로써 간접적으로 쓰기 성능도 높일 수 있다.

MySQL/마리아DB는 로그 파일 및 GTID 기반, 비동기식, 인메모리 NDB 클러스터를 사용하는 동기식, 반동기식 및 지연식, 문장 기반, 행 기반 및 혼합 기반 등의 다양한 종류의 복제본을 지원한다. 포스트그레SQL에는 다양한 복제 솔루션이 있다. 

아마존 오로라는 MySQL 및 포스그레SQL용 복제본 읽기 계획을 자체적으로 구현하고 있다. 오로라에서는 15개까지의 복제본이 가능하며, 동기화 지연시간은 20밀리초 미만이다.  

SQL 서버는 액티브-액티브 클러스터에서 보조 복제본 읽기를 지원한다. 오라클 데이터베이스는 읽기 전용 테이블 스냅샷을 사용하는 기본적인 한 방향 읽기 전용 복제 환경을 지원하고, 오라클 엔터프라이즈는 복제된 데이터베이스 시스템 전체에서 애플리케이션이 테이블 복제본을 업데이트할 수 있도록 하여 기본적인 읽기 전용 복제 기능을 확장시킨 고급 복제 기능을 지원한다.

샤딩(Sharding)
샤딩은 서버 간에 데이터를 나누는 방법이다. 수직 샤딩은 예를 들어 한 서버에는 인벤토리를 배치하고 다른 서버에는 주문을 넣고, 그리고 세 번째 서버에는 분석을 위해 집계된 테이블을 두는 등의 서로 다른 테이블의 분산과 관련이 있다. 

그것은 당신이 여러 서버의 테이블에 가입해야 할 때에만 문제가 된다. 수평 샤딩은 알파벳순으로 분할된 컨벤션의 등록 스테이션처럼 서버 간에 개별 테이블을 나누는 것과 관련된다. 수동 수평 샤딩은 골칫거리지만, 다행히도 자동 수평 샤딩을 위한 몇 가지 선택사항이 있다. 

시투스(Citus)는 프로트그레SQL의 자동 수평 샤딩을 한다. 시투스는 또한 데이터를 보관하는 작업자 노드에 대한 프런트엔드로써 코디네이터 노드도 제공한다.

마이크로소프트 에저 SQL 데이터베이스 v12는 자동 수평 샤딩을 위한 탄력적인 데이터베이스 샤드 맵을 지원한다. 또한, 수직 샤딩를 위한 데이터베이스 간 쿼리도 지원한다.

몇 가지 방법을 통해 아마존 RDS를 이용하여 MySQL 및 지원되는 다른 데이터베이스를 샤딩할 수 있다. 일반적으로 복제본 읽기를 사용하여 복제본을 만든 다음 복제본을 새 샤드로 삼을 수 있다. 오로라에는 이러한 용도의 clone database 명령이 있다. 복제 후 파티션 키 매핑 테이블에 따라 해당 샤드에 사용되지 않는 복제된 데이터는 삭제가 가능하다. 

SQL을 벗어난 보관 절차
역사적으로 모든 관계형 데이터베이스는 SQL 서버용 Transact-SQL 및 오라클용 PL/SQL과 같은 보관 절차를 위한 고유한 SQL 확장을 가지고 있었다. 최근 몇 년간 관계형 데이터베이스는 프로그래밍 언어 및 머신러닝 능력과 통합되어 왔다. 이것의 초기 예로는 오라클 데이터베이스에서 PL/SQL의 부속물로 실행되는 자바(Java)가 있다. 그 이후로 C, C++, C#, 펄(Perl), PHP, 파이썬(Python), R 언어 데이터베이스 확장이 등장했다. 

2009년 무렵 NoSQL 데이터베이스의 도입으로 SQL 호환성과 강한 일관성을 포기하는 대신 웹 애플리케이션을 위한 확장성이 높고 가용성이 좋은 데이터베이스의 필요성이 반영됐다. 지난 몇 년 동안 ‘고전적인’ SQL 데이터베이스는 일관성이나 호환성을 희생하지 않고서도 확장성과 가용성을 개선하기 위한 많은 옵션을 추가해왔다. 

해당 ‘NoSQL’ 작업을 위해 구식 SQL 데이터베이스를 무시하기 전에 문서를 확인하도록 하자. 양쪽 모두에서 최상의 결과를 얻을 지도 모른다. 

* Martin Heller는 인포월드 객원 편집자이자 리뷰어다. ciokr@idg.co.kr

X