영상버전 : https://youtu.be/mV7uoGQlm5g 이번엔 기술 vlog입니다. 제 기술 관련 이야기를 기다리시다가 쓸데없는 바이크 이야기 같은거 자주 올리니 구독 취소를 하시는 분들이 급증 했네요 ㅠㅡㅠ 사실 처음부터 자기 미래를 설계하는데 도움되는 정보를 찾으시는 분들이 들어오시는 곳이었으니 그렇겠지요.. 그래도 일본에서 IT하는 사람이 이렇게 놀기도 하는 구나 하고 일본에서의 취미 생활에 참고도 해주셨으면 합니다. ^^;;; 아뭏든 기다리시던 이야기를 해드릴께요~ 7월부터 참가했던 SQL Server를 TIDB로 전환하는 프로젝트가 어느덧 많은 준비를 마치고 최종 PoC를 진행하고 있습니다. 제가 초기에는 TiDB가 더 느릴걸요? 등등의 가벼운 반박 정도를 하면서 어짜피 회사의 70명이 넘는 인원이 이 프로젝트에 연관되어 이전이 결정이 된 상태였습니다. 지난 번 DNP(대일본 출판, 일본 최대의 출판회사) 사건도 있었다보니 사실을 이야기하면 안되겠다 싶어서 그냥 시키는대로만 도와주려고 슬렁슬렁 하고 있었습니다. 그렇게 열심히 WBS도 만들어서 많은 부서에서 체크하고 2차 PoC까지 끝내던 어느날 이었습니다. PoC결과 표를 보면서 리포트를 작성하는 회의를 했는데, 저도 초대 받아서 참여를 했지요. 1TiDB + 3TiKV에서 2TiDB + 6TiKV까지 4가지 패턴으로 테스트를 한 결과를 바탕으로 스파이크에 대한 이유와 해결 방법 등을 적으려고 TiDB쪽 사람이랑 이야기를 하던 중이었습니다. 2TiDB + 6TiKV만 스파이크가 없고 1TiDB + 3TiKV, 1TiDB + 6TiKV나 2TiDB + 3TiKV가 모두 스파이크가 존재했는데요. TIDB담당자는 이 이유에 대해서는 그 떄 마침 무거운 쿼리가 들어왔을 거라고 몰아가고 있었습니다. 그런데 테스트 한 사람은 그냥 같은 쿼리를 반복해서 돌렸는데… 라면서 반신반의로 받아들이더라구요.. 그도그럴게 그 대답만으로는 고객이 명쾌하게 OK를 내지 못할 거 같더랍니다.