기본 콘텐츠로 건너뛰기

라벨이 database인 게시물 표시

chatgpt로 DB튜닝 전문가 되기!

영상버전 :  https://youtu.be/3bhK0B96zIQ 이젠 chatgpt를 사용하면 저와 같은 레벨의 db튜닝을 하실 수 있습니다.  단! 아래와 같은 접근을 잘 연습하신다면 말이죠.. 1. 인덱스 점검 먼저 ChatGPT에게 “이 테이블에 어떤 인덱스가 이미 있고, 어떤 게 부족해 보이는지”를 물어봤습니다. 그러자 놀랍게도, 각 테이블에 필요한 인덱스 목록과 개선 방향을 꽤 체계적으로 제시해주더군요. 2. 복합 인덱스 인덱스를 최소화하면서도 효율을 높이려면 복합 인덱스가 답일 때가 많습니다. 그래서 ChatGPT에게 “그럼 복합 인덱스를 구성한다면 어떤 필드 조합이 좋을까?”라고 물어봤죠. 예: return_date + shop_id, order_id + return_flag 등등 필드 순서를 어떻게 두느냐에 따라 성능이 확 달라진다는 이야기 Include 옵션을 활용하면 인덱스만으로 데이터를 조회할 수 있어 훨씬 빠르다는 조언 이런 내용이 나오는데, 솔직히 저도 모르는 건 아니었지만 다른 시각에서 정리된 결과를 보니 훨씬 명쾌했습니다. 3. ‘카디너리티’ 인덱스 튜닝하면 꼭 등장하는 단어가 **카디너리티(Cardinality)**입니다. 쉽게 말해, 특정 필드가 갖는 값의 다양성 정도죠. 예를 들어, shop_id가 수천 개라면 카디너리티가 높고, dtenpocd처럼 점포코드가 57개밖에 안 된다면 카디너리티가 낮습니다. ChatGPT가 강조하더군요. “카디너리티가 높은 필드는 인덱스의 앞쪽에 두어야 효율을 극대화할 수 있어요.” 반면 카디너리티가 낮은 필드는 필요하면 Include에 넣거나 뒤로 빼서 쿼리 범위를 좁히는 식으로 사용하라고 했습니다. 4. 인덱스 필드 순서 실제로 저도 “기간 검색을 먼저 하고, 그 다음에 shop_id로 필터링하는 게 낫지 않을까?”라는 의문이 있었어요. 그런데 ChatGPT는 “shop_id로 먼저 필터링하고 기간 검색을 거는 게 더 나을 수도 있다”라고 하더군요. 그 이유는 shop의 개수가...

DB엔지니어라면 코드를 몰라도 API서버가 만들어지는 것 같습니다.

영상버전 :  https://youtu.be/JGgTOA5Tcsc 2007년에 SQL Server에 있는 SP를 기반으로 만든 서비스가 있습니다.  다른 RDBMS에서는 그냥 프로시저라고 부르는데 유독 SQL Server에서만 Stored Procedure라고 하네요..  이유가 뭔지는 모르겠지만.. 아뭏든..  거의 모든 처리는 SP에서 처리하고  웹페이지는 그냥 SP를 실행한 결과만 호출하는 방식이죠. 결과 또한 표시 화면에 맞추어 쿼리를 만들었기 때문에 계산이나 변수에 받아서 조정할 일이 없습니다.  여기에는 많은 개념이 있었는데요..  2007년이면 AWS가 막 이름을 내기 시작했고, VMWare가 일본을 장악 했던 떄이죠.  VMWare의 3.5를 쓰다가 VMWare 4.0부터 많은 부분이 안정화 되었고,  이 VMWare를 이용한 인프라 관리가 관건이었습니다.  Xen도 이 때 많이 커지는 듯 하였으나, 어느 정도 중대규모 및 상업용은 VMWare가,  초 대규모 또는 무상은 Xen이 점령하고 그 밖에 virtualserver, hyper-v, kvm등등 많은 가상화 솔루션들이 있었죠.. 그리고 2011년 정도 되어서 openstack과 cloudstack을 기반으로 오픈소스 진영이 엄청나게 전쟁중이었구요.. VMWare같은 가상화 솔루션은 하나의 머신에 VM을 쓰다가  vMotion이란 것을 이용해서 가동 중에 여기저기 머신을 오다닐 수 있는 기능을 가지고 있구요,  그러다 보면 local IP를 바꾸기 일상이죠.  300대의 물리머신에 대당 10개의 가상머신이 있다면 일일이 동일한 IP로 옮겨다니기 어렵거든요..   가상 IP를 마구잡이로 넣고 나중에 글로벌IP를 Routing으로 매핑하거나 NAT를 많이 쓰기도 했구요..  이 즈음에 Azure 클라우드 서비스가 처음 선보였는데,  이 때...

