KR102411806B1 - 데이터베이스 쿼리 효율 향상을 위한 시스템 및 방법 - Google Patents

Abstract

본 개시는 데이터베이스 쿼리 효율 향상을 위한 방법 및 시스템에 관한 것이다. 이 방법은 쿼리에서 프레디케이트들을 식별하고―각 프레디케이트는 컬럼 이름을 포함함―; 각 컬럼 이름에 대한 가장 공통적인 값들을 결정하고; 각 컬럼 이름에 대하여, 가장 공통적인 값들 중 적어도 하나를 포함하는 리스트를 생성하고; 컬럼 이름 중 하나와 컬럼 이름에 대응하는 리스트에 대한 엔트리를 포함하는 테스트 프레디케이트를 생성하고; 하나 이상의 테스트 프레디케이트를 포함하는 테스트 쿼리를 생성하고; 쿼리의 리소스 사용률을 결정하고; 그리고 효율성 향상 제안을, 디스플레이를 위한 유저 인터페이스에 제공하는 것을 포함할 수 있다.

Description

데이터베이스 쿼리 효율 향상을 위한 시스템 및 방법{SYSTEMS AND METHODS FOR DATABASE QUERY EFFICIENCY IMPROVEMENT}

실시예들은 데이터베이스 쿼리 효율 향상을 위한 컴퓨터로 구현되는 시스템 및 방법에 관한 것이다. 특히, 본 발명의 실시예들은 데이터베이스 쿼리를 분석하는 시스템에 관한 것이다. 상술한 시스템은 테스트 데이터베이스에서의 보다 적절한 기능을 위해 쿼리를 테스트할 수 있다. 쿼리가 성공적이면, 상술한 시스템은 쿼리 변형을 생성하고 쿼리 효율성을 테스트하기 위해 변형을 오프라인 데이터베이스에서 실행할 수 있다. 상술한 시스템은 프로덕션 데이터베이스에서 쿼리들을 실행하기에 앞서 복수의 쿼리 시나리오들을 오프라인 데이터베이스에서 실행해 볼 수 있다. 상술한 방법을 통하여, 잠재적인 쿼리의 비효율성 및 과도한 리소스 사용이 사용자 경험을 저하시키기 전에 식별될 수 있다.

대규모 데이터베이스 저장소의 속도 및 접근성의 발전으로 인하여, 개발자들은 사용자 웹사이트 경험을 향상시킬 수 있다. 예를 들어, 사용자가 전자 상거래 웹사이트에서 제품을 볼 때, 웹사이트의 기본 스크립트들은 여러 자동화된 데이터베이스 쿼리들을 실행하여 제품에 대한 정보를 획득할 수 있다. 몇가지 경우, 개발자들은 서버 데이터베이스 쿼리가 실행되기 이전에 사용자의 검색어로 완성되는 쿼리 구조로 웹사이트를 프로그래밍할 수 있다. 개발자들은 라이브 스트리밍되는 재고 메트릭스, 교통 계획, 교통 업데이트, 스포츠 점수 등과 같이 자동화된 데이터베이스 쿼리들 및 분석을 수행하는 프로그램을 생성할 수 있다.

간단한 쿼리를 사용하는 소규모 사용자와 같은 경우, 최근 데이터베이스 아키텍처는 비효율적인 쿼리들이라도, 사용자 경험에 대한 사용자 경험에 제한적인 저하를 주면서, 이들을 잘 실행할 수 있다. 다만, 데이터베이스 쿼리들이 복잡해지거나 어플리케이션의 사용자 용량이 커지는 경우, 사소한 데이터베이스 비효율성이라도 사용자 경험에 상당한 저하를 줄 수 있다. 이는, 웹사이트들 및 어플리케이션들로 하여금 고객 또는 거래의 손실로 이어질 수 있다.

그러나, 개발자들은 비효율적인 쿼리를 식별하기 어려울 수 있다. 일반적으로, 비효율적인 데이터베리스 지연은 사용자 경험을 통해 나타나기 이전에는 식별하기 어렵다. 경쟁 환경에서 대규모 사용자에게 서비스 또는 제품을 제공할 때, 이러한 문제점이 보고되지 않을 수 있다. 사용자는 단순히 느린 웹사이트를 보고 비효율적인 데이터베이스 쿼리를 식별하는 것은 시간 및 리소스 효율적인 방법이 아닐 수 있다. 개발자가 느린 웹사이트를 보고 비효율적인 쿼리의 식별을 결정한다고 하여도, 동일한 기능을 제공하기 위해 쿼리를 수정하는 것은 오히려 시간이 더 들 수 있다.

따라서, 배포 이전에 테스트 환경에서 비효율적인 쿼리를 식별하고 이를 수정하여 사용자 경험을 저하시키는 현상을 방지할 수 있는 시스템 및 방법이 필요하다.

실시예들은, 배포 이전에 테스트 환경에서 비효율적인 쿼리를 식별하고 이를 수정하여 사용자 경험을 저하시키는 현상을 방지할 수 있는 시스템 및 방법을 제공하는 것을 과제로 한다.

본 발명의 기술적 과제들은 이상에서 언급한 기술적 과제로 제한되지 않으며, 언급되지 않은 또 다른 기술적 과제들은 아래의 기재들로부터 당업자에게 명확하게 이해될 수 있을 것이다.

실시예들에 따른 데이터베이스 쿼리 효율 향상을 위한 컴퓨터로 구현되는 시스템은, 인스트럭션(instruction)을 저장하는 메모리; 및 상기 인스트럭션을 실행하여 동작들을 수행하는 적어도 하나의 프로세서; 를 포함하고, 상기 동작들은, 제1 데이터베이스를 제2 데이터베이스로 미러링(mirroring)하는 동작, 상기 제2 데이터베이스는 스키마(schema)를 포함함; 상기 스키마를 포함하는 테스트 데이터베이스를 생성하는 동작; 쿼리(query)를 수신하는 동작; 상기 쿼리를 상기 테스트 데이터베이스에서 실행하는 동작; 및 상기 쿼리가 상기 테스트 데이터베이스에서 성공적으로 완료된 것에 대응하여, 상기 쿼리를 판단하는 동작; 을 포함하고, 상기 쿼리를 판단하는 동작은, 상기 쿼리에서 프레디케이트(predicate)들을 식별하는 동작, 각 프레디케이트는 컬럼 이름을 포함함; 상기 제2 데이터베이스를 쿼리하여, 각 컬럼 이름에 대한 가장 공통적인 값들을 결정하는 동작; 각 컬럼 이름을 위하여, 적어도 하나의 상기 가장 공통적인 값들을 포함하는 리스트(list)를 생성하는 동작; 상기 컬럼 이름들 중 어느 하나 및 상기 컬럼 이름에 대응하는 상기 리스트에 대한 엔트리(entry)를 포함하는 테스트 프레디케이트를 생성하는 동작; 하나 또는 그 이상의 테스트 프레디케이트들을 포함하는 테스트 쿼리를 생성하는 동작; 상기 제2 데이터베이스에서 상기 테스트 쿼리들 각각을 실행하여 상기 쿼리의 리소스 사용률(resource utilization)을 결정하는 동작; 및 상기 리소스 사용률이 임계값을 초과하면, 효율성 향상 제안을 디스플레이를 위한 유저 인터페이스에 제공하는 동작; 를 포함할 수 있다.

또한, 실시예들에 따른 데이터베이스 쿼리 효율 향상을 위한 컴퓨터로 구현되는 방법은, 제1 데이터베이스를 제2 데이터베이스로 미러링하는 단계, 상기 제2 데이터베이스는 스키마를 포함함; 상기 스키마를 포함하는 테스트 데이터베이스를 생성하는 단계; 쿼리를 수신하는 단계; 상기 테스트 데이터베이스에서 상기 쿼리를 실행하는 단계; 및 상기 쿼리가 상기 테스트 데이터베이스에서 성공적으로 완료된 것에 대응하여, 상기 쿼리를 판단하는 단계; 를 포함하고, 상기 쿼리를 판단하는 단계는, 상기 쿼리에서 프레디케이트들을 식별하는 단계, 각 프레디케이트는 컬럼 이름을 포함함; 상기 제2 데이터베이스를 쿼리하여, 각 컬럼 이름에 대한 가장 공통적인 값들을 결정하는 단계; 각 컬럼 이름을 위하여, 적어도 하나의 상기 가장 공통적인 값들을 포함하는 리스트를 생성하는 단계; 상기 컬럼 이름들 중 어느 하나 및 상기 컬럼 이름에 대응하는 상기 리스트에 대한 엔트리를 포함하는 테스트 프레디케이트를 생성하는 단계; 하나 또는 그 이상의 테스트 프레디케이트들을 포함하는 테스트 쿼리를 생성하는 단계; 상기 제2 데이터베이스에서 상기 테스트 쿼리들 각각을 실행하여 상기 쿼리의 리소스 사용률을 결정하는 단계; 및 상기 리소스 사용률이 임계값을 초과하면, 효율성 향상 제안을 디스플레이를 위한 유저 인터페이스에 제공하는 단계; 를 포함할 수 있다.

