kkey21a
4k
2013-09-02 17:20:44
41
12590

약 4~5만건 화면 출력 관련해...


약 4~5만 건의 데이터를 화면에 출력하여야 하는 상황인데, 쿼리 속도가 생각보다 상당히 시간이 걸리네요. 조금 더 정확히 버퍼 풀에 올라가있지 않을 때에만요. (당연한거겠지만...)

그래서 쿼리 튜닝차 플랜을 떠봐도 실제 발생 비용보다 시간이 많이 걸려서 이대로 진행을 해야 하나 고민이 많이 되네요. 이제와서 해당 테이블에 파티션을 잡자니 사이즈가 대략 60G이상이라 마이그레이션 하자니 너무 부담이고 배치시간때문에 클러스터 잡기는 힘들고 이대로 메시지 하나 띄우고 오픈하자니 그렇고 보통 이런 경우 어떻게들 처리 하시나요? 일단, 현업과 얘기 후 한정적으로만 허용하자고 하고 진행하고 있기는 한데...마음속 한편으로 걸리네요.

PS
1. 현재 통계 생성은 새로 하였고, 리옥 작업은 고려중입니다. 그치만 딱히 해도 큰 변화는 없으리라 예상 되어서...

2. 화면에 4~5만건 이상 뿌려 주는 화면들 많이들 개발하시나요?
0
  • 답변 41

  • 피리아노
    595
    2013-09-02 17:20:32
    화면에 5만건이면 클라이언트 컴도 버겁겠네요~
    제가 썼던 방법은 jsp던 마이플랫폼이던 화면 페이징 해서 뿌렸습니다.
    일단 예로 들면 만건만 처음 화면에 뿌립니다. 그리고 이벤트로 스크롤이 끝까지 오면 그때 뒤이어서 만건 가져오고 또 그게 다 스크롤링 되면 만건 이런식으로 분할 해서
    동적 방식으로 표시 하였습니다. 로딩시간도 많이 줄고 사용자도 구지 전데이터를 다보는건 아니니 서로 윈윈 조건으로 성립이 되었습니다.
    다운로드야 프로세서 자체가 틀리니 상관없었구요~
  • luck_to
    44
    2013-09-02 17:24:19
    운영할때 대용량자료같은 경우 따로 프로그램등록해서 엑셀자료로 다운받게 해줬습니다. 화면에 몇백건만 띄워줘봐도 보지도 못할 자료들이니 몇만건이면 화면에 출력기다리다 오류 한번나면 처음부터 작업 다시해야하니 최악이죠
  • kkey21a
    4k
    2013-09-02 17:25:00
    피리아노님//
    우선 답변 감사드립니다.

    스크롤 페이징은 생각은 해봤는데, 현업들이 비추하네요.;;
  • roxet
    12
    2013-09-02 17:26:58
    4-5만건 쿼리 걸리는 시간보다 화면에 그리는 시간이 더 걸리는게 아닐까요
    피리아노님 말씀대로 50건이나 30건이나 페이징해서 보여주면 그리는 시간은 줄어들꺼 같구요

  • angeluser
    649
    2013-09-02 17:28:53
    오픈소스 그리드 이용하면
    처음엔 한 천건 뿌려주고 스크롤 내리는 대로 계속 조회되도록 하면 ...
    안되겠죠? - -;
  • kkey21a
    4k
    2013-09-02 17:29:23
    luck_to//
    답변 감사드립니다.

    엑셀만 따로 만들어 주긴 하면 되는데, 기존 화면들과 차이도 있고 추 후에 유지보수에 문제도 있고 해서 가능한 같은 모듈을 사용하고자 하는데 현재 엑셀 생성 모듈로는 구현이 힘든 상황입니다.
  • 피리아노
    595
    2013-09-02 17:30:59
    닉친구// 현업분들 비추 의견을 듣고 논리적으로 협의를 해보시는게 좋을듯 보여요~
    딱히 비추 이유가 없을듯 한데... 흠흠 아 저도 그건 있었네요. 스크롤 여러번 내기리 귀찮다 그래서 한번에 보여달라 그래서 제가 시뮬레이터 해드렸죠
    클라이언트 컴이 부하되서 거진다 다운될거다 하고 5만껀 뿌리고 웹브라우져 먹통되고
    직접보더니 페이징처리로 합의 ;;;

    건투를 빌어보아요~
  • kkey21a
    4k
    2013-09-02 17:31:56
    roxet//
    화면 뿌려 주는 시간이 많이 걸리기는 한데, 윗 본론 글에 언급하였듯 캐시에 없을때 시간이 많이 걸립니다.
  • kkey21a
    4k
    2013-09-02 17:35:10
    피리아노//
    현재 스크롤 페이징으로 구현된 화면이 있는데, 불편하다 하시네요. 그냥 한방에 보고싶어 하셔서 ...
  • kkey21a
    4k
    2013-09-02 17:38:48
    피리아노//
    아 그리고 현재 화면이 먹통 되는 혹은 Out of memoy 이유 등으로 한번에 던지지 않게 구현 했습니다.
  • 피리아노
    595
    2013-09-02 17:51:13
    아... 먹통안되게 비 스크롤링 페이징 하셨으면... 딱히 답이 안보이네요.ㅠㅠ
    협업이 그걸 본순간 되는구나 했을테니;;; 시간 지연으로 미는 수밖에;;;;;
    도움 못드려 죄송해요~
    ps : 문득 생각난건데 그럼 쿼리로 강제? 캐시 처리를 해보는 방법은 있겠네요
    with 문을 사용하여 지금 쿼리를 with안에 집어 넣어서 출력하면
    시간적으로 단축이 꽤 되실거라 사료되옵니다~ 수고하세용
  • kkey21a
    4k
    2013-09-02 18:03:40
    피리아노//
    답변 감사드립니다. ~^^
  • zepinos
    20k
    2013-09-02 18:08:54
    그냥 리포팅 툴 도입 후 거기서 알아서 해라...라고 하겠습니다.

    한 페이지에 그런 정보를 "보기만" 할꺼라면, 그게 리포팅이죠.

    그걸 보여주면서 수정도 해야된다면...아이고 두야...

    현업들이 제정신이 아닌거죠.
  • kkey21a
    4k
    2013-09-02 18:17:33
    zepions//
    답변 감사합니다.

    //
    화면 출력이 포커싱이 아닌데, 주제가 살짝 흘렀네요.
  • 머슴.
    723
    2013-09-02 20:32:02
    엑셀로 내려 받던지요.
  • kmjyarto
    1k
    2013-09-02 20:51:21
    처음부터 스크롤 페이징으로 구현되어 있으니 배부른 소리하는거죠. 한방에 딱 나오면 스크롤 할때 쭉쭉 내려갈꺼라 생각하는거죠.
    그냥 한화면에 보여주세요. 로딩시간 10분인데 보시겠습니까 물어보는 얼럿하나 띄우시구요.
  • kmjyarto
    1k
    2013-09-02 20:53:55
    한방에 사만 오만건 보는 화면 만드는거 본적도 들은적도 없습니다.
    차라리 토드 같은 툴깔아주시고 쿼리문 저장해주고 F5누르라고 하세요.
  • leemong77
    1k
    2013-09-02 20:57:55
    plsqL 쓰세요. 오라클 OBJECT 쓰면 답나옴
    그리고 자바쪽에서 벡터나 해쉬맵 이런거 담아 쓰면 답 안나옴
    그냥 jdbc 생코딩으로 짜야 속도 나옴
    그리고 5만건이면 화면 뿌려지는데 시간걸리는데 그건 사용자 컴사양에 따라 빠를수도 있슴
    서버는 머 별로 50000건이래봐야

    그리고 sql은 따로 튜닝하시공
  • kkey21a
    4k
    2013-09-02 21:04:55
    kmjyarto//
    그 부분이 마음에 걸린다는 겁니다 ~

    뭐 너무 배부른 욕심인지는 모르겠지만, 솔직히 4~5만건 출력 쿼리 시간을 줄이고 싶은게 제 맘이죠 ㅋ

    원판이 크서 그런지 DB 메모리 올리기전에 DISK IO가 심한지 쿼리시간이 좀 걸리네요. 4~5만건인데 5분이나 걸리닌깐요. 파티션 잡자니 마이그레이션이 귀찮다는...

    아무튼 답변 감사드립니다.
  • kkey21a
    4k
    2013-09-02 21:08:33
    냐옹//
    DB2고 자바나 화면단에서 처리 하는 로직은 별 문제 없습니다.
  • ekqlem73
    234
    2013-09-03 09:03:18
    1. 5만건 화면 출력이 무슨 의미가 있는지를 우선 파악해야 합니다.
    2. 5만건 화면 출력된걸 사용자가 사용할 수 있는 방법은 거의 없습니다.
    3. 상단의 검색조건을 통해 사용자가 필요로 하는 데이타를 보여줄 수 있도록 해줍니다.
    4. 5만건 이상의 데이타를 실제 받아보고자 할 시 엑셀출력 기능을 이용하도록 합니다.
  • solasin
    498
    2013-09-03 09:54:31
    1. 쿼리 결과를 파일로 저장.
    2. 처리결과 화면은 파일로 부터 조회
    3. 처리결과 화면은 별도의 페이징 보다는 ajax grid 사용해서 일정 버퍼씩만 읽어들이도록 처리

    천만건이라도 문제없음.

  • kkey21a
    4k
    2013-09-03 10:07:46
    solasin//
    파일로 저장해서 다시 그 파일 읽어서 조회하는 시간이 더 걸리지 않을까요? 그리고 화면 출력은 천만 건이라도 출력 될 수 있게 구현되어 있습니다.

    현재 문제는 쿼리가 버퍼 풀(오라클 기준으로 SGA영역)에 올라가기 전과 후에 대한 시간의 Gap을 줄 일 수 있는 방법이 초점입니다. (참고: 전: 7분, 후: 2분)


    PS: 화면 출력 방법이나 출력을 왜 하냐 얘기하시는 분들이 많으신데, 출력방법은 현재 이슈가 아니며 굳이 화면 출력 이유는 유지보수 관련이 있습니다. 엑셀 다운로드 기능을 여기 화면만을 위해 별도로 개발하는 것은 추 후에 생각해볼려고 합니다.

  • solasin
    498
    2013-09-03 11:04:14
    예전 C/S 프로그램들의 그리드들이 db와 직접 연결되서 수행될 때 async 방식으로 대단위 데이터 처리를 하는 기법과 같은거.
    15년 전에 이슈가 되던게 아직도 이슈라니...

    1. 파일 출력을 sync로 출력할 경우에는 백그라운드 스케쥴러나 db trigger로 사전에 출력.
    2. web grid는 파일로 부터 일정 분량씩만 읽어서 async로 grid에 출력.
    3. 조회/정렬은 그리드에서 수행하돼, 수만건의 데이터를 web grid에서 처리하지 못할 경우 db에서 수행하는 것과 파일에서 수행하는 것 비교 후 적합한 걸로 결정.

    * 쿼리가 버퍼 풀에 올라가야 한다는 것은 sync query 인 것이므로 table scan을 통해 조회한 것을 async로 바로바로 출력하게 하면 db버퍼 사용량은 최소로 가능.
    * gmail로 예를 들면.
    억단위의 메일 리스트를 한 화면에서 볼 수 있는 것도 아니고 눈에 보이는 것만 가져와서 출력하면 되는 것이니 아무리 메일이 많아도 화면출력 속도는 일정하게 유지 가능한 것과 같음.
  • solasin
    498
    2013-09-03 11:06:46
    굳이 파일로 처리하는 것은 페이징 기법이든 grid에서 스크롤을 내리든 미리 버퍼를 채우두는 것이든 필요할 때마다 일정 양의 데이터를 가져와야 하는데, 이를
    매번 db 조회를 해서 가져오는 것 vs 파일에서 일정양을 가져오는 것
    을 비교시 cost에서 비교가 되지 않기 때문.
  • solasin
    498
    2013-09-03 11:08:04
    excel download는 그냥 csv로 만들어둔 파일을 download만 하면 되는 것이니.
    비용 0에 수렴.

    더이상 답변 안합니다.
  • kkey21a
    4k
    2013-09-03 12:35:04
    solasin//
    결론부터 말하면 뭔가 오해하신 듯~

    DB2의 버퍼 풀을 얘기하는데, sync 쿼리가 왜 나오는지?
    오라클 기준으로 Data buffer cache를 말 함입니다.

    그렇다면 solasin님께서 말씀하신 sync 쿼리나 트리거 혹은 스냅샷등은 고려할 대상이 아니죠. 또 더 나아가 Materialized View등은 대상이 되지 않지 않을까요. 쉽게 얘기해 검색조건에 의해 매번 바뀌는데 그 데이터를 임의의 공간에 보관하여 그 대상을 조회한다? 기본적으로 DB가 하는 것을 굳이 왜 해야하죠? ㅋ

    Hit ratio로 인해 두번째 부터는 빠르다는 말인데, 처음부터 빠르게 할 방법이 이슈라는 거죠.
    뭐 상세 내용은 윗 글과 댓글들로 있으니 생략합니다.

    아무튼 답변 감사드립니다.
  • kkey21a
    4k
    2013-09-03 12:40:15
    쉽게 얘기해 쿼리를 처음 실행할 때 생각보다 느리다는 겁니다. 두번째, 세번째 캐시에서 사라지지 않을 때 까지는 빠르다는거고, 이 문제를 보다 쉽게 해결 할 방법을 찾는거죠.
  • kkey21a
    4k
    2013-09-03 12:57:59
    그리고 현재 속도가 관건인데, 파일 혹은 또 다른 어떤 공간에 옮겨 다시 그 대상들을 가져온다면 더 시간이 오바되겠죠. 그리고 원본 데이터에 대한 통계 데이터나 일정한 규칙에 의해 만들어지는 어떤 값등이라면 모를까 굳이 같은 데이터를 보관할 이유는 없죠. 지금도 원 데이터만 60G이상이나 잡아 먹고 있는데...

    아 그리고 당연히 일정한 양만큼 가져오게 구현했으니 화면이든 서버든 뻗지 않겠죠. 아무튼 그러니 이 얘기는 더이상 할 필요 없는 듯 하구요.
  • solasin
    498
    2013-09-03 13:39:03
    1초 안에 데이터 조회되는 기법 얘기해줬더니 딴 소리 한다 그러네. 이거참...

    sync 기반의 query는 쿼리가 완료될 때 까지 대기해야하는 것이 기본인거고.
    이 버퍼라는게 결국은 내부적인 temp table에 데이터가 다 채워져야 쿼리결과가 리턴될건데.
    4~5만건의 데이터가 버퍼양보다 커서 disk swap을 하기 때문에 성능이 급격히 저하되는거.
    메모리 내에서 버퍼가 다 채워지도록 버퍼 사이즈 키우든가.
    db temp volume의 i/o를 향상시키든가.
    이 두가지는 그러나 돈 들어가는거고.

    그냥 db2 엔지니어 불러다 놓고 족치면 될걸 프로그래머들에게 왜 물어보시는지.
    고급 프로그래밍 기법 알려줬더니. 쯧.
  • solasin
    498
    2013-09-03 14:01:41
    파일 처리 기법은 db의 temp volume을 직접 구현하는 것과 같은 거.
    외국애덜 솔루션에서는 널리 사용되는 기법임.
    믿거나 말거나.
  • kkey21a
    4k
    2013-09-03 14:31:11
    solasin//
    제가 글을 잘 못 읽었네요 ;;

    “쿼리가 버퍼 풀에 올라가야 한다는 것”
    위 당연한 말을 하셔서 뒷 글을 제대로 안 봤네요.

    뭐 맞습니다. 버퍼 사이즈가 결국 작아서 DISK IO가 빈번하다보니 실제 비용보다 시간이 많이 걸리지 않나 생각합니다. 그렇다고 무작정 운영이라 버퍼 사이즈를 키울 수 있는 것도 아니고 DISK를 좋은 걸로 바꿀수 있는 것은 돈이 드니 더더욱 아니고 결국 DBA 족친다고 답 나오는 것도 아니다보니 이런 경우 현업과 어떻게 푸시는지가 긍금했든건데 논란이 조금 되었네요.

    뭐 암튼 좋은 의견 감사드립니다. 그나저나 solasin님은 15년전 이슈를 얘기하시는 것보니 연차가 상당하신듯 하네요.
  • kkey21a
    4k
    2013-09-03 14:37:39
    파일처리 기법도 이해가 안되는 것은 아니나 결국 조회해야 할 데이터를 파일로 떨궈야 한다는 것이고 그에 따른 쿼리는 실행은 당연한 상황이라, 솔직히 테이블 데이터처럼 어느정도의 일정 룰이 있다면 실시간으로 만들어 주면서 그 부분을 검색하면 되겠지만...

    뭐 암튼 제 경력이 짧다보니 이해가 안되네요.
  • 랏츠
    1k
    2013-09-03 18:12:18
    현업 모니터는 100인치짜린가보군요. 일단 모니터부터 100인치짜리로 바꾸면 생각좀 해보겠다고 하세욤. 이런건 스킬로 푸는게 아니라고 봅니다.
  • kkey21a
    4k
    2013-09-03 18:24:42
    랏츠//
    뭐 랏츠님께서 틀린 말 하는 거라 생각하지는 않습니다.

    그냥 개발자로서의 오기 혹은 존심 정도라 생각해주셔요.
  • nobody_knows
    860
    2013-09-04 01:37:49
    MOVED FROM bbs6
  • 구로1동
    327
    2013-09-04 09:11:01
    //랏츠
    저도 랏츠님의 의견에 동의 합니다. 이건 개발로 해결할 문제가 아니네요. 프로젝트나 운영 등의 업무를 하다보면 개발보다 협의로 해결해야 하는 문제가 많지요. 사람이 수 많은 정보를 일일이 확인해야 한다면 그건 시스템이 아니지요.
  • kkey21a
    4k
    2013-09-04 10:21:19
    굳이 옮긴다면 DB QNA 게시판으로 가는게 맞는듯 합니다.
  • iamsky
    3
    2014-05-13 10:16:22
    5만건 이상 데이타 화면에 보여주는 방업있습니다. 순수 웹이구요
    제가 테스트시 오만건 쿼리 데이타 가져오는 속도 제하고 화면에 보여주는데 1초도 안걸립니다.
    물론 데이타 검색도 다되구요.
    필요하심 제공해드릴수도 있습니다.
    전 이상준이라고 하고 iamfreenoble@hanmail.net 으로 연락주심 됩니다
  • escaman
    82
    2015-09-04 17:55:10

    www,realgrid.com 

    HTML5 기술로 개발된 국산 유료 그리드 컴포넌트 입니다.

    대량 데이터 처리에도 좋은 성능을 보장합니다.

    데모에 다양한 기능이 소개되어 있으니 참고해 보세요.

  • 매드캣
    2
    2017-10-13 11:41:58 작성 2017-10-13 11:42:30 수정됨

    지나가다가 4년전 질문에 댓글다는것도 이상하다는 생각은 합니다만...

    기본적으로 한 화면에 뿌리는게 버벅거리는건 DB쿼리 문제라기 보다는 HTML 처리 버퍼링으로 인해

    버벅 거리는 거라서...

    한번에 딱! 하고 보여줄 필요가 없이 현재 뿌려줄 수 있는 데이터부터 순차적으로 출력버퍼를

    비워나가면서 뿌려주면 1초도 걸리지 않습니다.

    약 10년전에 일본에서 일할때 NEC에서 회계관련 데이터를 화면에 출력하는데 미친놈들이 10만건

    데이터를 한번에 뿌리고 데이터 갱신할때마다 약 30분에서 50분정도는 기다리고 있더라구요.- _-;

    어차피 버퍼를 비워주면 당장 출력되는 부분은 바로 보여주고 밑으로 계속해서 버퍼가 비워질때마다

    사용자가 보는 동시에 출력이 이루어집니다. 사용자 입찰에서는 한번에 뿌려지는것 처럼 느껴지지요.

    뭐 4년 전 질문이니 이미 잘 처리하셨으리라 생각됩니다만.

  • 로그인을 하시면 답변을 등록할 수 있습니다.