DB튜닝 전문가 망했습니다..ㅠㅡㅠ

영상버전 :  https://youtu.be/iTmkJ2iWJuU 지금 프로젝트에서 개발자들이 프로시저를 만들다보니  개발자의 의식의 흐름대로 데이터 처리를 만들다보니 커서를 이용해서 테이블 변수에 넣고  그걸.  변수로 다른 테이블에서 조회하는 식으로 짜놨네요..  튜닝할 때 항상 하는 이야기 이죠.. Trigger와 커서는 절대 쓰지 말라구요..  이것처럼 속도를 저하시키고 락을 유발 시키는 장치는 없거든요..   트리거는 트리거링 포인트가 되었을 때 대상 테이블을 락을 건 뒤에 트리거 처리를 하고 나서 락을 해제 하기 때문에 아무리 빨리 끝나도 동시에 들어오는 쿼리에 따라서는 데드락에 빠질 가능성도 있습니다.   마찬가지로 커서 역시 테이블을 열고 커서를 만들어 처리하기 때문에 그 모든 처리가 끝날 때까지 락이 걸린 상태가 됩니다. 데이터가 변동하면 안되니까요..  그래서 트리거와 커서를 사용하면 기본 서너배는 느려집니다.  커서랑 트리거만 없어도 50만명 받을 서비스가 15만명도 못받게 되는거죠.. 경우에 따라서는 수백배 느리게 짤 수도 있는게 커서와 트리거 입니다. 그냥 서비스를 떨구든 말든 자기 편한대로 만들겠다는 생각이 있지 않는한 커서는 피하셔야 합니다.   개발자들이 커서를 많이 이용하는 이유는 커서를 이용해서 만들면 복잡한 처리를 할 때 별로 생각하지 않고 개발 코드처럼 만들어도 가능하기 때문이죠  이번 쿼리도 커서를 사용해서 아주 길게 만들어놨네요..   한 줄 읽어서 상태에 따라서 데이터를 매핑해서 테이블 변수에 넣고를 쭈욱 한 뒤에  그 테이블 변수를 다시 읽어서 다른 테이블의 값을 가져오는데..   튜닝을 잘하려면 이 모든 데이터가 머리속에 연결구조를 그려서   하나의 비정규화 된 배열을 만들 수 있어야 합니다.   매번 이야...

월99만엔 TiDB프로젝트 2주째. 기존 디비의 튜닝

영상버전 :  https://youtu.be/VO7eNgFAGDA 2주 째에 들어왔습니다.  업무시간 8시간 중에 거의 5~6시간은 화상회의를 켜놓고 하게 되네요.  너무 지치는군요..  지난 번 프로젝트가 너무 널럴해서 그랬나봐요..^^;;;  한국과 조금 다른 것은  모두들 발언을 신중히 하기 때문에 말은 많지 않으나,  그 사람들의 말이 정말 이런 이유인지 아니면 다른 원인으로 인한 것인지를 찾는데 신경을 쓰다보니  더 빨리 피곤해지는데요..  지금은 TiDB 잘한다는 사람이 앞단의 교통정리를 헤주고 있으니 잘 하겠죠.  정말 잘할지는 모르겠으나 월권은 귀찮으니.. 하다가 폭탄 만들면 프로젝트를 뜨는 걸로..  SES는 SI와는 달리 프로젝트가 맘에 안들면 언제든 뜰 수 있는게 부담 없어 좋습니다.  리더를 해도 내가 합당한 이유를 우리쪽 영업에게 이야기 하면 빼주거든요..  요즘처럼 사람이 부족한 시기는 고를게 많아서  아무리 비수기라 해도 사람이 부족해 뒤늦게 가격 올려서 구인 하는 경우도 있어요.    첫주엔 27분기 총회가 있어서 참여를…  잊어먹고, 나중에 녹화방송을 봤습니다.  사원은 지금 마구 뽑아서 200명이 되었는데.. 3년 전에 수십억엔 매출이 2년전에 850억, 작년에 1850억엔이었네요..  레드오션이라는 화장품 시장에서 스타트업이 이 정도 수직상승이 가능…하네요..  여기 정사원들은 나중에 스톡 받겠네요…좋겠다…^^;;;  그건 그렇고..  이번주에 기억나는게 두 가지 있었는데요..  하나는 sql server의 리플리케이션이 끊어져 다시 걸어달라는 내용이었습니다.  얘네들은 부하가 너무 커져서 8대의 리플리케이션용 디스트리뷰터 조차 따로 두어서 마스터의 부하를 최소한으로 운영한건 좋었는데.. 마스터의 HA구성으로 대기용 ...

월99만엔 파견 현장(SES) 신규 프로젝트 참여한 이야기. TiDB Migration