또한, 실시예들에 따른 데이터베이스 쿼리 효율 향상을 위한 컴퓨터로 구현되는 방법은, 제1 데이터베이스를 제2 데이터베이스로 미러링하는 단계, 상기 제2 데이터베이스는 스키마(schema)를 포함함; 상기 스키마를 포함하는 테스트 데이터베이스를 생성하는 단계; 쿼리를 수신하는 단계; 상기 테스트 데이터베이스에서 상기 쿼리를 실행하는 단계; 및 상기 쿼리가 상기 테스트 데이터베이스에서 성공적으로 완료되면, 상기 쿼리를 평가하는 단계; 를 포함하고, 상기 쿼리를 판단하는 단계는, 상기 쿼리에서 프레디케이트들을 식별하는 단계, 각 프레디케이트는 특정 컬럼 이름을 포함함; 상기 제2 데이터베이스를 쿼리하여, 각 컬럼 이름에 대한 가장 공통적인 값들을 결정하는 단계; 쿼리 저장소를 쿼리하여, 각 컬럼 이름에 대한 가장 공통적인 쿼리된 값들을 결정하는 단계; 각 컬럼 이름을 위하여, 적어도 하나의 상기 가장 공통적인 값들 및 적어도 하나의 상기 가장 공통적인 쿼리된 값들을 포함하는 리스트(list)를 생성하는 단계; 상기 컬럼 이름들 중 어느 하나 및 상기 컬럼 이름에 대응하는 상기 리스트에 대한 엔트리(entry)를 포함하는 테스트 프레디케이트를 생성하는 단계; 테스트 프레이케이드들의 조합(combinations)을 포함하는 테스트 쿼리를 생성하는 단계; 상기 제2 데이터베이스에서 상기 테스트 쿼리들 각각을 실행하여 쿼리 프로세싱 시간을 결정하는 단계; 및 상기 쿼리 프로세싱 시간의 최대값이 임계값보다 작은 경우, 상기 제1 데이터베이스에서 상기 쿼리를 실행하는 단계; 를 포함할 수 있다.

본 개시의 일 양태는 데이터베이스 쿼리 효율 향상을 위한 방법 및 시스템에 관한 것이며, 이 방법은 쿼리에서 프레디케이트들을 식별하고―각 프레디케이트는 컬럼 이름을 포함함―; 각 컬럼 이름에 대한 가장 공통적인 값들을 결정하고; 각 컬럼 이름에 대하여, 가장 공통적인 값들 중 적어도 하나를 포함하는 리스트를 생성하고; 컬럼 이름 중 하나와 컬럼 이름에 대응하는 리스트에 대한 엔트리를 포함하는 테스트 프레디케이트를 생성하고; 하나 이상의 테스트 프레디케이트를 포함하는 테스트 쿼리를 생성하고; 쿼리의 리소스 사용률을 결정하고; 그리고 효율성 향상 제안을, 디스플레이를 위한 유저 인터페이스에 제공하는 것을 포함할 수 있다.

실시예들은, 배포 이전에 테스트 환경에서 비효율적인 쿼리를 식별하고 이를 수정하여 사용자 경험을 저하시키는 현상을 방지할 수 있다.

이 외에, 본 문서를 통해 직접적 또는 간접적으로 파악되는 다양한 효과들이 제공될 수 있다.

도 1은 실시예들에 따른 클라이언트 및 데이터베이스들을 포함하는 네트워크를 나타낸다.
도 2는 실시예들에 따른 데이터베이스 쿼리 효율성 향상 프로세스의 플로우 차트를 나타낸다.
도 3은 실시예들에 따른 쿼리 변형(vairations)의 생성을 나타낸다.

이하, 설명하는 발명의 상세한 설명은 후술하는 도면들에 관한 설명이다. 각 도면의 구성요소들에 참조부호를 부가함에 있어서, 동일한 구성요소들에 대해서는 비록 다른 도면상에 표시되더라도 가능한 한 동일한 부호를 가지도록 하고 있음에 유의해야 한다. 여기서 설명하는 본 발명의 실시예들은 서로 변형, 적용이 가능하다. 예를 들어, 실시예들 간의 치환, 재정렬, 제거 또는 추가가 가능하다. 따라서, 후술하는 발명의 상세한 설명은 개시된 실시예들 및 예시들에 국한되지 않는다. 대신, 본 발명의 적절한 권리범위는 첨부된 청구항들에 의해 정의될 수 있다.

본 발명의 실시예들은 가상 서버 자원 리소스 메트릭 등급을 위한 시스템 및 방법에 관한 것일 수 있다.

도 1은 실시예들에 따른 클라이언트 및 데이터베이스들을 포함하는 시스템(100)를 나타낸다. 시스템(100)의 구성요소들은 컴퓨터 네트워크(112)를 통해 통신할 수 있다. 컴퓨터 네트워크(112)는 인터넷, 인트라넷, LAN (Local-Area Network), WAN (Wide-Area Network) MAN (Metropolitan개의 Area Network), VPN (Virtual Private Network), 무선 네트워크(예를 들어, IEEE 802.11a/b/g/n에 따른 네트워크), 유선 네트워크, 전용선, 셀룰러 데이터 네트워크, 블루투스 연결을 위한 네트워크, 적외선 연결, NFC (Near-Field Communication) 중 하나 또는 그 이상의 조합을 포함할 수 있다.

시스템(100)은 제1 데이터베이스(104), 제2 데이터베이스(106), 테스트 데이터베이스(108) 및 쿼리 저장소(110)와 같은 복수의 데이터베이스들을 포함할 수 있다. 데이터베이스들(104 내지 110)은, 예를 들어, HBase, MongoDB?? 또는 Cassandra??와 같은 NoSQL 데이터베이스들을 포함할 수 있다. 또한, 데이터베이스들(104 내지 110)은 Oracle, MySQL, 및 Microsoft SQL 서버와 같은 관계형 데이터베이스를 포함할 수 있다. 실시예들에 따른 데이터베이스들(104 내지 110)은 서버, 가상 서버, 일반적인 컴퓨터, 메인 프레임 컴퓨터 또는 이들의 구성요소들의 조합의 형태를 가질 수 있다. 임의의 개수의 제1 데이터베이스(104), 제2 데이터베이스(106), 테스트 데이터베이스(108) 또는 쿼리 저장소(110)가 서버(100)에 포함될 수 있다.

제1 데이터베이스(104)는 클라이언트 디바이스(122)로부터 생성된 웹사이트 리퀘스트에 대응하여 서버(102)에 데이터를 제공할 수 있다. 제1 데이터베이스(104)는 프로덕션(production) 데이터베이스로 호칭될 있다. 다시 말해, 클라이언트들은 제1 데이터베이스(104)에 저장된 데이터로 접근(interact)할 수 있다. 제1 데이터베이스에 포함된 데이터는 클라이언트의 요구를 충족시키기 위해 실제 데이터를 포함할 수 있고, 다양한 보안 기능으로 보호될 수 있다. 예를 들어, 상술한 데이터는 보안 연결 및 액세스 권한이 필요한 은행 계좌 정보 또는 개인 식별 정보가 포함될 수 있다. 서버(102)는 액세스 권한을 관리할 수 있다.

