자격증/정보처리기사 📌 [정보처리기사] SQL 활용 - ORM(Object-Relational Mapping)/쿼리 성능 최적화
  • 728x90
    반응형

     

    데이터베이스 구축 - SQL 활용


     

    목차

       

      ORM(Object-Relational Mapping)의 개요

      📌 ORM은 객체지향 프로그래밍의 객체(Object)와 관계형 데이터베이스(Relational Database)의 데이터를 연결(Mapping)하는 기술을 의미한다.

       

      • 객체지향 언어에서 클래스와 테이블은 서로가 기존부터 호환가능성을 두고 만들어진 것이 아니기 때문에 불일치가 발생하는데, 이를 ORM을 통해 객체 간의 관계를 바탕으로 SQL문을 자동으로 생성하여 불일치를 해결한다. 따라서 ORM을 이용하면 따로 SQL문을 짤 필요 없이 객체를 통해 간접적으로 데이터베이스를 조작할 수 있게 된다.
      • ORM은 객체지향 프로그래밍에서 사용할 수 있는 가상의 객체지향 데이터베이스를 만들어 프로그래밍 코드와 데이터를 연결한다.
      • ORM으로 생성된 가상의 객체지향 데이터베이스는 프로그래밍 코드 또는 데이터베이스와 독립적이므로 재사용 및 유지보수가 용이하다.
      • ORM은 SQL 코드를 직접 입력하지 않고 선언문이나 할당 같은 부수적인 코드가 생략되기 때문에 직관적이고 간단하게 데이터를 조작할 수 있다.

       

       

       

       

      ORM의 장단점

      • 장점
        • 완벽한 객체지향적인 코드
          • ORM을 이용하면 SQL문이 아닌 클래스의 메서드를 통해 데이터베이스를 조작할 수 있어, 개발자가 객체 모델만 이용해서 프로그래밍을 하는 데 집중할 수 있게 한다. SQL 문을 사용하면서 같이 필요한 선언문, 할당, 종료 같은 부수적인 코드가 사라지거나 줄어들며, 각종 객체에 대한 코드를 별도로 작성하여 코드의 가독성을 높일 수 있다. 객체지향적 접근과 SQL의 절차적/순차적 접근이 혼재되어 있던 기존 방식과 달리 오직 객체지향적 접근만 고려하면 되기 때문에 생산성이 증가한다.
        • 재사용, 유지보수, 리팩토링 용이성
          • ORM은 기존 객체와 독립적으로 작성되어 있고, 객체로 작성되었기 때문에 재활용할 수 있다.
        • DBMS(DataBase Management System) 종속성 하락
          • 객체 간의 관계를 바탕으로 SQL문을 자동으로 생성하고, 객체의 자료형 타입까지 사용할 수 있기 때문에 RDBMS의 데이터 구조와 객체지향 모델 사이의 간격을 좁힐 수 있다.
      • 단점
        • ORM은 프레임워크가 자동으로 SQL을 작성하기 때문에 의도대로 SQL이 작성되었는지 확인할 필요가 있다.
        • 객체지향적인 사용을 고려하고 설계된 데이터베이스가 아닌 경우 프로젝트가 크고 복잡해질수록 ORM기술을 적용하기 어려워진다.
        • 기존의 기업들은 ORM을 고려하지 않은 데이터베이스를 사용하고 있기 때문에 ORM에 적합하게 변환하려면 많은 시간과 노력이 필요하다.

       

      ORM 프레임워크

      📌 ORM 프레임워크는 ORM을 구현하기 위한 구조와 구현을 위해 필요한 여러 기능들을 제공하는 소프트웨어를 의미한다.

       

      • ORM 프레임워크의 종류
      JAVA JPA, Hibernate, EclipseLink, DataNucleus, Ebean 등
      C++ ODB, QxOrm 등
      Python Django, SQLAlchemy, Storm 등
      iOS DatabaseObject, Core Data 등
      .NET NHibernate, DatabaseObjects, Dapper 등
      PHP Doctrine, Propel, RedBean 등

       

      💡 JPA(Java Persistent API) : 자바 ORM(Object Relational Mapping) 기술에 대한 API 표준 명세를 뜻한다.
      💡 Hibernate : JPA를 구현한 구현체이다. 대중적으로 많이 이용되는 JPA 구현체 중 하나이다.
      💡 EclipseLink, DataNucleus : JPA를 구현한 구현체
      💡 Ebean : Java와 Kotlin을 위한 ORM 라이브러리
      💡 Django : Python의 오픈 소스 웹 프레임워크이자 풀 스택 프레임워크이다.
      💡 SQLAlchemy : Python에서 사용 가능한 ORM

       

       


       

       

      쿼리 성능 최적화의 개요

      📌 쿼리 성능 최적화는 데이터 입/출력 애플리케이션의 성능 향상을 위해 SQL 코드를 최적화하는 것이다.

       

      • 쿼리 성능을 최적화하기 전에 성능 측정 도구인 APM을 사용하여 최적화 할 쿼리를 선정해야 한다.
      • 최적화 할 쿼리에 대해 옵티마이저가 수립한 실행 계획을 검토하고 SQL 코드와 인덱스를 재구헝한다.
      • RBO VS CBO
        • RBO(Rule Based Optimizer)는 규칙 기반 옵티마이저이고, CBO(Cost Based Optimizer)는 비용 기반 옵티마이저 로서 다음과 같은 차이점이 있다.
        RBO CBO
      최적화 기준 규칙에 정의된 우선순위 액세스 비용
      성능 기준 개발자의 SQL 숙련도 옵티마이저의 예측 성능
      특징 실행 계획 예측이 쉬움 성능 통계치 정보 활용, 예측이 복잡합
      고려사항 개발자의 규칙 이해도, 규칙의 효율성 비용 산출 공식의 정확성

       

      💡 APM(Application Performance Management/Monitoring) : APM은 애플리케이션의 성능 관리를 위해 접속자 자원 현황, 트랜잭션 수행 내역, 장애 진단 등 다양한 모니터링 기능을 제공하는 도구이다. APM은 리소스 방식과 엔드투엔드(End-To-End)방식이 있으며 종류는 다음과 같다.
      💡 리소스 방식 : Nagios, Zabbix, Cacti 등
      💡 엔드투엔드 방식 : VisualVM, 제니퍼, 스카우터 등

      💡 옵티마이저(Optimizer)
      - 옵티마이저는 작성된 SQL이 가장 효율적으로 수행되도록 최적의 경로를 찾아 주는 모듈로 RBO와 CBO 두 종류가 있다. 실무에서는 주로 CBO가 사용된다.
      - CBO 옵티마이저는 입/출력 속도, CPU 사용량, 쿼리의 블록 개수, 쿼리에 사용되는 개체의 속성, 튜플의 개수 등을 종합하여 각 DBMS마다 고유의 알고리즘에 따라 산출되는 '비용'을 계산한다. 그러므로 개체나 DBMS의 버전이 변경되어 알고리즘에 변화가 생기면 실행 계획을 다시 확인해야 한다.

       

       

       

      실행 계획(Execution Plan)

      📌 실행 계획은 DBMS의 옵티마이저가 수립한 SQL 코드의 실행 절차와 방법을 의미한다.

       

      • 실행 계획은 EXPLAIN 명령어를 통해 확인할 수 있으며, 그래픽이나 텍스트로 표현된다.
      • 실행 계획에는 요구사항들을 처리하기 위한 연산 순서가 적혀있으며, 연산에는 조인, 테이블 검색, 필터, 정렬 등이 있다.
      • 옵티마이저는 사용자가 쿼리를 실행하면 SQL문을 분석(Parsing)하여 SQL에 대한 실행 계획(Execution Plan)을 작성한 후, 실행 계획에 따라 데이터를 조작한다.

       

       

      쿼리 성능 최적화

      📌 쿼리 성능 최적화는 실행 계획에 표시된 연산 순서, 조인 방식, 테이블 조회 방법 등을 참고하여 SQL문이 더 빠르고 효율적으로 작동하도록 SQL 코드와 인덱스를 재구성하는 것을 의미한다.

       

      • SQL 코드 재구성
        • WHERE 절을 추가하여 일부 레코드만 조회하게 함으로써 조회에 들어가는 비용을 줄인다.
        • WHERE 절에 연산자가 포함되면 INDEX를 활용하지 못하므로 가능한 한 연산자 사용을 자제한다.
        • 서브 쿼리에 특정 데이터가 존재하는지 확인할 때는 IN보다 EXISTS를 활용한다.
        • 옵티마이저의 실행 계획이 잘못되었다고 판단되는 경우 힌트를 활용하여 실행 계획의 액세스 경로 및 조인 순서를 변경한다.
      • 인덱스 재구성
        • SQL 코드에서 조회되는 속성과 조건들을 고려하여 인덱스를 구성한다.
        • 실행 계획을 참고하여 인덱스를 추가하거나 기존 인덱스의 열 순서를 변경한다.
        • 인덱스의 추가 및 변경은 해당 테이블을 참조하는 다른 SQL문에도 영향을 줄 수 있으므로 신중히 결정한다.
        • 단일 인덱스로 쓰기나 수정 없이 읽기로만 사용되는 테이블의 경우 IOT(Index Organized Table)로 구성하는 것을 고려한다.
        • 불필요한 인덱스를 제거한다.

       

      💡 EXSTS : 서브 쿼리의 모든 데이터를 확인하는 IN과 달리 데이터의 존재 여부가 확인되면 검색이 종료되므로 보다 처리 속도가 빠르다.
      💡 힌트 : SQL문에 추가되어 테이블 접근 순서를 변경하거나, 인덱사 사용을 강제하는 등의 실행 계획에 영향을 줄 수 있는 문장을 의미한다.
      💡 IOT(Index-Organized Table) : 일반적으로 인덱스가 있는 테이블을 조회할 때, 인텍스를 검색하여 주소를 얻으면 주소를 다시 찾아 가는 과정을 거친다. 반면 IOT는 인덱스 안에 테이블 데이터를 직접 삽입하여 저장함으로써 주소를 얻는 과정이 생략되어 더욱 빠른 조회가 가능하다.

       

       

       

       

       

      728x90
      반응형
    상단으로