영상버전 :  https://youtu.be/OaDuZvE1ViQ 7월 1일부터 참여한 젊은 화장품 판매 기업의 DB이전 프로젝트 입니다.  연매출 2000억엔에  오프라인 제휴 매장 포함 26개 라던가요? 사원은 200명..  온라인 구치코미를 분석해서 잘팔리는 제품의 순환이  이 기업의 핵심가치 같네요.  때문에 가장 중요한 것은 구치코미 데이터인 듯 합니다.  여기서  구치 는 입이고  코미는 코뮤니티의 앞글자 입니다.  그래서  사람들의 말을 모아놓은 커뮤니티를 말하는 것이지요.  우리말로 하면 평점 같은 느낌이려나요? 일본의 구치코미는 한국만큼 오염되진 않아서 돈으로 매수한 것도 좀 있긴 하지만,  지나치지 않게 하는 것 같습니다.  때문에 구치코미에 대한 신뢰는 아주 크구요.  이 프로젝트의 가장 큰 문제는  회의가 너무 많다!  그냥 하루에 세 번 미팅은 기본이고,  전 서너번이 보통인데,  정사원들은 작업 시간이 하루에 한 두시간이고  나머진 전부 미팅인 거 같네요..  그리고 티켓 시스템이 다섯 종류..  각 부서마다 자기네 티켓 시스템을 따로 쓰기 때문에  레드마인에서 처음보는 시스템까지 골고루 사용 중입니다.  가장 크리티컬한 것은..  SQL 서버를 사용하고 TiDB 이관을 하기로 했는데,  모든 멤버가 SQL 서버와 TiDB를 잘 모르는 것입니다.  유저의 급증으로 인해 SQL서버가 자주 뻗는대요..  그래서 TiDB로 변경하면 대규모 OLSP랑 OLAP 처리가 가능하다는 영업(?)에 넘어가서  TiDB TF팀을 결성해서 순차적으로 이동 중이라고 합니다.  현재 가장 부하가 적은 MySQL의 테이블 두 개를 이동하고,  조금 용량이 큰 데이터를 이동 중에 성능 이슈가...

당신의 RDBMS 튜닝 레벨은 어느 정도 인가요?

영상버전 :  https://youtu.be/yrYdv_4vy6Y 데이터베이스 튜닝에 자신 있으신 분들은 한 번 보시고 자신의 위치라던가,  제가 잘못 알고 있다고 생각하는 분들은 자유롭게 태클 부탁 드립니다.  오히려 제가 모르는 튜닝 기법을 가르쳐주시는 분들은 대환영입니다.  세상에는 저도 손을 절레절레하는 레벨의 튜닝도 있더라구요..  세상은 넓고 고수는 많은 것 같습니다.  데이터베이스 튜닝은 쿼리 튜닝 및 Index tuning만으로 약 70%가 해결됩니다.  그리고 나머지 25%가 전문가라 불리는 사람들이 자신만의 노우하우로 튜닝하는 영역이구요,  마지막 5%가 하드웨어나 OS의 기저 레벨에서 튜닝하는 영역이라고 보시면 됩니다.   그러므로 대부분의 튜닝은 70%에서 거의 해결하기 때문에  실력의 차이가 많이 나지 않습니다.  우선 70%에 해당하는 기초적인 튜닝을 조금 언급하고,  그 나머지 30%의 튜닝에 대해서는 재미난 일화를 중심으로 다루어보겠으니  많은 정보를 받아가시기 바랍니다.  튜닝의 기초 부터 시작해 봅니다. 1. 쿼리튜닝 및 Index 튜닝 쿼리튜닝이나 Index tuning은 많은 영상에서 다루는 듯 하지만 그 다루는 분들과 다른  영역을 위주로 알려드리겠습니다.  대부분 쿼리 튜닝이나 인덱스 튜닝을 위해서는 어디부터 보시나요?  저의 경우는 프로파일 또는 쿼리 캐시 영역을 들춰봅니다.  보통 리얼타임 프로파일링에서는 1년에 한 번 또는 비주기로 던지는 복잡한 쿼리는 보이지 않는 경우가 많습니다.  RDBMS는 쿼리 통계를 기반으로 인덱스를 자동으로 타기 때문에 이를 위해서 RDBMS가 쿼리 캐시 영역이란 것을 가지고 있는데, 그 곳을 털면 이 RDBMS에서 사용하는 대부분의 쿼리를 알 수 있습니다.  심지어는 해커가 Query Injectio...

DB 전문가가 이야기 하는 DBMS선택 방법..

