2009년 03월 14일
Schemaless 시작
How FriendFeed uses MySQL to store schema-less data를 보고 영감을 받아 자바 버전을 만들었습니다. 개념이 간단하기 때문에 만들기도 쉬웠습니다. 기본 기능은 모두 구현이 되었고 깨진 인덱스를 효과적으로 복구하는 기능만 완료하면 필수 기능은 모두 구현이 됩니다.
엔티티와 인덱스를 분리하여 다루는 방식은 확장성, 가용성 면에서 장점이 있고, 스키마가 없다는 점은 유연성과 가용성면에서 장점이 있습니다. 이 둘이 조합되어 가용성, 확장성, 유연성 모두를 만족시킬 수 있습니다.
프로젝트를 뛰어야 시험해볼 수 있을텐데... 다시 일자리를 구할 수 있게 빌어 주세요. ㅋㅋ
엔티티와 인덱스를 분리하여 다루는 방식은 확장성, 가용성 면에서 장점이 있고, 스키마가 없다는 점은 유연성과 가용성면에서 장점이 있습니다. 이 둘이 조합되어 가용성, 확장성, 유연성 모두를 만족시킬 수 있습니다.
프로젝트를 뛰어야 시험해볼 수 있을텐데... 다시 일자리를 구할 수 있게 빌어 주세요. ㅋㅋ
# by | 2009/03/14 00:14 | Java | 트랙백(1) | 덧글(3)
☞ 내 이글루에 이 글과 관련된 글 쓰기 (트랙백 보내기) [도움말]
제목 : 디토의 생각
How FriendFeed uses MySQL to store schema-less data / Schemaless ? / 나도 한번 해볼까?...more
원문과 관련글을 읽어보니 2가지 의문점이 생기는데요.
1. Cleaner 프로세스가 어떻게 돌아가는지 대강의 방법이라도 알 수 있을까요?
2. Tokyo Cabinet이 Hash와 B-tree를 사용하는 건 알겠는데, 쿼리에 조건까지 넣을 수 있다는건 제가 생각하기에는 full-scan인데요. 그만큼 성능이 받쳐준다는 건가요? 아님 이와 같이 인덱스를 따로 지정할 수 있는 것인가요? 제가 본 Tokyo Cabinet 예제 Ruby 코드가 있는 URL은 여깁니다.
http://www.igvita.com/2009/02/13/tokyo-cabinet-beyond-key-value-store/
재미있고 유익한 글 올려주셔서 감사합니다.^^
2. Tokyo Cabinet 이야기는 다른 이야기인 듯 한데... Hash는 순서가 없지만 B-Tree는 순서가 있습니다. 그래서 원하는 범위의 키에 해당하는 값을 풀스캔하지 않고 읽을 수 있습니다.
Tokyo Cabinet은 좀 더 살펴봐야겠네요.
적절한 프로젝트 맡으셔서 능력을 발휘하시길 기원합니다.