Talk Lowy(kr)

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

DBMS의 튜닝의 70% 이상은 SQL튜닝과 Index튜닝으로 해결 됩니다. 하지만 예외적인게 조금 있지요. 얼마 전에 옆에서 이상하게 속도가 느려진 쿼리가 있어서 봐달라고 쿼리를 보여주었습니다. 힌트를 주어 강제로 인덱스를 태우고 있었습니다. 이 힌트는 왜 주었냐고 물어보니 원래 그렇게 되어 있어서 사용중이었다고 합니다. 아마 초기에 만든 사람이 사라지고 그냥 그 동안 문제 없이 쓰고 있었던 것 같네요. 그냥 잘 모르면 힌트를 없애고 돌려보세요. 라고 가이드를 했더니 3초 이상 걸렸던 쿼리가 0.01초로 끝났습니다. 이유는 뭘까요? 대부분의 인덱스는 초기 개발자가 개발하면서 만든 인덱스 외에는 나중에 추가 되는 경우가 많지 않습니다. 대부분 한 번 만들면 그게 최적이라고 생각하는 경우가 대 부분이고, 지금 처럼 초기에 만든 사람들이 사라지고 물려받은 사람들은 이유를 모르고 사용하는 경우도 있습니다. 테이블 설계시의 예상 데이터 축적량을 보고 아무리 DB 전문가가 Index를 걸어준들 사용자의 성향이나 시대에 따라 데이터는 전혀 달리 쌓이게 되는게 보통입니다. 예를 들어, 한국형 게시판은 대 부분 글이 많고 댓글이 적은 편입니다. 이유는 튀기 좋아하는 한국인들은 자기가 돋보여야 하기 때문에 댓글에 달 글 조차도 글쓰기로 올라와서 많은 사람들이 보게 하길 원하는 경우가 많기 때문이지요. 하지만 이 게시판으로 일본에서 서비스를 해보면 글은 얼마 안올라오는데 댓글이 수천에서 수만개가 쌓입니다. 즉 유저의 성향에 따른 데이터의 편중이 달라지는데, 이 때 게시글 옆에 댓글을 카운트 하는 경우 subquery를 이용해서 카운트 하는 경우도 많고, group by 를 이용해서 한 번 카운트 한 댓글 통계를 join하는 경우도 있습니다. 전자의 경우는 댓글 수가 적은 한국에서는 좋은 쿼리이나, 댓글이 너무 많아진 일본에서는 group by에 비해 많은 양의 카운트를 nested loop로 처리하게 되므로 효율이 많이 떨어집니다. ...

대부분의 사람들의 실수중에 row가 몇백개 없어서 PK자체를 안잡는 사람이 있다. 이런 경우 어떠한 현상이 일어날까? 잘 보이는지는 모르겠지만, 단순 select에 where에 자기 테이블내 특정 필드에 Y값을, 그리고 Z필드로 정렬하고 있다. 하지만 프로파일러에서 보면 20초가 넘었다. 가끔 한 번하는데는 전혀 문제가 없다 500ms미만으로 처리된다. 하지만 왜 이따금 발생하는 것일까? 정확한 DBMS의 엔진 알고리즘을 알고 있지는 않다. 하지만 경험적으로 말할 수 있다. 동일 쿼리를 여러번 시도하는 경우 PK가 없으면 정렬이 되지 않기 때문에 우선 Table Scan을 처음부터 해서 계속 메모리에 올리게 된다. 즉 Disk I/O와 Memory I/O가 지속적으로 일어나는 것이다. 때문에 동시 100번 정도 처리되도 전부 Disk I/O를 사용하게 된다. 단지 800행도 되지 않는데 20초를 먹을 수 있는 것이다. 하지만 PK를 Clustered index로 걸게 되면 처음 Insert할때마다 PK에 의존해서 Sorting을 계속하게 된다. 나중에 Select할때는 언제나 같은 것을 가져오기 때문에 Cache에서 처리할 수 있는 것이다. 그럼 누군가가 다시 질문한다. "50행도 안되는건 괜찮나요?" 그냥 맘대로 해라.. 선을 그어서 어디까지는 되고, 어디부터는 안된다는 흑백논리는 60년대나 하는 것이지, 모든 것을 정해놓고 이렇게 하세요 하는 것은 아직도 현실을 모르는 사람들이나 하는 것이다. 1Row가 1MB가 되도록 짜는 사람들도 있는 것이고, 1000Row가 100KB가 되도록 짜는 사람들도 있을 것이다. DB의 구조설계부터 스스로 판단하고 튜닝도 결정해라. 누누히 얘기하지만, 튜닝이란 것은 만들때 하고 땡이 아니다. 우리가 1년에 한번씩 건강검진을 받듯이, DBMS도 자신에게 축적된 노폐물이 어딨는지 찾고 부정맥이 어딨는지 찾기 위해 건강검진을 받아야 한다. 이...