CUBRID를 사용하면서 하지 말아야 할 것 10가지

 

 

1. 오프라인 교육 안 받고 매뉴얼 안 보고 사용
   • "R-DBMS가 거기서 거기지", "DB많이 써 봐서 난 다 알아"
     같은 R-DBMS이더라도 벤더사에 따라 그 Spec이나 syntax에서 차이가 발생하며, 사용하고자 하는 기능의 차이로 여러 이슈가 발생할 가능성이 있습니다.
     이를 간과하고 개발하는 경우가 종종 발생하고 있습니다.
      
   • (주)큐브리드에서 분기마다 온라인 교육을 온라인( http://www.cubrid.com/education )으로 신청받고 있으며, 매뉴얼도 제공하고( http://www.cubrid.org/documentation/manuals/) 있습니다.
     차이점을 우선 인지하시고 운용이 되어야겠습니다.
      
2. 잘못된 데이터 타입 선택
   ​테이블 생성 시, 테이터 타입을 정하는 것은 무척 쉬워 보이나 데이터가 누적된 후에는 문제점을 발견해도 변경하기가 곤란할 때가 많습니다.
   잘못된 테이터 타입은 성능과도 연관있으며, 모든 DBMS에 연관이 있습니다.
   • CHAR VS VARCHAR : 고정길이와 가변길이이 차이로 공간낭비가 발생하며 컬럼 시 trim()같은 특정함수를 사용 할 필요가 발생할 수 있습니다.
   • CHAR,VARCHAR VS DATE : 데이터 정합성이 깨어질 수 있습니다.
   • VARCHAR VS NUMBER : 잘못된 데이터가 입력될 가능성이 있습니다. 숫자를 저장해야 하는데 문자가 입력될 수 도 있습니다.
      
3. ASIS-DB에서 사용하던 질의문을 그대로 사용
   • CUBRID는 ANSI SQL 표준 및 확장된 SQL 지원하고 있습니다. 각 DBMS마다 이러한 표준을 따르는 곳도 있고, 표준 외에 것을 지원하는 벤더사들도 존재합니다.
     표준에서 벗어나는 질의문들은 CUBRID에서 지원하지 않을 수 있으니, 표준에 맞추어 질의문을 변경해 주셔야 합니다.
      
4. PK, INDEX없이 사용 하기
   • 기존 DBMS의 설계 파악이 되지 않고 , 데이터만 이관하여 바로 적용하는 경우, 사용자 테이블에  Primary Key 나 NDEX가 존재하지 않은 경우가 있습니다. 다른 벤더사에서 제공하는 DB에서는 이러한 key가 존재하지 않은 경우에  임시key를 생성 주기도 하지만 CUBRID에서는 사용자가 직접 생성해 주어야 합니다. 
   • 이러한 경우 Full-scan이 발생되면서 속도 지연이슈가 가장 많이 발생합니다.
      
5. 무분별한 view를 마구잡이로 사용
   • 일반적인 view는 논리적인 view고, 특정 DB에서는 Materialized View 라고 하는 물리적인 구조를 지닌 view를 제공하고 있습니다. MView는 어떤 결과를 뽑아 내는 쿼리가 너무나도 빈번히 사용 될 경우, Query 실행 시간의 수행속도 향상을위하여 , 여러 가지의 Aggregate View를 두어, 미리 비용이 많이 드는 조인이나, Aggregate Operation 을 처리하여야 하는 SQL을 위해, 데이터베이스의 한 테이블로 저장 하며, 그 테이블을 조회 하도록 하는 것 입니다.
   • 그러나 CUBRID에서는 Materialized View와 같은 물리적인 View는 제공되지 않고, 논리적인view만 제공되고 있습니다. 
     물리적인 view보다 성능차이가 있으므로, 즉답을 화면에 출력해야하는 업무에서는 지양해야 할 필요가 있습니다.
      
6. 인덱스를 안 쓰거나 쓸모없는 인덱스만 생성하여 사용
   • 인덱스 분포도 (S=d/n)-(d=서로 다른 값의 수, n=테이블의 전체 레코드 수)  가 낮으면 지양합니다.
   • 자주쓰이는 where, group by 표현식에서 쓰이는 컬럼은 인덱스 생성을 고려해야 합니다.
   • 되도록 다중컬럼 인덱스로 생성합니다.
   • covering index에 대한 조사하여 적용이 필요합니다.
      
7. 실행계획 안 보고 질의문 사용(운영)
   • 모든 DBMS에서는 질의문이 수행되기 전 실행계획을 확인 할 수 있으며, CUBRID또한 이를 제공하고 있습니다.
     
     개발기간이 짧거나, 선별적 테스트로 동작여부만 확인하고  실행계획을 확인하지 않은상태에서  적용하는 경우에  운영 중 부하발생 시 속도지연 이슈가 발생할 수 있으므로
     실행계획을 꼭 확인하고 적용해야 할 것입니다.
      
8. 프로파일링이나 벤치마킹 않고 사용(운영)하기
   1. 개발 사이트에 따라 개발기간 혹은 이슈에 따라 프로파일링, 벤치마킹, 부하테스트 없이 운영되는 곳이 종종 있습니다. 
      (프로파일링: 병목 찾아내기, 벤치마킹: 시간에 따른 성능 변화 추이 평가, 부하테스트 : 서버가 견딜 수 있는 최대치 측정)
      
      초기에는 이슈가 발생하지 않을수도 있지만 데이터가 누적되거나, 사용자가 몰리는 기간이 있다면,  부하이슈가 발생할 가능성이 큽니다.
      그러므로 오픈전에 이러한 테스트를 필히 수행해 주셔야 합니다.
       
9. DBMS니까 알아서 복구 되겠지라고 생각
   1. 모든 DBMS는 복구를 지원하고 있으며, CUBRID또한 제공되고 있습니다.
      "복구"기능을 제공한다고 하여 모든 이슈에 대하여 복구 되는 것을 보장하지 않습니다. 
      적용하고자 하는 프로젝트에서 백업&복구 정책을 수립하고 그에 맞게 주기적(full혹은 increment)인 백업이 수행되어야 할 것입니다.
       
10. 오픈 소스니까 모든지 다 꽁짜라고 생각
    1. CUBRID는 오픈소스입니다.
    2. 오픈소스 소프트웨어는 저작권자가 소스코드를 공개하여 누구나 자유롭게 사용, 복제, 배포, 수정, 활용할 수 있는 소프트웨어를 지칭하는 것입니다.
       사용자 임의의 설정한 후, 최적화 작업 없이 오픈이 되는 경우 이슈가 발생할 가능성이 큽니다.
       (주)큐브리드에게 자문을 얻어 co-work하는 것을 권장하며, 이러한 경우 비용이 발생하게 됩니다.
        

 

CUBRID는 "국가정보자원관리원", "국방통합데이터센터", "온-나라 문서2.0및 기록물관리시스템", "광역시도 홈페이지", "네이버", "방송 및 민간기업"등의 많은 민간 및 공공서비스에서 사용 중에 있습니다.

최적화 작업을 수행하는 경우 동시접속자 몇천명도 소화가 가능하지만, 이러한 작업 없이 운영되는 경우 100명에서도 문제가 발생하며 적은 rows의 DB임에도 많은 이슈가 발생합니다.

다운받아 바로 사용하는 것이 아닌, 해당 업무와 성격에 따른 최적화 작업이 선행되어야 안정적인 시스템을 운용할 수 있겠습니다.

 

감사합니다.