Talk Lowy(kr)

영상버전 : https://youtu.be/S7CDcs0bLJM 고객사에서 환영회를 하자고 해서 관련 사람들 7명이 모인 작은 노미까이에 초대 받아서 롯뽕기에 왔습니다.  롯뽕기는 수도고속도로 아래의 자투리 공간에 바이크 주차장을 운영중이네요..  국가에서 관리하는 곳이라 저렴하니 바이크로 롯뽕기에 오시는 분들은 참고 바랍니다.  30분에 100엔이고 12시간 이내라면 최대 1000엔으로 고정이므로 주차비 걱정을 안해도 될 듯 합니다.  노미까이에서 저를 극찬을 아끼지 않아주셔서 몸둘바를 몰랐는데..  오히려 제가 이 환경에선 담당자분들이 정말 좋은 환경의 튜닝을 경험할 수 있어서 행운이라고 말씀을 드렸지요.  SQL Server라는 RDBMS의 대표격인 제품의 특장점에서, 무료 MySQL엔진의 Aurora에 IOPS가 떨어지는 클라우드 환경에서의 튜닝기법, 그리고 Key Value 베이스인 TiDB환경에서의 튜닝방법까지 제게서 배워간다면,  어떠한 교육기관에서도 배울 수 없는 경험을 할 수 있으니 제가 가진 경험을 받아가실 수 있는 최고의 환경이라고 했지요..  참고로 여기 DB운영 사람이 부족해서 추가로 더 모집한다고 합니다. N1자격이나 동등의 일본어 능력을 가지신 분들 중에 이 프로젝트에서 저와 같이 하고 싶으신 분들은 연락 주세요~ ^^ 회사의 밸류가 구치코미, 즉 유저 평가의 분석을 무기로 한 기업이다 보니 AI에 대한 활용 방법론 등도 관심을 많이 가지고 있어 미래가 기대되는 곳이었습니다… 이런 건전한 이야기를 하면서 두 시간 코스로 식사를 하고 헤어졌는데요.. 2차를 가자고 했는데, 2차는 회사 내부 사람들과 가라고 하고 전 빠졌지요..  그런데 여기 사람들과는 좀 더 오랫동안 좋은 관계를 가지고 싶네요..  담당자 분들도 순수하고 밝고 내부에서도 서로 배려하는 모습이 아주 좋았습니다.  일단, 정치질 하려는 사람이 저랑 엮인 분들 사이에선 ...

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

듣기 버전 :  https://youtu.be/_JtfZzISH5g 역시 한국의 유투브 방송에는 NoSQL이랑 RDBMS랑 비교하면서 초심자 분들에게 NoSQL이 좋아 하는 식으로 방송하는게 많이 보이는데요, 이건 잘못하면 RDBMS는 안써도 되 라는 느낌으로 들립니다. 실제로 그런 사례도 몇 번 일어난 것을 보면 제대로 알려드려야 할 것 같아서 이 주제를 가지고 나왔습니다. 넌 뭐가 잘났는데 하시는 분들을 위해 제 자랑을 또 해드려야지요. 전 하둡으로 4000만 dau가 있는 서비스의 1.76PB 짜리를 설계 구축 해봤습니다. 카우치베이스로 32TB 데이터 올리다가 터뜨려 먹은 적도 있습니다. 몽고디비 운영중에 이건뭐지 하고 리밸런싱 커맨드 날렸다가 락걸려서 8시간 서비스 정지도 시켜봤습니다. 저를 nosql의 n자도 모른다고 하시려는 분들! 사실 전 nosql을 제대로 못써봤습니다! Nosql의 진가는 최소 일간 10억 유니크 엑세스 부터가 아닐까요? Nosql을 처음 봤을 때 그 구조에 대해 경악 했지요. NoSQL이 대단한 것은 데이터 저장 구조가 아닙니다. MySQL도 SQL Server도, ORACLE도 JSON Query를 지원하기 때문에 하나의 필드에 다 때려 넣고 표준 SQL에 JSON Query구문만 추가하면 필드처럼 인식 가능합니다. 비정형 데이터를 RDBMS가 못넣는다는 것은 이미 10년 전 이야기지요.. 많은 영상에서 하드웨어 구조 같은것은 설명을 하나도 못봤는데요.. NoSQL은 만약 100개의 노드에 데이터가 뿌려져 있다고 합시다. 그러면 Namenode에 검색용 쿼리를 날립니다. 그러면 Namenode는 100개의 노드에 동일 쿼리를 던집니다. 그리고 그 중에 해당 쿼리에 데이터가 있으면 그 데이터만 Name node에 가져옵니다. 그걸 머지해서 리턴을 해주지요. 어떤 내용이냐면, 만약 100GB의 하드를 가진 서버 100대에 NoSQL을 설치하고 데이터를 마구 넣었습니다. 동일하게 10TB의 하드디스크 한대에 RDBMS를 ...