제2 데이터베이스(106)는 제1 데이터베이스(104)로부터 복사된 데이터를 포함할 수 있다. 상술한 데이터는, 제2 데이터베이스에 저장된 정보가 제한적 허가 요건에 의해 보호되지 않도록 삭제될 수 있다. 제2 데이터베이스(106)은 제1 데이터베이스가 사용자 리퀘스트에 응답하느라 바쁘지 않을 때, 제1 데이터베이스로부터 데이터를 임시로 복사할 수 있다. 제2 데이터베이스(106)는 정보를 주기적으로, 예를 들어, 몇 시간 마다, 매일 밤, 격일로, 매주 또는 요구에 따라 복사할 수 있다. 실시예들에서, 사용자는 제2 데이터베이스에 저장된 데이터에 접근할 수 없을 수 있다. 대신, 제2 데이터베이스(106)의 데이터는 제1 데이터베이스를 태스크(task)하고 사용자 리퀘스트를 잠재적으로 방해하지 않고, 쿼리를 테스트하기 위해 사용될 수 있다. 제2 데이터베이스(106)는 오프라인 데이터베이스로 호칭될 수 있다.

테스트 데이터베이스(108)는 제1 데이터베이스(104)에 저장된 데이터의 서브 세트를 포함할 수 있다. 상술한 데이터는 제1 데이터베이스와 동일한 데이터 구조를 유지하면서, 실제 데이터를 제거하기 위해 삭제될 수 있다. 예를 들어, 만약 제1 데이터베이스(104)가 계좌 소유자 이름에 대응하는 은행 계좌 정보 테이블을 저장하는 경우, 테스트 데이터베이스(108)는 가상(fictional) 이름에 대응하는 난수 테이블이 저장할 수 있다. 개발자는 쿼리가 작동하는지 여부를 결정하기 위해 테스트 데이터베이스(108)에 저장된 데이터를 사용할 수 있다. 다시 말해, 테스트 데이터베이스(108)은 제1 데이터베이스(104) 또는 제2 데이터베이스(106)와 동일한 데이터 구조를 가지나, 제1 데이터베이스(104) 및 제2 데이터베이스(106) 보다 적거나 데이터 및/또는 다른 데이터를 가질 수 있다.

쿼리 저장소(110)는 사용자의 의해 실행된 쿼리 기록을 저장할 수 있다. 서버(102)는 사용자로부터 리퀘스트가 수신될 때 쿼리 저장소(110)을 채울 수 있다. 전자 상거래를 예로 들면, 사용자는 신발과 코트에 대한 리퀘스트를 온라인 스토어 인벤토리에 제출할 수 있다. 리퀘스트가 생성되면, 서버(102)는 아이템 타입이 "신발"인 인벤토리 엔트리를 얻기 위해 쿼리를 생성할 수 있다. 또한, 서버(102)는 사용자가 "인벤토리"로 표시된 컬럼에서 "신발"에 대한 쿼리를 트리거했음을 나타내는 쿼리 저장소에 저장된 로그를 업데이트할 수 있다. 쿼리 저장소의 데이터는 쿼리 효율성 테스트를 위해 사용될 수 있다.

시스템(100)은 서버(102)를 포함할 수 있다. 서버(102)는 웹사이트, 앱 등을 클라이언트 디바이스에 제공하기 위하여 HTML 코드, 그래픽, 스크립트 및 연결 프로토콜과 같은 정보를 저장할 수 있다. 서버(102)는 웹사이트를 채우기 위해 데이터베이스(104 내지 110) 중 어느 하나에 의해 제공된 정보를 검색하고 처리할 수 있다. 실시예들에서, 서버(102)는 프로세싱 과정 없이, 데이터베이스(104 내지 110) 중 어느 하나로부터 클라이언트 디바이스로 로우(raw) 데이터를 제공할 수 있다. 추가적으로, 서버(102)는 클라이언트 디바이스로부터 데이터를 처리하여 쿼리를 생성하고, 쿼리를 데이터베이스에 제출하고, 결과를 분석 또는 포맷하고, 결과를 클라이언트 디바이스(122)에 제공할 수 있다. 서버(102)는 데이터베이스(104 내지 110)으로부터 데이터를 다운로드 받거나 데이터를 업로드할 수 있다. 실시예들에서, 서버(102)는 데이터를 복사하고, 데이터를 수정하고, 저장소를 할당하고, 중복 데이터 저장소를 정렬하고, 하나 또는 그 이상의 데이터베이스들(104 내지 110)의 데이터 액세스를 관리함으로써 데이터베이스(104 내지 110)를 관리할 수 있다.

클라이언트 디바이스(122)는 랩탑, 스탠드 컴퓨터, 모바일 폰, 태블릿 컴퓨터, 웨어러블 장치(예를 들어, 스마트 위치) 등에 해당할 수 있다. 클라이언트 디바이스(122)는 웹사이트에 의해 제공되는 서비스 또는 제품을 사용하는 웹사이트 고객과 관련될 수 있다. 추가적으로 또는 대체적으로, 클라이언트 디바이스(122)는 개발자와 관련될 수 있다. 예를 들어, 개발지는 웹사이트의 기본 코드를 작성하고 클라이언트 디바이스(122)를 통하여 서버(102)에 코드를 업로드 할 수 있다.

시스템(100)은 쿼리 테스트 시스템(114)를 더 포함할 수 있다. 쿼리 테스트 시스템(114)은 쿼리가 서버(102)에서 실행되는 코드에 병합되기에 앞서, 쿼리들의 테스트를 조정할 수 있다. 따라서, 개발자는 클라이언트 디바이스(122)를 통해 쿼리 테스트 시스템(114)를 활용하여, 쿼리의 에러 또는 효율성을 테스트할 수 있다. 쿼리 테스트 시스템(114)은 적어도 하나의 프로세서(116), 데이터를 송신하는 입/출력 디바이스(118) 및 적어도 하나의 메모리(120)을 포함할 수 있다. 메모리(120)는 쿼리 테스트를 수행하기 위한 프로그램을 저장할 수 있다. 또한, 메모리(120)는 그래픽 유저 인터페이스(Graphical User Interface, GUI)를 위한 인스트럭션(instruction)들을 저장할 수 있다. 쿼리 테스트 시스템(114)은 사용자 입력 장치 및 디스플레이 디바이스(이 도면에 도시되어 있지 않음)을 포함할 수 있다. 서버(102), 클라이언트 디바이스(122) 및 데이터베이스들(104 내지 11)은 프로세서들, 입/출력 디바이스들, 메모리들, 프로그램들 및 유저 인터페이스들을 포함할 수 있다. 실시예들에서, 클라이언트 디바이스(122)는 개발자가 쿼리 테스트 시스템(114)에 접근할 수 있도록 사용자 입력 및 디스플레이 기능을 제공할 수 있다.

추가적으로, 프로세서(116)은 정보를 조작하거나 프로세싱할 수 있는 일반적인 또는 특정 전자 디바이스에 해당할 수 있다. 예를 들어, 프로세서는 하나 또는 그 이상의 중앙 처리 장치(또는 CPU), 그래픽 프로세싱 유닉(또는 GPU), 광학 프로세서, 프로그래머블 로직 컨트롤러, 마이크로 컨트롤러, 마이크로 프로세서, 디지털 신호 프로세서, 지적 재산(IP) 코어, 프로그래머블 로직 어레이 (Programmable Logic Array, PLA), 프로그래머블 어레이 로직 (Programmable Array Logic, PAL), 제네릭 어레이 로직 (Generic Array Logic, GAL), 콤플렉스 프로그래머블 로직 디바이스 (Complex Programmable Logic Device, CPLD), 필드 프로그래머블 게이트 어레이 (Field-Programmable Gate Array, FPGA), 시스템 온 칩(System On Chip, SoC), 어플리케이션 특정 집적 회로(Application개의 Specific Integrated Circuit, ASIC) 또는 데이터 프로세싱이 가능한 어떤 형태의 회로 중 하나 또는 그 이상을 포함할 수 있다. 또한, 프로세서는 네트워크를 통해 연결된 여러 디바이스들 또는 기계들에 걸쳐 분포된 하나 또는 그 이상의 프로세서들을 포함할 수 있다.

