모델링에 대한 생각

그간 여러 사이트를 다니고 나서 느낀 모델링에 대한 개인적인 소회, 생각들 한번 정리해보자.

 

- 튜닝에 비해 바로 효과 나타나지 않아 중요해 보이지 않는다. 

한때 좋은 모델과 데이터의 품질에 대해서 신경을 쓰려던 트렌드가 잠깐 생겼었는데 조금은 뜸해진 느낌

튜닝은 바로 효과가 나타나고 비용과 즉시 연결이 된다. 클라우드의 시대가 오면서 더 확고해졌다. 

온프레미스에선 성능 개선으로 자원사용륭이 낮아졌다고 해서 서버를 낮은 스펙으로 바꾸지 않는다. 

이미 구매를 한 서버니 그럴일이 없다. 어느 정도 이상의 튜닝은 굳이 할 필요가 없다. 

하지만 클라우드에서는 서버의 스펙다운이 자유롭다. 튜너를 투입해서 얻은 성능개선이 운영비 절감을 가시적으로 할수있게 되었다. 

 

- 통합 관점의 표준은 개별적이고 독립적으로 개발하는 MSA 트렌드와 상충

물론 완전히 하나를 버리고 하나를 택하는 극단적인 상황까지 가는 것은 아니지만 통합 관점의 표준과 데이터의 중복도 허용하지 않는 기존의 방식을 계속 고수하려면 갈등이 발생한다. 

 

- 잘못된 모델은 시간이 한참 지나고 나서야 비싼 청구서를 부과한다. 

물리모델은 dbms 의 특성을 반영할수 밖에 없는데 최근에 mysql 로 환경이 많이 바뀌면서 이 특성을 잘 고려해야한다. 

오라클은 인덱스를 통해 데이터를 찾아갈때 인덱스의 리프노드에서 데이터의 rowid 를 찍어서 바로 원하는 데이터를 찾아갈수 있지만 mysql 은 조금 방식이 다르다.

mysql 의 innodb 테이블에서는 pk 가 클러스터링 되어 저장이 되는데, 세컨더리 인덱스에서 rowid 를 찍는것이 아니라 pk 를 찍어준다. 그래서 pk 가 여러 칼럼으로 구성되면 인덱스의 크기가 커지고 성능상 불리함이 있다. 

그래서 mysql 은 단순하게 일련번호로 pk 를 만드는 오라클의 모델링에서는 참을수 없는 방식으로 가이드를 한다.

다만 이때도 업무식별자를 도출해 유니크 인덱스를 만들 필요가 있다.

일련번호로 식별자를 만들때의 단점은 어떤 규칙으로 데이터가 만들어지는지 파악하기 힘들다는 것에 있다. 

심한경우 운영환경에서 여러사람을 거친 경우 나중에는 특정 테이블을 잘못 사용하고 있거나 무슨 테이블인지 모르겠다고 해서 비슷한 새로운 테이블을 또 만드는 경우가 생기게 된다. 

- 틀린 모델로 운영이 가능하다 .


안타까운 사실은 모델이 틀려도 어떻게든 운영을 한다는 것이다. 물론 내눈에 보이지 않는 누군가의 노력이 있었겠지만. 

좋은 모델을 만들고 유지하려면 비용을 지불해야 하지만 당장의 우선순위에서 밀리다 보니 고객은 이쪽에 더 돈을 지불할 의사를 보이지 않는듯한 느낌이다.