현재 논문과는 별도로 실제 Disk Based Hash를 구현했다.(진행중??)
이것의 속사정은 이렇다.
3만여건의 comment를 training하는데 무려 3시간이 넘는 시간이 필요했기에 테스트의 역동성을 위해서 구현을 해버린 것이다. 왜 3시간이냐? 하고 묻는다면, pos tagger를 헤집어볼 시간이 없어서였다.
이것의 입출력 인터페이스를 위해 무려 3번의 파일 writing을 해버리는 무지막지한 병목을 만들어 버렸다.
결국 어떻게든 파일 기반 해슁을 만들어 버렸으니… 쩝…
사실 파일기반 해쉬를 만들기 전에 공개 DB를 찾아봤다.
버클리DB(BDB)하고 PBL(The Program Base Library) ISAM을 찾아서 비교해봤는데… BDB는 워낙 유명하니 각설하고, PBL은 실제 SpamProbe라는 e-mail 스팸 서버를 개발할때 만들어진 DB이다.
PBL은 BDB와 비슷한 성격의 DB이다. stateless database라는것도 비슷하고 Key, Value 기반의 DB라는것도 비슷하고 말이다.
SpmaProbe를 만든 Brian Burton가 BDB를 지적한 사항을 보면.
1. 키워드가 입력될수록 파일의 크기가 커지는 속도가 키워드의 입력속도보다 빠르다.
2. DB가 불안정하다.
3. 데이터베이스를 traverse할때 무한 루프를 야기할 수 있다.
버클리DB를 실제 써보고 그 단점을 인지한 사람이 만든것이므로 스팸 데이터DB로 손색이 없을듯 하다.
버클리 DB와 PBL ISAM으로 압축되어 버렸으나, 결국 둘다 포기하고 만드는 방향으로 갔다.
이유는 그냥 내가 한번 만들고 싶어서다. 뭐 파일 시스템 만들어본적도 오래 된거 같구. 내 논문이니 내 맘이다. ㅋㅋㅋ
일단 예전에 기억을 되살려 몇몇 파일관련 함수들을 D로 만들었다.
물론 지금은 이것보다 많이 변해 있지만, 아마도 다른 언어로 개발한다고 치더라도 그리 크게 변하는 부분은 없을듯 하다.
검색엔진 색인 압축에 나오는 variable-int 같은것도 쓰고, String 같은 경우는 utf-8로 저장을 하는 구조로 가봤다. 나중에는 다른 압축 방법도 써보면서 비교도 해봐야 겠다.
D 언어 자체가 UTF-8 기반의 유니코드 문자열을 쓰기 때문에 파일 시스템 구현에 그렇게 큰 문제는 없었지만, 다른 인코딩 기반의 언어로 개발 한다면 String write 부분에 대한 고민을 좀 더 해야할 것이다.
해쉬 본체는 말구, 기본 함수들만 일단 올려본다.
잘 되면 분산 해쉬로도 한번 발전시켜 볼란다.
Spam서버 저장 구조 관련 by from __future__ import dream is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License.