[Devonthink pro] 데본씽크 인덱스(Index) or 인서트(Insert) ??
- 키노트와 MAC
- 2012. 11. 27.
반응형
데본씽크를 사용하면서 개인 DB의 폴더 트리 구조를 구축하는것 외에, 데본씽크를 사용함에 있어서 우선적으로 결정해야 할 사항이 2가지가 있습니다.
1. 단일 DB or 복합 DB
2. Index or Insert
단일 DB로 운용할것이냐 아니면 복합 DB로 구분해서 사용할 것이냐는 나중에 차차 적어보기로 하고...
이번에는 Index 와 Insert 의 차이점과 어떤 결과를 이용할 수 있을지에 대해 살펴봅니다.
먼저 데본씽크에서 기능하는 2가지의 방법은 다음의 프로세스처럼 작동합니다.
Index : 자료는 하드디스크에 그대로 있는 상태이며, 데본씽크 DB와 연결만 해두는 상태입니다. 즉, 자료는 하드 어딘가에 위치해 있으나, 그 폴더를 뒤져가며 직접 찾는것이 아니라 데본씽크에서 검색 등을 이용하여 한 곳에서 찾아볼 수 있습니다. 인덱스의 장점은 바로 DB 자체의 용량을 작게 관리할 수 있다는 점입니다. 데이터 자체가 DB에 포함되는것이 아니라 인덱스 링크 정보만 기록되기 때문에 DB는 경량화된 상태로 관리할 수 있습니다.
예를들어, 외장하드에 있는 A라는 이미지를 데본싱크에 인덱스로 링크를 잡아주면, 데본씽크에서 얼마든지 검색을 활용하여 찾아낼 수 있습니다. 이때의 A라는 이미지는 내부 하드에 있든, 외장하드에 있든 검색할 수 있기 때문에 편리합니다. 처음으로 인덱스만 해두면, 그 다음부터는 사용자가 그 파일이 어디쯤에 위치해 있는지 기억하지 않아도 됩니다. 단지 데본씽크에서 A 이미지의 제목으로 검색을 하거나 태그 등을 활용하여 빠르고 쉽게 찾을 수 있습니다. 이것은 마치 MAC OS X 의 Spotlight와도 비슷합니다.
아무리 소량의 링크 데이터만 기록되긴 하지만, 수십GB가 넘는 자료를 모두 인덱스하면 그 인덱스 정보만도 몇 백MB까지 올라갈 수 있습니다. 물론 인덱스 기능만 있기 때문에 이정도면 가벼운 편이긴 하지만요.
Insert : 말 그대로 데이터 자체를 데본씽크 DB에 삽입하는 것입니다. 가령, 1MB짜리 문서를 Insert하면 DB의 용량이 1MB가 되는 형식입니다. 데이터를 DB에 삽입했다면, 이제 원래있던 데이터는 삭제해도 무방합니다. 마치 USB나 외장하드처럼 동일한 자료가 DB에 고스란히 있기 때문이죠.
Insert 방식은 하드디스크를 깔끔하게 관리하고 싶다든지(어차피 하드에서 차지하는 용량은 비슷합니다.), SSD를 사용하면서 DB를 외장하드에 저장하는 형태처럼 약간 우회적인 방법일 때 효과적일 것 같습니다. 아니면 단순히 저처럼 귀차니즘을 싫어하고, 한 곳에서 모든 데이터를 쉽게 관리하고 싶은 사람에게도 적합한 방식이 아닐까 생각해 봅니다.
데본씽크 프로그램 자체에서는 인서트보다는 인덱스 방식을 권장하는 듯 보입니다. 인덱싱을 권고하면서 스팟라이트에서 검색할 수 있음을 처음에 팝업창으로 띄우는것을 본 바로는요. 아무래도 데본씽크또한 100% 완벽한 프로그램이 아니고, DB의 용량이 무지막지하게 커질 경우 버그라든지 로딩 시간 등으로 인해 발생할 수 있는 여러가지 오류들을 조금이나마 방지하고자 함이 아닐까 생각해봅니다. 이런점에서 미루어볼 때, 데본씽크는 Index or Insert 와 단일 DB or 복합 DB를 동시에 결정해야 되는 프로그램입니다.
어떤 방식을 사용하시던 편하신대로 하시면 가장 좋습니다.
저같은 경우에는 복합DB + Insert 방식으로 활용하고 있습니다.
Index 방식을 고민해봤는데, 백업과 관련하여 애로사항이 있더군요. 어차피 원본파일은 어딘가에는 백업해야 하는데 DB가 GB급으로 가게되면 더 이상 드롭박스 같은 클라우드로는 불가능하기 때문에 타임머신밖에 답이 없는것 같았습니다. 그런데, 어차피 타임머신으로 백업을 할 요량이면, 차라리 Insert해서 DB의 크기가 크더라도 문제가 없기 때문에 저는 Insert를 하고 있네요. 그리고 Insert는 소비되는 인덱싱 용량(매우 소량이지만)도 절약할 수 있으니까요. 외장하드에 있는 자료같은것들은 Index가 나아보이긴 합니다만, 반대로 생각해보면 차라리 외장하드에 있는 모든 자료를 데본씽크에 때려박고, 그 외장하드를 상대로 타임머신 하는게 낫지 않나 싶습니다.
데본씽크의 속도 문제는 복합 DB로 어느정도 케어할 수 있을것 같습니다.
이 부분은 복합DB에 대한 내용을 적을 때 함께 적도록 하겠습니다.
1. 단일 DB or 복합 DB
2. Index or Insert
단일 DB로 운용할것이냐 아니면 복합 DB로 구분해서 사용할 것이냐는 나중에 차차 적어보기로 하고...
이번에는 Index 와 Insert 의 차이점과 어떤 결과를 이용할 수 있을지에 대해 살펴봅니다.
먼저 데본씽크에서 기능하는 2가지의 방법은 다음의 프로세스처럼 작동합니다.
Index : 자료는 하드디스크에 그대로 있는 상태이며, 데본씽크 DB와 연결만 해두는 상태입니다. 즉, 자료는 하드 어딘가에 위치해 있으나, 그 폴더를 뒤져가며 직접 찾는것이 아니라 데본씽크에서 검색 등을 이용하여 한 곳에서 찾아볼 수 있습니다. 인덱스의 장점은 바로 DB 자체의 용량을 작게 관리할 수 있다는 점입니다. 데이터 자체가 DB에 포함되는것이 아니라 인덱스 링크 정보만 기록되기 때문에 DB는 경량화된 상태로 관리할 수 있습니다.
예를들어, 외장하드에 있는 A라는 이미지를 데본싱크에 인덱스로 링크를 잡아주면, 데본씽크에서 얼마든지 검색을 활용하여 찾아낼 수 있습니다. 이때의 A라는 이미지는 내부 하드에 있든, 외장하드에 있든 검색할 수 있기 때문에 편리합니다. 처음으로 인덱스만 해두면, 그 다음부터는 사용자가 그 파일이 어디쯤에 위치해 있는지 기억하지 않아도 됩니다. 단지 데본씽크에서 A 이미지의 제목으로 검색을 하거나 태그 등을 활용하여 빠르고 쉽게 찾을 수 있습니다. 이것은 마치 MAC OS X 의 Spotlight와도 비슷합니다.
아무리 소량의 링크 데이터만 기록되긴 하지만, 수십GB가 넘는 자료를 모두 인덱스하면 그 인덱스 정보만도 몇 백MB까지 올라갈 수 있습니다. 물론 인덱스 기능만 있기 때문에 이정도면 가벼운 편이긴 하지만요.
Insert : 말 그대로 데이터 자체를 데본씽크 DB에 삽입하는 것입니다. 가령, 1MB짜리 문서를 Insert하면 DB의 용량이 1MB가 되는 형식입니다. 데이터를 DB에 삽입했다면, 이제 원래있던 데이터는 삭제해도 무방합니다. 마치 USB나 외장하드처럼 동일한 자료가 DB에 고스란히 있기 때문이죠.
Insert 방식은 하드디스크를 깔끔하게 관리하고 싶다든지(어차피 하드에서 차지하는 용량은 비슷합니다.), SSD를 사용하면서 DB를 외장하드에 저장하는 형태처럼 약간 우회적인 방법일 때 효과적일 것 같습니다. 아니면 단순히 저처럼 귀차니즘을 싫어하고, 한 곳에서 모든 데이터를 쉽게 관리하고 싶은 사람에게도 적합한 방식이 아닐까 생각해 봅니다.
데본씽크 프로그램 자체에서는 인서트보다는 인덱스 방식을 권장하는 듯 보입니다. 인덱싱을 권고하면서 스팟라이트에서 검색할 수 있음을 처음에 팝업창으로 띄우는것을 본 바로는요. 아무래도 데본씽크또한 100% 완벽한 프로그램이 아니고, DB의 용량이 무지막지하게 커질 경우 버그라든지 로딩 시간 등으로 인해 발생할 수 있는 여러가지 오류들을 조금이나마 방지하고자 함이 아닐까 생각해봅니다. 이런점에서 미루어볼 때, 데본씽크는 Index or Insert 와 단일 DB or 복합 DB를 동시에 결정해야 되는 프로그램입니다.
어떤 방식을 사용하시던 편하신대로 하시면 가장 좋습니다.
저같은 경우에는 복합DB + Insert 방식으로 활용하고 있습니다.
Index 방식을 고민해봤는데, 백업과 관련하여 애로사항이 있더군요. 어차피 원본파일은 어딘가에는 백업해야 하는데 DB가 GB급으로 가게되면 더 이상 드롭박스 같은 클라우드로는 불가능하기 때문에 타임머신밖에 답이 없는것 같았습니다. 그런데, 어차피 타임머신으로 백업을 할 요량이면, 차라리 Insert해서 DB의 크기가 크더라도 문제가 없기 때문에 저는 Insert를 하고 있네요. 그리고 Insert는 소비되는 인덱싱 용량(매우 소량이지만)도 절약할 수 있으니까요. 외장하드에 있는 자료같은것들은 Index가 나아보이긴 합니다만, 반대로 생각해보면 차라리 외장하드에 있는 모든 자료를 데본씽크에 때려박고, 그 외장하드를 상대로 타임머신 하는게 낫지 않나 싶습니다.
데본씽크의 속도 문제는 복합 DB로 어느정도 케어할 수 있을것 같습니다.
이 부분은 복합DB에 대한 내용을 적을 때 함께 적도록 하겠습니다.
반응형