GFS와 RocksDB의 Block Cache 모델 비교 (feat. OS Page/Buffer Cache)

GFS 논문에는 아래와 같은 내용이 나온다. Linux의 buffer cache를 믿고 file data를 cache하지 않는다고 한다.

Neither the client nor the chunkserver caches file data. Client caches offer little benefit because most applications stream through huge files or have working sets too large to be cached. Not having them simplifies the client and the overall system by eliminating cache coherence issues. (Clients do cache metadata, however.) Chunkservers need not cache file data because chunks are stored as local files and so Linux’s buffer cache already keeps frequently accessed data in memory.

 

RocksDB에서는 자체적으로 block cache를 사용한다.

Logical reads are those that get data from cache, either the RocksDB block cache or the OS filesystem cache.

 

어떤 이유로 두 서비스는 서로 다른 접근 방법을 선택했을까?

 

GFS의 Assumptions 4번째에서는 아래와 같은 내용이 나온다.

The workloads also have many large, sequential writes that append data to files. Typical operation sizes are similar to those for reads. Once written, files are seldom modified again. Small writes at arbitrary positions in a file are supported but do not have to be efficient

 

그리고 RocksDB 애초에 KeyValue Storage이고 RocksDB In Memory Workload Performance Benchmarks 에서도 each value is of size 100 bytes 라고 가정하고 있다.

 

결론은 애초에 두 서비스는 workload의 패턴부터 너무 많이 다르다. OS의 Page/Buffer Cache는 하나의 큰 파일에 대해서 Streaming READ/WRITE 요청이 주된 workload일 때에는 대안이 될 수 있겠지만, key 방식으로 query path 기준으로 파일을 찾아가는 경우에는 상대적으로 너무 많은 File에 대한 접근이 필요해서 OS의 Page/Buffer Cache에 의존하기에는 어려움이 있어보인다.

Reference

- Goofle File System

- RocksDB Tuning Guide