|
2012-06-12 08:09
조회: 12,148
추천: 3
데이터베이스 입장에서 본 이번 사건 추론서론은 빼고 본론과 결론만 쓰겠습니다. 글이 너무 길다고 생각하시는 분은 결론만 보세요. -본론- 사실 1: 이번 사건이 일어나기 전 경매장의 조회 등 속도가 엄청 느린 적이 있음.
사실 2: 서버 점검 후 경매장 조회 속도가 개선됨
사실 4: 어제 경매장을 들어가보니 마치 이전처럼 속도가 느려진 점을 확인함.
위의 사실 3의 빨간 글에서 오류가 있는데도 아무도 오류를 지적하지 않아서 이렇게 글을 쓰게되었습니다.
아래부터는 사실을 근거로 한 추론 : 중복 저장을 허용하지 않도록 설계되었다는 말은 앞서 설명드린 unique index나 primay key를 설정했다는 내용인데요. 정말로 이렇게 설정되어 있으면 종복으로 저장되면 안됩니다. 이건 데이터베이스의 기본이기 때문입니다. 이렇게 설정했는데도 중복으로 저장된다는 건 데이터베이스 제품에 문제가 있는 것입니다. 그런데 이런 제품은 들어본 적이 없습니다. 그렇다면 데이터베이스 자체가 아이템 중복 저장을 허용하지 않도록 설계되어있었지만 특정한 사유로 인하여 중복으로 저장되게끔 변경이 되었다는 것을 추론할 수 있습니다.
특이한 점으로 이번 사건 직전에 경매장 등 속도 개선이 이루어진 적이 있으며 이는 주로 데이터베이스 입장에서 보면 인덱스 작업을 하면 됩니다. 인덱스가 좋으면 속도도 좋지만 인덱스가 나쁘면 속도도 안 좋아지기 때문입니다. 어제 다시 경매장 속도가 느려진 점이 이전의 인덱스로(unique index) 복구되었기 때문이라고 생각됩니다.
즉, 이전의 점검에서 index작업으로 인하여 데이터베이스에 중복 저장되도록 변경이 되었다고 추측해봅니다.
또한 서버 점검시간이 길어진게 당직자밖에 없다는 등의 내용이 있던데요. IT를 무시하지 마십시요. 남들 일할 때 일하고 남들 놀 때 일합니다. --;;; 제가 봤을 때는 중복저장을 피하기 위하여 unique index를 만드는데 시간이 아주 많이 필요했다고 생각됩니다. unique index를 만들려면 현재 존재하는 data가 중복된 건이 있으면 안되기 때문에 중복 data를 삭제하고 unique index를 만들어야 합니다. 중복 data를 삭제하기 위해서도 (실제 data건수는 모르지만) 많은 시간이 걸리고 이 작업 후 다시 index를 만드는데 또 많은 시간이 걸렸던 것으로 보입니다. ( 이 과정에서 중복 data가 삭제되었고 이로 인한 2차 피해가 발생한 것으로 생각됨)
-결론- 아이템이 복제된 사람 / 골드가 복제된 사람 / 이번 작업 후 골드 및 아이템이 없어진 사람 등 어떠한 내용이든 피해를 본 사람에 대해서는 위의 추론이 맞다면 블쟈에서 책임을 져야 됩니다. 왜냐하면 중복 저장을 허용하게끔 만든 블자로 인하여 발생한 사건이기 때문입니다. 즉 제품의 기능상의 이슈이지 개인의 잘잘못이 아니라는 말입니다. 중요한건 위의 내용을 입증할 증거는 없다는 점입니다. --ㅋ 아쉽네요.
-끝-
EXP
14
(14%)
/ 101
|
ODM