Talk Lowy(kr)

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

영상 버전 : https://youtu.be/M4RfSiQfVlI TiDB 마이그레이션 프로젝트에 참여 합니다.  아직도 100만엔 넘는 프로젝트가 하루에 수십개 씩 쏟아지고 있습니다.  한국의 SI는 지금 시기가 완전 비수기잖아요.. 사고가 아닌 이상 이 시기에는 좋은 프로젝트는 나오지 않을 겁니다. 연초에 시작된 프로젝트에 다들 들어가서 열심히 달리고 있겠죠..  일본 역시 연말 연초 처럼 프로젝트가 많아지는 무렵이 있긴 하지만,  이렇게 비수기라도 최소한 수십개 정도는 언제나 사람을 찾고 있습니다.  물론 눈높이만 낮추면 수백개도 볼 수 있지만,  기본 월 100만엔 위만 찾느라 이 정도인 거죠..  그렇게 보던 중에  단가는 조금 적지만 DB 마이그레이션 프로젝트가 있어서 한 번 인터뷰를 봤죠.  현재는 SQL Server를 사용하지만,  수 년전에 TiDB이관을 검토했다가 드랍 되었다가  다시 이관을 적극 검토하는 것으로 이야기가 되었다고 합니다.  고객사는 연매출이 2000억엔이 넘어가면서  대규모 유저 처리에 고심을 하고 있다고 합니다.  그런데 연매출 2000억엔이 넘는 홈페이지 수준이… =ㅅ=;;; 이거 한국에선 있을 수 없겠죠? 물론 나름 대규모 처리를 위해 불필요한 거 다 배제하고  최소한의 리소스로 최대 처리를 하고 있을지도 모르겠지만요.. TiDB는 도대체 뭐야? 저도 20여년 DB를 만져왔지만 처음 듣는 DB네요..  공식 홈페이지에서 찾아보니  대규모 OLTP에 특화된 MySQL호환 클라우드 DB라고 하네요..  https://pingcap.co.jp/ 뭐, 기존 RDBMS보다 뛰어나다면 왜 아직도 안알려졌지?  생각보다 문제가 있는거 아냐? 라는 걱정이 드네요.. https://db-engines.com/en/ranking 한국의 자랑인 Tibero도 클라우...

영상 버전 :  https://youtu.be/KtRKb2Py5xs 아무 생각없이 쉽게 생각해버린 20 년간 축적된 AIX위의 ORACLE 데이터 이전 작업..  AIX가 서비스연한이 다되어 신규 구매를 해야만 하는 상황이다. 신규 구매 18억 + 연간 6억원의 유지 비용. 5년 사용기준으로 연간 약 10억원의 비용이 드는 것을 x86으로 교체함으로 신규 구매비용 5천만원(2대 이중화)으로 퉁치고 오라클 라이선스도 44Core -> 16 Core로 줄이는 것이 이번 프로젝트의 목표이다. 별 준비 없이 오라클이니까 라는 생각만으로 너무 자체 기능을 믿고 진행 한 것이 문제 였다.  서비스 정지 허용 시간은 교섭에 교섭을 해서 단 7시간..  Full backup만으로 40시간이 걸린다. 게다가 센터가 클라우드 센터 내에 있는 물리 서버라 백업 장비 반입 불가, 백업 영역이 500GB도 채 남지 않은 곳에서 NAS 이용 불가, 1Gbps 네트워크에서 알아서 하랜다. 프로젝트를 받고 나서 이런 상황이었다는 사실을 뒤늦게 알았다.. 당연히 이런거 다 지원해주는 곳인줄 알았는데.. ㅠㅡㅠ 나중에 안 얘기로는 SI업체 견적으론 30억이었다고 한다.  이전이 결정되자마자 DBA는 사표를 던지고.. 대타가 없어 내가 들어와서 간단한 인수인계만으로 준비를 시작.. 서버 선택에서부터 이전준비, 이전작업까지 모두 나 혼자 하게 되어버렸는데, 그냥 그 동안의 경험상 문제 없겠지 하고 개시.. 사전에 이건 미션임파서블이기 때문에 일부 데이터의 누락이 발생하거나 하면 수동처리하는 걸로 합의 했다.  병렬 export & import용 스크립트를 만들어서 충분히 테스트 해봤다. 별 문제없이 계산 상으로 7시간정도에 맞출 수 있었다. 이전 당일... 서비스 정지후 복사 작업 진행.. 사전에 변경되지 않을거라 생각되는 2800여개 테이블을 미리 복사해두고 남은 1500여개의 테이블을 복사하는 시간만 40시간인 것이다....

오라클은 sql을 실행하여 DDL SQL을 만든다거나 하는 것들이 가능한데 문제는 파일로 저장하면 애매한 부분에서 줄넘김이 되면서 에러를 발생시킨다.  이번에 이동해야 하는건 테이블만 12만개나 있어서  하나식 보면서 할 수가 없어 찾아보니.. 여러가지 옵션들이 있어  내 나름대로 정리해 봤다.  #get_ddl.sql set  long  100000 set  head  off set  feed  on set  wrap  on set  linesize  3200 set  pagesize  0 set  trimspool  on set  longchunksize  1024 spool insertout.txt select dbms_metadata.get_dll('TABLE', 'MyTablename', 'MyOwner'); exit long : 한 필드에 표시되는 문자 수. 적으면 내용이 중간에 잘린다.  head off : 필드명을 없앤다.  feed on : 한 필드 내의 줄넘김을 표시한다. off면 한줄만 표시되면서 다음 줄 이후는 잘린다.  wrap on : ?? 기억이;; linesize 3200 : 한 줄에 3200글자까지 지원.. 이게 작으면 오른쪽이 잘린다.  pagesize 0 : 한 줄에 표현하는 페이지.. 숫자가 커도 별로 의미 없이 공백만 생기므로 0으로 설정 trimsppo on : 이건 그냥 붙여봤는데 아직 테스트 안함. lognchunksize 1024 : 오른쪽 글자 잘림을 막아줌(linesize가 있어도 잘리는 경우 이것까지 넣으니까 다음줄로 안넘어가고 옆으로 잘 붙어준다.) spool filename.sql : filename.sql 파일로 출력해준다.  이렇게 처리하면 sql만 들어가기 때문에  ...