더 빠른 (부가적 의존성 없는) 파일 캐시 스토어

어제(2013.7.17) 아드리안이 발표하였듯이, 새로운 인피니스팬 6.0.0.Alpha1는 부가적인 의존성을 필요로 하지 않는 새로운 파일 기반 캐시스토어를 포함한다. 이는 의도한 대로 동작하지 않았고, 그리고 생성하는 파일 개수 때문에 큰 문제를 발생시켰던 기존의 FileCacheStore를 완전히 대체한다.

이 새로운 캐시스토어는 (비동기 캐시스토어 향상에도 기여했던) 칼스텐 블리스(Karsten Blees)가 제공하였는데, SingleFileCacheStore라고 이름지어졌고 모든 데이터를 하나의 파일에 둔다. 키와 이 파일안에서 값들의 위치에 대한 인덱스를 메모리 유지하며 데이터를 찾는다. 이 설계는 기존의 FileCacheStore와 심지어는 LevelDB 기반 JNI 캐시스토어보다 성능이 좋다.

파일 기반 캐시스토어의 일반적인 용도는 메모리 크기나 시간 제약에 의해 메모리로부터 제거된 데이터를 로컬 캐시 스토어에 저장하려고 하는 것이다. 우리는 몇 개의 다른 캐시 스토어 구현체가 이 메모리로부터 넘쳐나오는 데이터를 읽고 쓰는 것을  얼마나 빠르게 처리하는지 테스트했고 결과는 아래와 같다.

• FileCacheStore: 0.75k reads/s, 0.285k writes/s
• LevelDB-JNI impl: 46k reads/s, 15.2k writes/s
• SingleFileCacheStore: 458k reads/s, 137k writes/s

그 차이는 매우 놀랍다. 하지만 위에서 힌트를 주었듯이 이 성능 향상을 위해서는 비용이 따른다. 메모리상에 파일 내 키와 위치의 인덱스를 유지 해야만 하기 위해 추가 메모리가 필요하고, 가비지 컬렉션에 대한 잠재적인 영향이 있을 수 있다는 것은 비용이 된다. 그래서 SingleFileCacheStore는 키가 아주 클 경우에는 추천하지 않는다.

이  메모리 소비 문제를 완화하기 위해, 캐시스토어의 크기는 저장할 엔트리의 최대 개수를 제공함으로써 선택적으로 제한될 수 있다. 하지만 이 파라미터는 인피니스팬이 캐시로 사용될 때만 동작한다. 캐시로 사용될 때, 인피니스팬에 있지 않은 데이터는 믿을만한 데이터 스토어로부터 재계산되거나 다시 불려와서 인피니스팬 캐시에 저장된다. 이 제약의 원인은, 일단 엔트리의 최대 개수가 도달되면, 캐시 스토어의 예전 데이터는 삭제된다. 그래서 만약 인피니스팬이 믿을만한 데이터 스토어로 쓰인다면 데이터를 잃어버리게 되고 이것은 좋지 않다.

기존의 FileCacheStore 사용자는 궁금해할 것이다. 기존 FileCacheStore은 어떻게 될 것인가? 아직은 어떻게 될지 확신할 수 없다. 하지만 FileCacheStore의 데이터를 SingleFileCacheStore로 이전하기 위한 방법이 있는지 찾고 있다. 벌써 몇 개의 흥미로운 아이디어를 받았고, 다음 인피니스팬 6.0 이전 릴리즈에 조사할 예정이다.

그래서 만약 FileCacheStore를 사용한다면, SingleFileCacheStore를 한 번 사용해보고 어떤지 우리에게 알려달라. 전환하는 것은 쉽다. ^^

갤더(Galder)

원문:
Thursday, 18 July 2013, Faster file cache store (no extra dependencies!) in 6.0.0.Alpha1