인덱스를 어떤 녀석으로 하셨는지 잘 모르겠습니다만, 웬만한 인덱스에서 삭제를 해도 파일크기가 줄지 않는 것은 별로 이상한 현상은 아닙니다.
단지 그 데이터부분이 그냥 가비지로 남게 되는 것이지요. 나중에 다시 그부분을 사용할지 사용하지 않을지도 보장할수 없습니다. 데이터가 static한 크기라면 다시 사용할수도 있겠지만 variable 이라면 그냥 가비지가 될 가능성이 높습니다. berkeley db 인덱싱 스킴마다 코드를 제대로 읽어본 적은 없으니 자신은 할 수 없습니다만, 결론은 별로 이상한 현상은 아닙니다.
물론 같은 이야기이지만 insert/delete를 계속 반복했을때 파일크기가 점점 커지기만 해도 별로 이상한 현상은 아니지요. 8)
직업상 berkeley db나 gdbm같은 인덱스 코드를 직접 만들게 되는 경우가 꽤 많이 있었는데, 저같은 경우는 보통 delete는 index에서만 값을 지워버리는 방법을 택합니다. 그리고 차라리 optimizer를 하나 더 만들지요. 물론 이런 방법은 insert가 많고 delete가 적으며 search를 빨리 해야 하는 requirement때문에 택하는 방법입니다만...
아마도 파일처리론 책이야 수도없이 보셨겠지만, 어떤 인덱스 시스템에서고 delete를 제대로 처리하기란 보통 골치아픈 일이 아닙니다.
한마디 더 덧붙이자면 berkeley db를 사용하고 계시니 인덱스 스킴을 다른 녀석으로 바꿔서도 실험해보세요. 그리고 현재 하셔야 하는 작업이 delete가 잦고 실제 운영환경이 space에 민감한 곳이라면 데이터를 잘 운용하는 다른 인덱스를 사용해보시는 것이 좋을것 같습니다. 하지만 저같으면 가장 서치가 빠른 녀석을 택하고 traverse- insert를 처음부터 해 데이터를 새로 생성하는 optimizer를 하나 만드는 쪽을 택하겠습니다.
별로 이상한 것은 없는데요.
인덱스를 어떤 녀석으로 하셨는지 잘 모르겠습니다만, 웬만한 인덱스에서 삭제를 해도 파일크기가 줄지 않는 것은 별로 이상한 현상은 아닙니다.
단지 그 데이터부분이 그냥 가비지로 남게 되는 것이지요. 나중에 다시 그부분을 사용할지 사용하지 않을지도 보장할수 없습니다. 데이터가 static한 크기라면 다시 사용할수도 있겠지만 variable 이라면 그냥 가비지가 될 가능성이 높습니다. berkeley db 인덱싱 스킴마다 코드를 제대로 읽어본 적은 없으니 자신은 할 수 없습니다만, 결론은 별로 이상한 현상은 아닙니다.
물론 같은 이야기이지만 insert/delete를 계속 반복했을때 파일크기가 점점 커지기만 해도 별로 이상한 현상은 아니지요. 8)
직업상 berkeley db나 gdbm같은 인덱스 코드를 직접 만들게 되는 경우가 꽤 많이 있었는데, 저같은 경우는 보통 delete는 index에서만 값을 지워버리는 방법을 택합니다. 그리고 차라리 optimizer를 하나 더 만들지요. 물론 이런 방법은 insert가 많고 delete가 적으며 search를 빨리 해야 하는 requirement때문에 택하는 방법입니다만...
아마도 파일처리론 책이야 수도없이 보셨겠지만, 어떤 인덱스 시스템에서고 delete를 제대로 처리하기란 보통 골치아픈 일이 아닙니다.
한마디 더 덧붙이자면 berkeley db를 사용하고 계시니 인덱스 스킴을 다른 녀석으로 바꿔서도 실험해보세요. 그리고 현재 하셔야 하는 작업이 delete가 잦고 실제 운영환경이 space에 민감한 곳이라면 데이터를 잘 운용하는 다른 인덱스를 사용해보시는 것이 좋을것 같습니다. 하지만 저같으면 가장 서치가 빠른 녀석을 택하고 traverse- insert를 처음부터 해 데이터를 새로 생성하는 optimizer를 하나 만드는 쪽을 택하겠습니다.
감사합니다.
답변에 감사합니다.
버클리db를 첨으로 사용하여 프로젝트를 진행하고 있습니다.
좋은글 마니 부탁드립니다.
댓글 달기