메모리(120)은 코드를 저장하거나 프로세서에 의하여 데이터 접근 가능한(예를 들어, 이 도면에서 도시되어 있지 않은 bus를 통하여) 일반적인 또는 특정 전자 디바이스를 나타낼 수 있다. 예를 들어, 메모리(120)은 랜덤 액세스 메모리(Random-Access Memory, RAM), 리드 온리 메모리(Read-Only Menory, ROM), 광학 디스크, 메그네틱 스틱, 컴팩트 플래시(Compact Flash, CF) 카드 또는 어떠한 형태의 저장 디바이스 중 하나 또는 그 이상을 포함할 수 있다. 코드들은 특정 태스크를 위한 운영 체제(Operating System, OS) 및/또는 하나 또는 그 이상의 어플리케이션 프로그램들(Application Programs, apps)을 포함할 수 있다. 메모리(120)는 네트워크를 통해 연결된 여러 디바이스들 또는 기계들에 걸쳐 분포된 하나 또는 그 이상의 가상 메모리일 수 있다.

실시예들에서, 쿼리 테스트 시스템(114), 서버(102) 및/또는 데이터베이스들(104 내지 110)의 어떠한 조합도 하나의 디바이스에서 포함될 수 있다. 예를 들어, 서버(102)는 쿼리 테스트 시스템(114)의 기능을 실행할 수 있고, 쿼리 저장소(110)의 데이터를 포함할 수 있거나, 쿼리 테스트 시스템(114)은 데이터베이스들(104 내지 110) 중 임의의 데이터베이스를 관리할 수 있다. 독립적인 디바이스들은 복제되거나 분해될 수 있다. 예를 들어, 제1 데이터베이스는 오류 발생시 연속적인 동작을 수행하기 위한 복수의 백업(backup) 데이터베이스들을 포함하거나, 메모리(120) 상의 프로그램은 별도의 도시되어 있지 않은 데이터베이스에 저장될 수 있다. 또한, 디바이스들은 가상 서버를 통해 구현될 수 있다.

도 2는 실시예들에 따른 데이터베이스 쿼리 효율성 향상 프로세스의 플로우 차트를 나타낸다. 쿼리 테스트 시스템(114)는 데이터베이스들(104 내지 110)에 저장된 데이터를 사용하여 프로세스(200)을 수행할 수 있다. 프로세스(200)을 수행하기 위한 인스트럭션은 메모리(120)에 저장되고 쿼리 테스트 시스템(114)의 프로세서에 의해 실행될 수 있다. 프로세스(200)는 도 3 에 도시된 단계들을 포함할 수 있다.

202 단계에서, 쿼리 테스트 시스템(114)은 제1 데이터베이스를 제2 데이터베이스로 미러링(mirroring)할 수 있고, 제2 데이터베이스는 스키마(schema)를 포함할 수 있다. 다시 말해, 쿼리 테스트 시스템(114)은 제1 데이터베이스를 제2 데이터베이스로 복사할 수 있다. 각 컬럼 이름에 대한 컬럼 이름들 및 데이터 타입들과 같은 정보를 포함하는 스키마 또는 데이터 구조는, 제1 데이터베이스의 스키마와 동일할 수 있다. 미러링은 제1 데이터베이스에 저장된 데이터의 서브셋만 임의로 선택하여 부분적으로 수행될 수 있다. 쿼리 테스트 시스템(114)은 임의의 간격으로, 예를 들어, 제1 데이터베이스가 여분의 프로세싱 능력을 가질 때 마다, 또는 개발자가 데이터베이스로부터 정보를 복사하기 위해 버튼을 클릭할 때와 같은 이벤트에 기반하여 202 단계를 수행할 수 있다. 미러링이 초기화되거나 처음으로 설정된 경우, 쿼리 테스트 시스템(114)은 제1 데이터베이스의 데이터 스키마를 복사할 수 있다. 그후 후속하는 업데이트들은 스키마의 업데이트 없이 제2 데이터베이스의 데이터를 편집(예를 들어, 데이터의 추가, 수정 또는 삭제)할 수 있다.

204 단계에서, 쿼리 테스트 시스템(114)은 스키마를 포함하는 테스트 데이터베이스(108)를 생성할 수 있다. 테스트 데이터베이스(108)의 데이터는 제1 데이터베이스 및 제2 데이터베이스와 동일한 스키마를 포함할 수 있지만, 테스트 데이터베이스는 합성 데이터(즉, 플레이스 홀더 정보(Place Holder Information)로 생성된 인공의 "필터" 데이터)를 포함할 수 있다. 개발자들은 테스트 데이터베이스에 반하여(against) 쿼리들을 실행하고 오류, 누락된 컬럼 등으로 쿼리들이 실패하기 않도록 보장함으로써, 쿼리를 디버깅할 수 있다. 따라서, 테스트 데이터베이스(108)은 쿼리들의 기본적인 기능을 테스트하기 위해 사용되므로, 테스트 데이터베이스(108)은 제1 데이터베이스 또는 제2 데이터베이스와 동일한 양의 데이터를 포함할 필요가 없을 수 있다. 대신, 일부 실시예들에 따른 테스트 데이터베이스(108)은 제1 데이터베이스 및/또는 제2 데이터베이스와 동일한 정보를 포함할 수 있다.

206 단계에서, 쿼리 테스트 시스템(114)은 쿼리를 수신하고, 쿼리를 테스트 데이터베이스에서 실행할 수 있다. 쿼리를 실행하는 과정은 쿼리를 데이터베이스에 제출하는 과정을 포함할 수 있으며, 여기서 데이터베이스는 쿼리의 기준(criteria)와 매칭되는 정보를 찾고, 데이터를 반환할 수 있다. 개발자는 클라이언트 디바이스(122)를 통해 쿼리 테스트 시스템(114)에 쿼리를 제출할 수 있다. 쿼리 테스트 시스템(114)은 개발자가 제1 데이터베이스에 데이터를 저장하기 위해 사용되는 동일한 스키마에 반하여 테스팅 기능을 위한 쿼리들을 작성하고 제출할 수 있는 웹 인터페이스를 호스팅할 수 있다.

210 단계에서, 쿼리 테스트 시스템(114)은 쿼리가 테스트 데이터베이스(108)에서 성공적으로 완료되었는지 여부를 결정할 수 있다. 쿼리 테스트 시스템(114)이 쿼리가 실패했다고 결정하면(예를 들어, 테스트 데이터베이스로부터 에러 메시지의 존재 또는 부존재를 감지), 210 단계는 "No"로 수행될 수 있고, 쿼리 테스트 시스템은 212 단계를 수행하여 쿼리가 실패했다는 경고를 반환할 수 있다. 쿼리 테스트 시스템(114)은 개발자로 하여금 쿼리 테스트 실패의 원인을 결정할 수 있도록, 에러 리포트를 제공할 수 있다. 다만, 쿼리 테스트 시스템(114)이 쿼리가 테스트 데이터베이스에서 성공적으로 완료된 것으로 결정하면, 210 단계는 "Yes"로 수행될 수 있고, 쿼리 테스트 시스템은 214 단계를 수행할 수 있다. 쿼리 테스트 시스템은 쿼리가 성공했음을 나타내는 표시를 개발자에게 제공할 수 있고, 프로세스(200)의 다음 단계들을 수행하기 위한 허가를 요청할 수 있다.

214 단계에서, 쿼리 테스트 시스템(114)은 쿼리에서 프레디케이트(predicate)들을 식별할 수 있고, 각 프레디케이트는 컬럼 이름을 포함할 수 있다. 프레디케이트들은 예를 들어, 반드시 선택되어야만 하는 엔트리들을 위한 조건을 지시하는 데이터베이스 쿼리의 요소들을 포함할 수 있다. 예를 들어, 쿼리가 SQL 쿼리에 해당하면, 프레디케이트는 데이터베이스 컬림을 위한 값을 나타내는 쿼리 "WHERE" 문의 조건일 수 있다.