재밌는 DB 스페셜리스트가 되어보지 않겠어요?  이번에는 제 자랑 이야기가 메인이니 재미 없으신 분들은 피해주셔도 됩니다. ^^;; 제 삼자의 입장에서 한국을 보면,  누가 뭔가로 돈을 벌었다 하는 소문이 나면 전 국민이 그거 밖에 없는 듯이 움직이는 모습을 보면  가끔은 웃음이 나와요.. 레밍스 보는 느낌이랄까..  전국민의 개발자화 하려는 나라는 한국 밖에 없지 않을까요?  지금이야 수요가 있으니까 대우를 받는다 해도,  충분한 공급이 나오면 개발자들은 헐값에 넘어가잖아요..  예전에 일본에 IT인력을 넘길 때도 마찬가지 였거든요..  한국에서 자바 개발자가 최고라느니 하는 이상한 소문이 나서  모두 자바 개발을 시키니까 포화상태가 되버려,  국가가 나서서 그걸 풀려고 일본으로 대거 보냈지요.  그러다가 일본에서 경험 부족한 한국인이 대거 오면서 품질이 안좋아져 한국인 금지를 내린 기업들이 늘었고..  그 때문에 다시 한국으로 돌아간 자바 개발자들이 떨이가 된 적이 있었죠..  뭐랄까.. 다양성이 없다고나 할까..  일본에선 아직도 코볼로 먹고 사시는 분도 계시구요.. 일본 디지털 방송 시스템 내에서도 광고 송출 스크립트는 시퀄셜 처리이기 때문에 아직도 코볼을 쓰는데 효율적이거든요..  전 지금도 classic asp로 제가 필요한거 그때그때 만들어서 제공하는데 아무 문제 없거든요..  Skynet을 classic asp로 짜고 있습니다! 요건 나중나중에...  한국에선 자바가 붐 이었을 때 전 세계가 자바밖에 없는 줄 아시는 분도 계셨는데..  이 때 제가 W3Tech라고 하는 전 세계 1000만 상용 웹 사이트의 서버 사이드 개발 언어 통계를 보여드린 적이 있지요. 그 때는 php가 90%가 넘었는데 지금은 그래도 많이 줄었네요..  전제를 어디에 두느냐에 따라 Python이 1등일 수도...

누군가 요청해서 재미삼아 만들었음.. mongodb를 mysql에서 불러들이는 방법은 몇 가지가 있는데요..  1. mongodb에 mysql 모듈을 설치해서 mysql에서 호출하는 방법..   -> 설정이 많이 필요해서 귀찮음 2. mongodb에 mysql 5.7이후라면 json import를 이용해서 json으로 집어넣는 방식   -> mongodump를 이용해서 json 파일로 넣고 json_import를 이용해서 테이블에 넣으면 되기 때문에 간단한 명령으로 쉽게 정리 됨.    단점은 KVS(Key Value Store)로 저장되기 때문에 쿼리가 살짝 귀찮아짐.. 기존 쿼리를 사용할 수 없다.  SELECT doc->>"$.name" AS name FROM test.my_restaurants WHERE doc->>"$.cuisine" = "Italian"    요런 느낌으로 쿼리를 짜야 함. 3. mongodump로 json으로 떨군 뒤에 jq로 읽어서 쉘로 필드를 뽑은 뒤에 mysql커맨드로 insert처리를 함.       #!/bin/bash      # Useful date text     TodayYYYYMMDDHH24MISS= `date '+%Y%m%d%H%M%S'`     TodayYYYYMMDD= `date '+%Y%m%d'`     TomorrowYYYYMMDD= `date +%Y%m%d --date '1 day'`     YesterdayYYYYMMDD= `date +%Y%m%d --date '1 d...

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