안녕하세요.
큐브리드 사용시 궁금한점이 생겨서 문의드립니다.
스키마는 동일하고 테이블명만 다른 테이블이 두개가 있습니다.
A 테이블에는 사용자에게 노출하기 전의 자료가, B 테이블에는 사용자에게 노출하는 자료가 들어 있습니다.
관리자는 A, B 테이블을 union all로 묶은 뷰를 사용해서 조회를 하고, 사용자는 B 테이블만 조회를 합니다.
A 테이블에는 600개의 자료가, B 테이블에는 35만개 정도 자료가 들어 있습니다.
문제는 A, B 테이블 자료를 인덱스가 걸린 필드를 이용해 갯수를 쿼리해 보면 15ms 씩 걸립니다.
그런데 A, B 테이블이 묶여있는 뷰를 조회를 하게 되면 5초 이상 걸립니다.
관리자는 사용자에게 노출 해야될 자료, 노출하기 전의 자료를 모두 봐야 하기 때문에 뷰를 사용해야 합니다.
문제 해결 방안을 문의드립니다.
감사합니다.
첨부해주신 질의문과 질문시 테스트한 질의가 동일한가요?
SELECT COUNT(*)
FROM ho_article
WHERE gi > ''
AND gi LIKE '%중도일보%'
의 경우 ho_article의 인덱스 스캔을 수행하기는 하지만 '%중도일보%' 실제 인덱스 스캔의 효과를 보지 못하고 해당 인덱스 전체를 스캔합니다.
따라서 위 질의를 수행함에 있어서 많은 시간이 소요될 것으로 예상됩니다.(제 PC에서 테스트시에 5분이상 기다리다 강제 종료했습니다.)
view에서도 동일하게 union 중 해당 질의에서 많은 시간이 소요될 것으로 보여 집니다.
실제 view에 대한 plan을 보더라도 각 각의 질의를 수행할 때와 동일하게 해당 인덱스를 스캔하고 있습니다.
큐브리드 매니저 질의 편집기를 이용하여 view를 실행하기 전에 '질의 실행 보기' 버튼을 클릭하여 plan을 통해 확인하실 수 있을 것입니다.
따라서 좀더 검색 범위를 줄일 수 있는 조건이 포함될 수 있는지 여부를 확인해보시기 바랍니다.
안녕하세요.
제가 테스트 할때에는 길어도 5초 이내에 결과가 나오는데 반해 5분 이상 걸린다고 하셔서
좀전에 테스트한 결과를 캡쳐하여 첨부합니다.
확인 부탁드리겠습니다.
감사합니다.
제 PC가 문제일가요? 저는 ho_article에 대한 질의를 실행하면 결과가 나오지가 않네요.
혹시 DB를 재기동했을 때도 동일한 성능을 보이나요? ho_article 테이블이 메모리에 캐싱되어 있는 상태여서 빠른 결과가 나오고 있지는 않을 까 하는 생각이 드네요.
일단 내부에서 다른 장비로 좀더 확인을 해보도록 하겠습니다.
우회 방안으로 view를 사용하는 대신 view에서 사용된 union 질의문을 직접사용해보시기 바랍니다.
안녕하세요.
테스트중인 서버는 intel xeon E5506 2.13GHz, 4GB 하드웨어에 가상화 솔루션을 사용하여 2 CPU, 2GB Ram으로 테스트 중으로
하루에도 몇번씩 껏다가 켰다가를 반복해도 비슷한 결과를 보입니다.
그리고 첨부한 쿼리는 결과가 느리기는 하지만 현재 관리자 페이지에서 사용하고 있는 쿼리입니다.
큐브리드 성능 향상을 위해서라도 이 문제가 해결이 되었으면 합니다.
감사합니다.
안영하세요.
문의하신 내용을 window, linux 각각 테스트해 봤지만 view 조회 시간차이가 거의 없습니다. 다만 테이블(ho_article_pre, ho_article, v_ho_article) 검색 순서 따라 차이가 발생하는데 이는 데이터가 메모리에 캐싱되어 있는 상태에 따라 차이 발생할 수 있어 view에 문제가 아닌 것으로 판단 됩니다.
안녕하세요
주신 데이터와 말씀하신 순서대로 ho_artiicle_pre->ho_article->view 조회 쿼리를 실행하니까 View 에 대한 질의 수행 시간이 상대적으로 더 깁니다. (저는 1.092초) 물론 위 댓글의 다른 분들처럼 view에 먼저 조회 쿼리를 날리면 캐싱된 데이터가 없어서 수 초~분단위로 훨씬 오래 걸릴 것입니다.
큐브리드에서 뷰에 대해 count 질의를 수행하실 때 엔진 내부적으로는 뷰로 정의한 테이블 A에 대해 인덱스를 타서 결과를 추출하고(짧게 걸림) 테이블 B에 대해 인덱스 타서 결과를 추출하고(짧게 걸림) 이 각각의 결과를 UNION ALL하여 이를 순차스캔하면서 카운트를 수행(길게 걸림)하기 때문에 당연히 A,B테이블을 UNION ALL하여 정의한 현재의 뷰에 대한 질의의 실행 시간이 길게 소요되는 것입니다. 이는 다른 DB도 마찬가지로 동작할 것 같네요. 따라서, 이를 고려하시어 카운트 쿼리는 각각 테이블에 수행하고 합산을 하는 것으로 처리하시는 것이 훨씬 빠를 것입니다.
안녕하세요.
저는 각각의 테이블에 인덱스가 있으면 뷰도 빠른 결과를 낼 수 있울쥴 알았는데, 그런 문제가 있네요.
그러면 쿼리 날리는 방법을 조정해서 성능을 개선하도록 하겠습니다.
답변 감사합니다.
가능하시면 각 테이블 스키마(인덱스 포함)와 sql, view를 올려주시기 바랍니다.
둘 사이의 어떤 차이가 있을 것 같은데 설명만으로는 판단하기 어렵네요.