도 3은 실시예들에 따른 단계 214 에서 개시된 쿼리 변형(vairations)의 생성을 나타낸다. 도 3은 SQL 쿼리에 해당할 수 있는 수신된 쿼리를 개시한다. 도 3의 수신된 쿼리(302)는 개발자에 의하여 제공된 테스트 쿼리로, 프로덕션 데이터베이스와 동일한 데이터베이스 스키마를 가지는 테스트 데이터베이스에 저장된 인공적인 데이터를 나타낼 수 있다. 예를 들어, "Tom" 이라는 이름은 테스트 데이터베이스에 인공적인 엔트리로 보일 수 있으나, 실제 데이터를 가지는 프로덕션 데이터베이스에서는 보이지 않을 수 있다. 제1 프레디케이트(304)는 "name = 'Tom'"이고, 제2 프레디케이트(306)는 "purchase = 'rice'"를 나타낼 수 있다. 따라서, 제1 프레디케이트는 "name" 컬럼에 관한 것이고, 제2 프레디케이트는 "purchase" 컬럼에 관한 것일 수 있다. 상술한 예에서, 쿼리에 포함된 데이터가 인공적인 데이터이기 때문에, 제1 프레디케이트 및 제2 프레디케이트의 값들을 버려질 수 있다.

프레디케이트들을 식별하기 위하여, 214 단계는 프레디케이트를 식별하고 각 프레디케이트의 컬럼 이름 및 값을 추가로 식별하기 위해 쿼리 텍스트에 대해 문자 패턴을 식별하고 추출하는 방법인 정규 스크립트(regular script)를 실행하는 단계를 포함할 수 있다. 스크립트들은 스크립트에 의해 평가되는 패턴과 약간 다른 프레디케이트를 식별하는 퍼지 매칭 테크닉(fuzzy matching techniques)이 포함될 수 있다. 일부 실시예들에서, 퍼지 매칭 프레디케이트들(패턴으로부터 작은 변형을 포함하는 매칭을 찾는데 도움이 되는) 및 수학적인 테스트들(예를 들어, 숫자 비교)인 생략될 수 있다. 프레디케이트들에 대하여 구두점 및 공백을 제거하는 등 프레디케이트 데이터를 표준화하기 위한 처리 과정을 수행될 수 있다. 또한, 일부 실시예들에서, 개발자는 동일한 컬럼 이름을 포함하는 여러 프레디케이트들로 쿼리 초안을 작성할 수 있다. 또한, 쿼리 테스트 시스템(114)은 쿼리로부터 파생된 컬럼 이름의 리스트가 중복 값을 가지지 않도록, 컬럼 이름에 따라 프레디케이트들을 중복 제거(deduplicate)할 수 제거할 수 있다. 214 단계는 쿼리의 컬럼 이름 세트로 마무리될 수 있다. 예를 들어, 도 3에서, 수신된 쿼리(302)의 예시에 해당하는 SQL 쿼리는 컬럼 이름들 "name" 및 "purchase"를 결정하기 위해 프로세스될 수 있다.

도 2로 돌아오면, 216 단계에서, 쿼리 테스트 시스템(114)은 제2 데이터베이스(106)를 쿼리하여, 각 컬럼 이름에 대한 가장 공통적인 값들을 결정할 수 있다. 쿼리 테스트 시스템은 발생 횟수에 따라 컬럼의 엔트리를 집계, 카운트 및 정렬할 수 있도록 쿼리를 구성할 수 있다. 상술한 방법을 통하여, 쿼리 테스트 시스템은 컬럼 이름에 대응하는 컬럼에 포함된 각 값의 개수를 결정할 수 있다. 상술한 단계는 도 3에서 더 구체적으로 후술한다. 수신된 쿼리(302)에서 컬럼 이름들 "name" 및 "purchase"를 식별한 뒤, 쿼리 테스트 시스템은 오프라인 데이터베이스의 "name" 컬럼 및 "purchase" 컬럼에 포함된 엔트리들을 리뷰할 수 있다. 예를 들어, 오프라인 데이터베이스는 10개 행의 엔트리들을 포함할 수 있다. 표 308에 도시된 바와 같이, 10개의 행 중 "name" 컬럼은 "John"을 5번, "Chris"를 3번, "Allen"을 2번 기록할 수 있다. 마찬가지로, 표 310에 도시된 바와 같이, "purchase" 컬럼은 "burrito", "sandwich" 및 "soup"의 값들로 구성될 수 있다. 상술한 표들의 가장 공통적인 값들은 상위 두 엔트리로 결정될 수 있다. 따라서, 표 308의 가장 공통적인 값들은 "John" 및 "Chris"을 나타내고, 표 310의 가장 공통적인 값들은 "Burrito" 및 "Sandwich"를 나타낼 수 있다.

제1 데이터베이스(104)에 포함된 엔트리들의 삭제 또는 추가로 인한 전체 엔트리들의 개수 변화를 수용하기 위하여, 쿼리 테스트 시스템(114)는 각 값에 대하여 컬럼에 포함된 전체 엔트리들의 개수 대비 결정된 개수에 대응하는 비율(fraction)을 계산함으로써 각 컬럼을 위한 가장 공통적인 값들을 찾을 수 있다. 가장 공통적인 값들은 컬럼에 더 자주 나타나는 컬럼의 값을 나타낼 수 있다. 따라서, 예를 들어, 기 설정된 임계 개수(또는 임계값)보다, 컬럼에서 더 많이 나타내는 값들은 상술한 컬럼을 위한 가장 공통적인 값들에 해당할 수 있다. 예를 들어, 의류 아이템들의 데이터베이스는 데이터베이스에 포함된 각 아이템에 대한 의류 타입을 위한 값을 기록하는 컬럼을 포함할 수 있다. 만약 데이터베이스가 신발들을 위해 10개 엔트리들, 코트들을 위한 50개의 엔트리들, 셔츠들을 위해 40개의 엔트리들을 포함하면, 쿼리 테스트 시스템은 신발들을 위한 0.1(예를 들어, 10/100)의 값, 코트들을 위한 0.5의 값 및 셔츠들을 위한 0.4의 값을 계산할 수 있다. 쿼리 테스트 시스템은 값들 각각에 대응하는 비율들에 기반하여 값들을 정렬할 수 있다. 따라서, 의류 데이터베이스를 계속해서 예시로 들자면, 쿼리 테스트 시스템은 코트들, 셔츠들, 신발들 순으로 값들을 정렬할 수 있다. 쿼리 테스트 시스템은 리스트를 분석하고 선택된 값에 대응하는 비율의 합이 비율 임계값 보다 클 때까지 가장 높은 비율을 가지는 선택되지 않은 값을 반복적으로 선택할 수 있다. 상술한 임계값은 쿼리를 제출할 때 개발자에 의하여 기 설정되거나 쿼리 테스트 시스템의 코드에서 기 설정될 수 있다. 의류 데이터베이스 예시에서, 만약 임계값이 0.4로 설정되었다면, 쿼리 테스트 시스템은 코트들을 위한 비율(0.5)과 임계값(0.4)을 비교하여 코트들을 216 단계를 위한 "가장 공통적인 값들"로 결정할 수 있다. 대신, 만약 임계값이 0.7(예를 들어, 선택된 쿼리들이 전체 엔트리들의 70%를 구성해야 함을 나타냄)로 설정되었다면, 쿼리 테스트 시스템은 코트들(0.5)로 시작하여, 코트들이 엔트리의 임계값 0.7 미만을 구성한다고 결정할 수 있다. 쿼리 테스트 시스템은 다음으로 높은 엔트리, 즉 셔츠들로 진행하고, 코트들 및 셔츠들이 전체 엔트리들의 0.9(0.5+0.4)를 구성한다고 결정할 수 있다. 0.9가 0.7보다 크므로, 쿼리 테스트 시스템은 데이터베이스에서 가장 공통적인 값들로 "코트들" 및 "셔츠들"을 식별할 수 있다.

218 단계에서, 쿼리 테스트 시스템(114)는 각 컬럼 이름에 대하여, 적어도 하나의 가장 공통적인 값들을 포함하는 리스트(list)를 생성할 수 있다. 상술한 리스트는 216 단계에서 식별된 값들의 전부 또는 서브셋을 포함할 수 있다. 예를 들어, 서브셋은 값들의 랜덤 선택 또는 n개의 가장 공통적인 값들에 기반하여 식별될 수 있다. n은 정수를 나타낼 수 있다. 코드들, 셔츠들 및 신발들의 예시를 계속하면, 218 단계에서, 쿼리 테스트 시스템은 코트들 및 셔츠들을 포함하는 리스트를 생성할 수 있다. 추가적인 예시로, 상술한 바와 같이, 도 3의 표 308은 "name" 컬럼에 포함된 각 엔트리의 개수를 나타낸다. 상술한 예시에서, 쿼리 테스트 시스템은 상위 두개의 가장 공통적인 값들을 선택하고, “’John', 'Chris'"를 나타내는 리스트(여기서, n=2)를 생성하도록 설정될 수 있다. 유사하게, 예를 들어, “purchase" 컬럼을 위한 리스트는 "'Burrito', 'Sandwich'"를 포함할 수 있다.