듣기 버전 :  https://youtu.be/gee37PXME2E?si=F3hsUPq9ptJ-Uidz DB 전문가가 이야기 하는 DBMS선택 방법..  많은 개발자 분들이 DBMS선택 방법에 대해서 동영상을 올려드리는데,  DBMS엔진에 대해 정확하게 알지 못하는 상태에서 개략적인 정보만으로 올리시는 분들이 많은 것 같아서 오히려 DBMS를 선택하는데까지의 충분한 도움이 안되는 것 같아서 DB전문가가 DB를 선택하는 방법을 알려드리겠습니다.  만약 DB전문가라는 사람이 당연히 오라클이죠.. 라던가 MySQL만큼 좋은게 없어요 라던가 하나만 밀고 있는 사람이라면 그 사람은 DB전문가가 아니라 그 제품 하나만 알고 있는 평범한 사람이라고 보시면 됩니다.  다양한 RDBMS의 특징을 모르면 뭐가 왜 좋은지 알 수 없잖아요.. 그리고 상황 및 데이터 타입 등등 다양한 환경에 따라 달라지는데 하나만 최고가 될 수가 있나요?  제가 있던 시절의 RDBMS는 DBase(HBase아님), Cybase, Infomix등등 다양한 RDBMS가 판치던 시절이었습니다.  이 때에는 Index 알고리즘도 B-Tree index뿐만 아니라 Bitmap index도 있었지요.  Bitmap index는 Cardinality가 낮은 데이터, 즉 1 이나 0 처럼 종류가 적을 수록 속도가 빠른 인덱스도 있었으나,  대부분의 데이터가 Cardinality가 높은 경우가 많아져 SQL Server도 6.5부터는 B-Tree index를 사용하게 되었지요.  그래서 MySQL, SQL Server, ORACLE등의 메이저 RDBMS의 엔진 성능도 엇비슷해 진 듯이 보입니다..  많은 곳에서 MySQL이 최고라면서 증거를 들이밀고, SQL서버가 최고라면서 데이터를 들이미는 곳이 있는가 하면 ORACLE이 최고라면서 발표하기도 합니다.  다들 거짓말을 하는 걸까요?  아닙니다! 그들이...

오라클에서 테이블 생성 쿼리 작성 - ORACLE Management by SQL

Oracle의 관리 툴은 대부분 비용이 비싸서 가급적 무료툴로 관리를 한다. 그러다보면 기능들이 부족해서 SQL로 해결해야 하는 것들이 생기는데, 그 중에서 많이는 사용하지 않으나 있으면 관리하기 편한 하나가 바로 테이블이나 Procedure의 생성쿼리 이다. Oracle에서는 기본으로 제공해주는 쿼리이므로 주기적으로 select * from all_tables where owner = '<owner>' 로 테이블 명을 가져와서 아래 쿼리로 테이블 생성 쿼리를 업데이트 해주면 변경이력 관리가 필요없게 된다. select dbms_metadata . get_ddl ( ' TABLE ' , ' TableName ' , ' Owner ' ) from dual; select dbms_metadata . get_ddl ( ' Procedure ' , ' ProcedureName ' , ' Owner ' ) from dual; 추가로 Procedure작성쿼리도 추가함.. select * from all_objects 로 검색해서 Procedure나 Function도 가져오면 편할 듯.. Do not login your server any more! giip :: Free server management tool! https://giipasp.azurewebsites.net/

오라클 복구의 마지막... ORACLE RMAN

처음에 시작된 것은 NFS로 연결된 REDO LOG파일이 사라진 것인데.. 왜 REDO LOG를 NFS마운트에 올렸는지도 궁금하지만.. (아마 용량이 부족해서 이렇게 일시적으로 한 듯..) NFS는 끊어졌는데 그 원천 서버의 디스크가 날라가서 OS재설치하면서 REDO LOG파일이 사라졌다. 더 큰 문제는 REDO LOG 파일이 CURRENT로 지정된 데다가 파일이 하나밖에 설정되어 있지 않다. 이로서 불가능한 옵션은 ALTER DATABASE ADD LOGFILE MEMBER '/mnt/sdb1/redolog/redo05.log' TO GROUP 5; 기존 파일이 없댄다.. ALTER   DATABASE   DROP  LOGFILE GROUP  5 ; 파일이 없어서 삭제 안된단다.. ALTER   DATABASE  ADD LOGFILE GROUP  6 ; 신규로 그룹을 추가 했다.. 성공.. 이제 바꾸고 싶다.. alter  system  archive  log  current; 안된단다.. select  *  from  v$logfile; 이걸로 없어진 파일은 보이는데.. 이걸 빼고 다른걸로 바꿀 방법이 없다. ALTER DATABASE    RENAME FILE '/NFS/app/oracle/oradata/smartdb/redo05.log'            TO '/mnt/sdb1/redolog/redo05.log'; 이렇게 이름을 바꾸어 봤다. 이름은 바뀐다....