Facebook Photo Service Architecture

페이스북의 Photo 서비스 시스템 아키텍쳐
The Photos application is one of Facebook’s most popular features. Up to date, users have uploaded over 15 billion photos which makes Facebook the biggest photo sharing website. For each uploaded photo, Facebook generates and stores four images of different sizes, which translates to a total of 60 billion images and 1.5PB of storage. The current growth rate is 220 million new photos per week, which translates to 25TB of additional storage consumed weekly. At the peak there are 550,000 images served per second. These numbers pose a significant challenge for the Facebook photo storage infrastructure.

1.5 PB의 사진 저장. 2009년 아키텍쳐 문서

http://www.facebook.com/note.php?note_id=76191543919

얻은 아이디어
- 하드웨어 디자인시, 디스크에 Write Back 캐쉬 적용

하나의 이미지 파일이 올라오면 4개의 Resize된 thumnail을 유지.
하나의 PhotoKey에 대해서, 1,2,3,4 thumnail에 대한 reference를 저장
Photo Key + Thumnail reference 를 Index형태로 저장하고 메모리에 유지하여 성능 향상

물리 저장 파일과 (HeyStack Store File)
Index 파일을 나눠서 저장하는 데이타 구조 (HeyStack Index File)-Index 파일은 물리 저장 파일을 통해서 다시 Build가 가능
물리 파일을 먼저 기록한 다음, Index를 Async 방식으로 기록하는 방식. Index 파일은 위와 같은 이유로 Less Critical
Delete Operation은 Index Flag에 deleted로 표시 해놓고, 물리 저장 파일은 Compaction 단계에서 collection
Index는 모두 Memory에 Loading하는 방식을 사용

Summary
Write를 Append 방식으로 하고, search나 read 성능 향상을 위해서 index 파일을 별도 유지하고, index는 memory에 로딩되는 방식을 사용. Update나 Delete는 New file을 append하고, Compaction 단계에서 Copy&Scavange와 유사한 방식으로, deleted로 mark된 needle(file)을 제거하고 복사하는 형태를 사용함