상술한 리스트는 다른 방법으로 식별된 추가적인 값들을 더 포함할 수 있다. 예를 들어, 쿼리 테스트 시스템(114)은 제1 데이터베이스의 히스토리컬(historical) 쿼리들을 포함하는 쿼리 저장소(110)에 액세스할 수 있고, 각 컬럼 이름에 대한 가장 공통적인 값들을 결정할 수 있다. 상술한 바와 같이, 쿼리 저장소는, 서버(102)가 웹사이트, 앱 등에 액세스하는 동안, 제1 데이터베이스가의 클라이언트 디바이스(122)에 의하여 생성된 히스토리컬 쿼리들을 기록할 수 있다. 쿼리 저장소는 쿼리 테스트 시스템에 컬럼 이름에 포함된 각 값이 프로덕션 쿼리에서 나타나는 횟수에 관한 개수를 제공할 수 있다. 컬럼 이름에 포함된 각 값이 프로덕션 쿼리에서 나타나는 횟수는 쿼리된 값(quaried value)으로 호칭된 수 있다. 쿼리 테스트 시스템은 상술한 값들을 분석하여 216 단계에서 개시하는 가장 공통적인 값들을 결정하는 방법과 가장 유사한 방법으로 가장 공통적으로 쿼리된 것을 결정할 수 있다.

쿼리 테스트 시스템(114)는, 218 단계에 후행하는 단계들에서 쿼리 변형을 생성하기 위해, 상술한 가장 공통적으로 쿼리된 값들 및 가장 공통적인 값들을 결합하여 리스트에 포함시킬 수 있다. 실시예들에서, 리스트는 가장 공통적인 쿼리된 값들 및 상기 가장 공통적인 값들의 교차(intersection)로 구성될 수 있다. 예를 들어, 가장 공통적인 값들이 신발들, 셔츠들 및 코트들이고 가장 공통적으로 쿼리된 값들이 바지들, 신발들 및 모자들이면, 쿼리 테스트 시스템은 두개의 값들의 세트에서 공통적인 값을 나타내는 신발들을 포함하는 리스트를 218 단계에서 생성할 수 있다.

실시예들에서, 개발지는 $50 보다 작은 아이템들 찾는 등과 같이 수학적인 비교를 포함하는 프레디케이트를 가지는 쿼리를 생성할 수 있다. 쿼리 테스트 시스템(114)은 이러한 종류의 쿼리를 위하여 가장 공통적인 수치 값들을 식별할 수 있다. 대체적으로 또는 추가적으로, 쿼리 테스트 시스템은 컬럼 이름에 대한 가장 포괄적인 범위를 식별할 수 있다. 예를 들어, 쿼리는 $50 보다 작은 아이템들을 찾을 수 있다. 쿼리 테스트 시스템은 “item price"이라는 이름을 가지는 컬럼이 최대 $250까지의 아이템들을 포함한다고 결정할 수 있다. 쿼리 테스트 시스템은 후행하는 단계에서 테스트 프레디케이트 및 쿼리를 생성하는 경우, $250를 사용할 수 있다.

도 2로 돌아오면, 220 단계에서, 쿼리 테스트 시스템(114)은 컬럼 이름들 중 어느 하나 및 컬럼 이름에 대응하는 리스트에 대한 엔트리를 포함하는 테스트 프레디케이트를 생성할 수 있다. 220 단계는 리스트에 포함된 각 값마다 반복될 수 있고, 쿼리에 포함된 각 컬럼 이름마다 반복될 수 있다. 206 단계에서 수신된 쿼리에 price, category 및 product name의 컬럼 이름을 가지는 세 개의 프레디케이트들이 포함되어 있고, 각 컬럼 이름이 4개의 가장 공통적인 값들을 가지고 있으면, 쿼리 테스트 시스템은 총 12개의 테스트 프레디케이트들을 생성할 수 있다. 상술한 단계는 도 3 에 도시되어 있다. 쿼리 테스트 시스템이 표 308 및 표 310에서 상위 두 개의 가장 공통적인 값들을 선택한 뒤, 쿼리 테스트 시스템은 각 컬럼 이름/컬럼 값 페어(pair)를 위한 테스트 프레디케이트를 생성할 수 있다. 따라서, 테스트 프레디케이트들(312)는 “name = 'John'" 및 "name = 'Chris'"을 포함하지만, "Allen"은 상위 두 개의 가장 공통적인 값들에 포함되어 있지 않기 때문에, “name = 'Allen'"은 포함하지 않을 수 있다. 유사하게, 테스트 프레디케이트는 “purchase = 'Burrito'" 및 "purchase = 'Sandwich'"를 포함할 수 있다.

도 2로 돌아오면, 쿼리 테스트 시스템(114)은 222 단계에서, 220 단계에서의 하나 또는 그 이상의 테스트 프레디케이트들을 포함하는 테스트 쿼리를 생성할 수 있다. 테스트 쿼리는 수신된 쿼리에 기반할 수 있고, 쿼리 테스트 시스템은 수신된 쿼리의 프레티케이트들을 테스트 쿼리의 프레디케이트들로 치환할 수 있다. 도 3은 222 단계에서 생성될 수 있는 복수의 테스트 쿼리들(316)을 도시한다. 테스트 쿼리들은 테스트 프레디케이트들(312), 테스트 프레디케이트들(314) 및 수신된 쿼리(302)의 구조의 조합에 기반할 수 있다. 따라서, 수신된 쿼리의 구조가 테스트 쿼리에서 유지될 수 있으나, 테스트 쿼리는 수신된 쿼리의 가짜(fake) 값을 가지는 프레디케이트들을 실제 및 가장 공통적인 값들을 포함하는 프레디케이트로 대체할 수 있다. 또한, 각각의 테스트 프레디케이트들(312)은 각각의 테스트 프레디케이트들(314)과 결합하여, 4개의 테스트 쿼리를 생성할 수 있다.

또한, 쿼리 테스트 시스템(114)은 프로세싱 시간 또는 리소스 사용에 무시할 수 있거나 표준적인 영향을 미치고 쿼리 결과를 저장하는 인스트럭션과 같이 변경된 프레디케이트들에 영향을 받지 않는 절(clause)들을 제거하거나 추가하기 위하여 수신된 쿼리를 수정할 수 있다. 이를 통해, 공통 기준(common baseline)에 대한 테스트 쿼리들을 더 빠르게 비교할 수 있다.

224 단계에서, 테스트 쿼리 시스템(113)은 제2 데이터베이스(106) 상의 테스트 쿼리들 각각을 실행할 수 있고, 226 단계에서, 쿼리의 리소스 사용률을 결정할 수 있다. 테스트 쿼리들은 데이터를 클라이언트에게 제공하는 것으로부터 제1 데이터베이스(104)를 방해하지 않고, 실제 데이터를 분석하기 위하여 제2 데이터베이스(106)에서 실행될 수 있다. 쿼리의 리소스 사용률은 테스트 쿼리의 누적, 최대 또는 평균 리소스 소비를 나타내는 메트릭(metric)일 수 있다. 실시예들에서, 리소스 사용률은 분석된 행(row)들, 프로세싱 시간 및 메모리 사용량 중 적어도 하나를 포함할 수 있다. 쿼리가 클라이언트에 의해 사용되도록 배치된 경우, 결정된 리소스 사용률을 개발자들로 하여금, 제1 데이터베이스의 리소스를 과도하게 소비할 가능성이 있는 위험한 쿼리들을 식별하는데 도움이 될 수 있다. 다시 말해, 테스트 쿼리들은 데이터베이스에서 가장 공통적인 값들을 사용하여 엔트리들을 위한 데이터를 검색하기 때문에, 테스트 쿼리들은 수신된 쿼리의 가장 리소스 집약적인 어플리케이션으로 나타내어 질 수 있다. 개발자들은 리소스 집약적인 어플리케이션의 가능성이 큰 쿼리 배포(deploy)를 자제할 수 있다. 추가적으로, 만약 테스트 쿼리들이 쿼리 저장소(110)에서 파생된 값들을 포함하면, 테스트 쿼리들은 실제 클라이언트의 상호 작용에 의해 정보를 받은 것처럼 가장 높은 가능성을 가지는 사용예를 나타낼 수 있다. 상술한 방법에 따라, 쿼리 테스트 시스템은 가장 공통적인 값들을 쿼리함으로써 최악의 시나리오에 해당하는 리소스 사용률을 추정할 있고, 가장 공통적인 값들을 쿼리함으로써 가장 가능성이 높은 리소스 사용률을 추정할 수 있다. 실시예들에서, 쿼리 테스트 시스템은 두 종류의 값들의 교차를 쿼리함으로써, 최악의 시나리오에 해당하는 리소스 사용률을 추정할 수 있다. 상술한 방법을 통하여, 많은 수의 가장 공통적인 값들과 프레디케이트들을 가지는 시나리오의 경우, 정확하고 빠른 쿼리 효율성 테스트를 제공할 수 있다. 쿼리 테스트 시스템은 가장 공통적인 값들을 포함하는 쿼리들의 히스토리컬 빈도에 기반하여 최악의 시나리오의 가능성 또는 리소스 사용률의 예측값을 계산할 수 있다.

228 단계에서, 쿼리 테스트 시스템(114)은 리소스 사용률이 임계값보다 큰지 여부를 결정할 수 있다. 상술한 임계값은 쿼리를 완료하는데 1 밀리세컨트(millisecond) 이상 걸리지 않은 것과 같은 회사 정책을 반영할 수 있다. 상술한 임계값은 가변적일 수 있으며, 가능성이 따라 달라질 수 있다. 예를 들어, 임계값은 시나리오의 99.999%에서 쿼리가 5 밀리세컨트 이내에 완료되어야 하거나, 시나리오의 99%에서 쿼리가 2 밀리세컨트 이내에 완료되도록 설정된다.

만약 리소스 사용률이 임계값 보다 작으면, 228 단계는 "NO"로 수행될 수 있다. 클라이언트에게 미치는 위험의 영향이 상당이 낮기 때문에, 쿼리 테스트 시스템(114)은 230 단계에서 제1 데이터베이스 상의 쿼리를 실행할 수 있다. 상술한 동작을 통하여 실제 데이터에 반하여 쿼리에 대한 추가적인 테스트를 제공할 수 있다. 제1 데이터베이스(104) 상의 쿼리의 리소스 소비량을 측정함으로써, 쿼리 테스트 시스템은 제1 데이터베이스(104) 및 제2 데이터베이스(106) 간의 차이점(예를 들어, 보안 세팅 또는 동시 쿼리로부터의 충돌)이 클라이언트 경험에 허용할 수 없는 영향을 초래한다고 결정할 수 있다. 상술한 방법을 통하여, 개발자들은 쿼리 리소스 소비량을 점진적으로 테스트하여, 우선적으로 기본 기능들을 테스트하고, 이후 최악의 시나리오들을 테스트하고, 마지막으로 위험한 쿼리를 식별하고 위험이 발생할 수 있는 환경에 놓이는 것을 방지할 수 있는 보호 장치를 사용하여 실제 환경에서의 성능을 테스트할 수 있다. 추가적으로, 실시예들에서, 쿼리 테스트 시스템(114)은 수신된 쿼리가 서버(102)에 로드(load)되도록 허용하고, 쿼리와 연관된 리소스 사용률이 낮다는 결정(예를 들어, 임계 리소스 사용률 미만인 경우)에 기반하여 프로덕션(production)에 들어갈 수 있다.

또한, 만약 리소스 사용률이 임계값보다 크면, 228 단계는 "YES"로 수행되고, 쿼리 테스트 시스템(114)은 232 단계를 수행하여, 효율성 향상 제안을 디스플레이를 위한 유저 인터페이스에 제공할 수 있다. 쿼리 테스트 시스템은 개발자들로부터 제공받은 휴리스틱스(heuristics)에 기반하여 효율성 향상 제안을 계산할 수 있다. 예를 들어, 개발자들은 쿼리 테스트 시스템에 쿼리 성능을 향상하기 위한 제안들을 제공할 수 있고, 상술한 제안들은 구현되기 어려운 변경 사항은 매우 비효율적인 쿼리에 대해 제공되고, 사소하게 비효율적인 쿼리에 대해서는 사소한 변경 사항이 제공되도록 설정된 리소스 사용률 범위에 대응하는 제안일 수 있다. 휴리스틱스는 중첩된 쿼리를 피하는 것과 같이 쿼리 효율성을 높이기 위해 개발자가 관찰한 방법을 포함할 수 있다. 추가적인 예시로, 쿼리 테스트 시스템은 쿼리 결과가 데이터베이스의 특정 섹션(section)에서 발견되도록 데이터베이스의 섹션이 정렬되었는지 여부를 결정하기 위해 데이터베이스를 분석할 수 있다. 예를 들어, 데이터베이스는 아이템 이름에 따라 알파벳 순으로 정렬될 수 있다. 쿼리 테스트 시스템은 알파벳 "s"로 시작하는 아이템들이 데이터베이스의 1787 번째 행에서 시작된다고 결정할 수 있고, 쿼리가 1787 번째 행에서 검색을 시작하도록 쿼리에 인덱스(index)를 추가하도록 하는 쿼리 효율성 제안을 제공할 수 있다.

실시예들에서, 쿼리 테스트 시스템(114)은 상술한 제안을 포함하는 쿼리를 자동적으로 생성하여, 개발자로 하여금 쿼리의 기존 성능과 수정된 쿼리의 성능을 비교할 수 있게 할 수 있다. 이 경우, 리소스 사용률은 제1 리소스 사용률일 수 있고, 쿼리를 판단(또는 평가)하는 단계를 추가적인 단계들을 더 포함할 수 있다. 쿼리 테스트 시스템은 효율성 향상 제안을 기반으로 쿼리를 수정할 수 있다. 예를 들어, 쿼리 테스트 시스템은 쿼리에 인덱스를 추가할 수 있다. 쿼리 테스트 시스템은 이후, 수정된 쿼리를 실행할 수 있다. 실시예들에서, 상술한 단계들은 수정된 쿼리에 기반하여 222 단계 내지 226 단계를 수행하는 단계를 포함할 수 있다. 쿼리 테스트 시스템은 수정된 쿼리의 제2 리소스 사용률을 결정할 수 있고, 제1 리소스 사용률 및 제2 리소스 사용률 간의 리소스 사용률 차이를 디스플레이를 위한 유저 인터페이스에 제공할 수 있다. 또한, 쿼리 테스트 시스템은 제1 데이터베이스(104) 상에서 수정된 쿼리를 실행할 수 있다.

프로세스(200)은 도 3에서 개시된 실시예들에 따른 쿼리 변형의 생성에 기반하여 수행될 수 있다. 도 3은 프로세스(200)의 206 단계 및 222 단계의 데이터 프로그레션(progression)의 예시를 나타낼 수 있다.

본 발명의 실시예들에 따르면, 데이터베이스 쿼리 효율 향상을 위한 컴퓨터로 구현되는 방법은 제1 데이터베이스를 제2 데이터베이스로 미러링하는 단계, 제2 데이터베이스는 스키마를 포함하고, 스키마를 포함하는 테스트 데이터베이스를 생성하는 단계, 쿼리를 수신하는 단계; 및 테스트 데이터베이스에서 쿼리를 실행하는 단계를 포함할 수 있다. 상술한 방법은 쿼리가 테스트 데이터베이스에서 성공적으로 완료된 것에 대응하여, 쿼리를 판단하는 단계를 더 포함할 수 있고, 쿼리를 판단하는 단계는, 쿼리에서 프레디케이트들을 식별하는 단계, 각 프레디케이트는 특정 컬럼 이름을 포함하고, 제2 데이터베이스를 쿼리하여, 각 컬럼 이름에 대한 가장 공통적인 값들을 결정하는 단계, 쿼리 저장소를 쿼리하여, 각 컬럼 이름에 대한 가장 공통적인 쿼리된 값들을 결정하는 단계, 각 컬럼 이름에 대하여, 적어도 하나의 가장 공통적인 값들 및 적어도 하나의 가장 공통적인 쿼리된 값들을 포함하는 리스트를 생성하는 단계, 컬럼 이름들 중 어느 하나 및 컬럼 이름에 대응하는 리스트에 대한 엔트리를 포함하는 테스트 프레디케이트를 생성하는 단계, 테스트 프레이케이드들의 조합을 포함하는 테스트 쿼리를 생성하는 단계, 제2 데이터베이스에서 테스트 쿼리들 각각을 실행하여 쿼리 프로세싱 시간을 결정하는 단계 및 쿼리 프로세싱 시간의 최대값이 임계값보다 작은 경우, 제1 데이터베이스에서 쿼리를 실행하는 단계를 포함할 수 있다.

상술한 개시가 특정 실시예에 참조하여 도시되고 설명되었으나, 상술한 개시는 다른 환경에서 수정 없이 실행될 수 있는 것으로 이해되어야 한다. 상술한 설명은 예시의 목적으로 제공되었다. 상술한 개시 또는 예시를 완전하지 않으며, 정확한 형태 또는 실시예로 제한되지 않는다. 개시된 실시예들에 대한 수정 및 개조는 통상의 기술자 입장에서 명백할 수 잇다. 추가적으로, 개시된 실시예들이 모두 메모리에 저장되는 것으로 설명하고 있으나, 통상의 기술자는 개시된 실시예들이 보조 저장 장치(예를 들어, 하드 디스크 또는 하드 디스크와 같은 다른 유형의 컴퓨터 판독 가능한 저장 매체, CD ROM 또는 다른 형태의 RAM, ROM, USB 미디어, 블루레이 또는 광학 드라이브 미디어)에 저장될 수 있음은 명백하다.

본 명세서에서 설명하는 방법들 및 개시들에 기반한 컴퓨터 프로그램은 숙련된 개발자의 기술 범위 내에 있을 수 있다. 다양한 프로그램 또는 프로그램 모듈은 통상의 기술자에게 공지된 임의의 기술을 사용하여 생성될 수 있거나, 기존 소프트웨어를 사용하여 설계될 수 있다. 예를 들어, 프로그램 섹션 또는 프로그램 모듈은 .Net Framework, .Net Compact Framework (및/또는 Visual Basic, C와 같은 관련 언어들), Java, C++, Objective-C, HTML, HTML/AJAX combinations, XML, 또는 Java applets을 포함하는 HTML을 사용하여 디자인될 수 있다.

또한, 예시적인 실시예들이 본 명세서에서 설명되었으나, 통상의 기술자가 인식할 수 있는 바와 같이, 등가적인 요소의 수정, 생략, 조합, 적응 및/또는 변형이 가능하다. 청구항들에 기재된 제한 사항은 청구항에 기재된 단어 또는 언어에 기반하여 최광의로 광범위하게 해석되어야 하며, 본 명세서에 기대된 예시 또는 실시예들에 의하여 제한 또는 한정되지 않는다. 실시예들은 비독점적으로 해석되어야 할 수 있다. 또한, 개시된 방법 및/또는 단계는 단계들 간의 재정령, 삭제 및/또는 삽입이 가능하며, 임의의 방식에 따라 수정될 수 있다. 명세서 및 실시예들은 예시적인 것으로 간주되어야 하며, 진정한 권리 범위는 후술되는 청구항 및 그 균등물의 전체 범위에 의해 표시될 수 있다.

Claims (11)

1. 쿼리에서 프레디케이트(predicate)들을 식별하고―각 프레디케이트는 컬럼 이름을 포함함―;
   각 컬럼 이름에 대한 가장 공통적인 값들을 결정하고;
   각 컬럼 이름에 대하여, 상기 가장 공통적인 값들 중 적어도 하나를 포함하는 리스트를 생성하고;
   상기 컬럼 이름 중 하나와 상기 컬럼 이름에 대응하는 상기 리스트에 대한 엔트리(entry)를 포함하는 테스트 프레디케이트를 생성하고;
   하나 이상의 테스트 프레디케이트를 포함하는 테스트 쿼리를 생성하고;
   상기 쿼리의 리소스 사용률(resource utilization)을 결정하고; 그리고
   효율성 향상 제안을, 디스플레이를 위한 유저 인터페이스에 제공하는 것을 포함하는,
   데이터베이스 쿼리 효율 향상을 위한 컴퓨터로 구현되는 방법.
2. 청구항 1에 있어서,
   상기 리스트는,
   제1 데이터베이스의 히스토리컬 쿼리들을 포함하는 쿼리 저장소를 쿼리하여 결정된 각 컬럼 이름에 대한 가장 공통적인 쿼리된 값들을 더 포함하는,
   데이터베이스 쿼리 효율 향상을 위한 컴퓨터로 구현되는 방법.
3. 청구항 2에 있어서,
   상기 리스트는,
   상기 가장 공통적인 쿼리된 값들과 상기 가장 공통적인 값들의 교차(intersection)로 구성된,
   데이터베이스 쿼리 효율 향상을 위한 컴퓨터로 구현되는 방법.
4. 청구항 2에 있어서,
   상기 리스트는,
   n개의 가장 공통적인 값들을 포함하는,
   데이터베이스 쿼리 효율 향상을 위한 컴퓨터로 구현되는 방법.
5. 청구항 1에 있어서,
   상기 효율성 향상 제안은,
   상기 쿼리에 인덱스를 추가하는 것을 포함하는,
   데이터베이스 쿼리 효율 향상을 위한 컴퓨터로 구현되는 방법.
6. 청구항 1에 있어서,
   상기 리소스 사용률은 제1 리소스 사용률이고,
   상기 방법은
   상기 효율성 향상 제안을 기반으로 상기 쿼리를 수정하고;
   상기 수정된 쿼리의 제2 리소스 사용률을 결정하고; 그리고
   상기 제1 리소스 사용률과 상기 제2 리소스 사용률 간의 리소스 사용률 차이를, 디스플레이를 위한 상기 유저 인터페이스에 제공하는 것을 더 포함하는,
   데이터베이스 쿼리 효율 향상을 위한 컴퓨터로 구현되는 방법.
7. 청구항 1에 있어서,
   각 컬럼 이름에 대한 가장 공통적인 값들을 결정하는 것은,
   상기 컬럼 이름에 대응하는 컬럼에 포함된 각 값의 개수를 결정하고;
   각 값에 대하여, 엔트리들의 전체 개수에 대한 상기 결정된 개수에 대응하는 비율(fraction)을 계산하고;
   상기 값들에 대응하는 계산된 비율들 각각에 기반하여, 상기 값들을 정렬하고; 그리고
   선택되지 않은 값들을 반복적으로 선택하는 것―상기 선택되지 않은 값들 각각은 상기 선택된 값들에 대응하는 비율들의 합이 비율 임계값을 초과할 때까지 가장 높은 비율을 가짐; 을 포함하는,
   데이터베이스 쿼리 효율 향상을 위한 컴퓨터로 구현되는 방법.
8. 청구항 1에 있어서,
   상기 방법은
   상기 리소스 사용률이 임계값보다 작은 경우, 상기 쿼리를 제1 데이터베이스에서 실행하는 것을 더 포함하는,
   데이터베이스 쿼리 효율 향상을 위한 컴퓨터로 구현되는 방법.
9. 청구항 1에 있어서,
   상기 리소스 사용률은,
   분석된 행들, 프로세싱 시간 및 메모리 사용량 중 적어도 하나를 포함하는,
   데이터베이스 쿼리 효율 향상을 위한 컴퓨터로 구현되는 방법.
10. 청구항 1에 있어서,
    상기 방법은
    컬럼 이름에 따라 프레디케이트들을 중복 제거(deduplicate)하는 것을 더 포함하는,
    데이터베이스 쿼리 효율 향상을 위한 컴퓨터로 구현되는 방법.
11. 인스트럭션을 저장하는 메모리; 및
    상기 인스트럭션을 실행하여 청구항 1 내지 청구항 10 중 어느 한 항에 기재된 방법을 수행하는 적어도 하나의 프로세서를 포함하는,
    데이터베이스 쿼리 효율 향상을 위한 컴퓨터로 구현되는 시스템.

Images