Bài báo này mô tả về Haystack - một hệ thống lưu trữ được được tối ưu hóa cho việc lưu trữ hình ảnh của Facebook. Hiện tại trên hệ thống Facebook đang lưu trữ khoảng 260 tỷ hình ảnh, tương đương với khoảng 20 petabyte dữ liệu. Người dùng tải lên 1 tỷ hình ảnh mới mỗi tuần, và đỉnh điểm Facebook phục vụ khoảng 1 triệu truy vấn hình ảnh trên giây. Haystack cung cấp một giải pháp rẻ hơn, hiệu năng cao hơn phương pháp sử dụng NFS. Các thiết kế hệ thống lưu trữ truyền thống tốn rất nhiều chi phí hoạt động của ổ đĩa do phải thường xuyên tìm kiếm metadata. Chúng tôi cẩn thận giảm bớt kích thước metadata của mỗi ảnh vì vậy các máy lưu trữ Haystack có thể tìm kiếm metadata của hình ảnh trực tiếp trên bộ nhớ chính. Việc này đã làm giảm được các thao tác đọc dữ liệu từ ổ đĩa. Nhóm dịch: Trần Trung Hiếu, Phan Thế Hoàng, Nguyễn Khắc Nam, Cao Văn Long

1. Tìm kiếm needle trong Haystack: Hệ thống lưu trữ ảnh của Facebook
Doug Beaver, Sanjeev Kumar, Harry C. Li, Jason Sobel, Peter Vajgel
Facebook Inc.
{doug, skumar, hcli, jsobel, pv}@facebook.com
Nhóm dịch: Trần Trung Hiếu, Phan Thế Hoàng, Nguyễn Khắc Nam, Cao Văn Long
Ngày 12 tháng 5 năm 2017
Tóm tắt nội dung
Bài báo này mô tả về Haystack - một hệ thống lưu trữ được
được tối ưu hóa cho việc lưu trữ hình ảnh của Facebook.
Hiện tại trên hệ thống Facebook đang lưu trữ khoảng 260
tỷ hình ảnh, tương đương với khoảng 20 petabyte dữ liệu.
Người dùng tải lên 1 tỷ hình ảnh mới mỗi tuần, và đỉnh
điểm Facebook phục vụ khoảng 1 triệu truy vấn hình ảnh
trên giây. Haystack cung cấp một giải pháp rẻ hơn, hiệu
năng cao hơn phương pháp sử dụng NFS. Các thiết kế
hệ thống lưu trữ truyền thống tốn rất nhiều chi phí hoạt
động của ổ đĩa do phải thường xuyên tìm kiếm metadata.
Chúng tôi cẩn thận giảm bớt kích thước metadata của
mỗi ảnh vì vậy các máy lưu trữ Haystack có thể tìm kiếm
metadata của hình ảnh trực tiếp trên bộ nhớ chính. Việc
này đã làm giảm được các thao tác đọc dữ liệu từ ổ đĩa.
1 Giới thiệu
Chia sẻ hình ảnh là một trong những tính năng phổ biến n-
hất Facebook. Tính đến nay, người dùng đã tải lên khoảng
65 tỷ hình ảnh khiến cho Facebook trở thành trang web
chia sẻ hình ảnh lớn nhất thế giới. Với mỗi ảnh tải lên,
Facebook tạo ra và lưu trữ 4 kích thước khác nhau của
chúng, tương đương với tổng số 260 tỷ hình ảnh và hơn
20 petabyte dữ liệu. Người dùng tải lên 1 tỷ hình ảnh mới
mỗi tuần, và đỉnh điểm Facebook phục vụ khoảng 1 triệu
truy vấn hình ảnh trên giây. Như chúng tôi kỳ vọng, số
lượng ảnh sẽ tiếp tục tăng lên trong tương lai và tạo ra
một thách thức lớn đối với cơ sở hạ tầng của Facebook. Bài
báo này trình bày về thiết kế và cách triển khai hệ thống
Haystack - hệ thống lưu trữ hình ảnh của Faecbook đã
được công bố 24 tháng trước. Chúng tôi thiết kế Haystack
cho việc chia sẻ hình ảnh trên Facebook trong đó dữ liệu
được ghi một lần, đọc nhiều lần, không bao giờ sửa và rất
ít khi xóa. Chúng tôi phải thiết kế một hệ thống lưu trữ
của riêng mình vì các hệ thống file truyền thống không đủ
khả năng phục vụ khối lượng công việc lớn của chúng tôi.
Theo kinh nghiệm của chúng tôi, nhược điểm của hệ
thống POSIX[21] dựa trên hệ thống tệp tin truyền thống
là những thư mục và metadata của mỗi file. Đối với chương
trình lưu trữ ảnh, hầu hết metadata chẳng hạn như quyền
truy cập thì không được sử dụng và gây lãng phí rất nhiều
không gian lưu trữ. Tuy nhiên, chi phí đáng kể hơn là
metadata này phải đọc từ ổ đĩa và bộ nhớ chính trước
khi có thể tìm kiếm. Mặc dù không đáng kể trên quy mô
nhỏ, nhưng nếu với hệ thống có hàng tỷ hình ảnh và hàng
petabyte dữ liệu thì sẽ bị nghẽn cổ chai khi thường xuyên
phải đọc ghi. Chúng tôi thấy đây là vấn đề chính trong
việc sử dụng NAS (Network Attached Storage). Một vài
thao tác ổ đĩa để đọc một bức ảnh duy nhất: một (hoặc
thường là nhiều hơn) để chuyển đổi tên tập tin sang một
số inode, một thao tác khác để đọc inode từ ổ đĩa, và cuối
cùng có một thao tác đọc chính tệp tin đó. Nói ngắn gọn,
việc đọc metadata từ ổ đĩa làm giới hạn thông lượng của
chúng tôi. Trên thực tế, vấn đề này đã làm tốn thêm chi
phí vì chúng tôi phải thuê ngoài các CDN để lưu trữ file,
ví dụ như sử dụng CDN của Akamai để phục vụ các truy
vấn đọc.
Trên đây là nhược điểm của hệ thống lưu trữ truyền
thống, chúng tôi đã thiết kế Haystack để đạt được bốn
mục đích chính sau:
Thông lượng cao và độ trễ thấp. Hệ thống lưu trữ
hình ảnh của chúng tôi phải theo kịp được với lượng truy
vấn từ người dùng. Khi lượng truy vấn vượt quá khả năng
xử lý của chúng tôi thì hoặc là bỏ qua, điều này không
được chấp nhận đối với trải nghiệm người dùng hoặc là
được xử lý bởi một CDN, rất tốn kém. Hơn nữa, các hình
ảnh nên được phục vụ nhanh nhất có thể để mang lại
một trải nghiệm tốt cho người dùng. Haystack đạt được
thông lượng cao và độ trễ giảm vì yêu cầu tối đa một lần
đọc ổ đĩa cho một truy vấn. Để làm được điều này, chúng
tôi quản lý tất cả các metadata trên bộ nhớ chính, điều
này giúp giảm đáng kể chi phí tìm kiếm một ảnh từ ổ đĩa
nhờ đọc metadata.
Chịu lỗi. Trong các hệ thống quy mô lớn, lỗi xuất
hiện hàng ngày. Hình ảnh là một phần không thể thiếu
đối với người dùng, không nên gặp lỗi dù không tránh
khỏi các tai nạn máy chủ và lỗi ổ cứng. Nó có thể xuất
hiện trong trường hợp trung tâm dữ liệu bị mất điện,
hoặc đường mạng giữa các quốc gia bị đứt. Haystack sao
lưu mỗi ảnh tại các vị trí địa lý khác biệt. Nếu chúng ta
mất một máy chủ, thì đã có một cái khác thay thế, sao
chép dữ liệu nếu cần.
1

2. Chi phí hiệu quả Haystack hoạt động tốt hơn và
tốn ít chi phí hơn hướng tiếp cận dựa trên NFS cũ. Chúng
tôi định lượng được việc tiết kiệm chi phí xuất phát từ 2
hướng: chi phí trên một terabyte lưu trữ sử dụng được
và tỉ lệ đọc được chuẩn hoá theo mỗi terabyte1
. Trong
Haystack, mỗi chi phí sử dụng terabyte ít hơn 28% và
tiến trình đọc trên một giây nhiều hơn 4 lần so với cách
sử dụng NAS.
Đơn giản. Haystack là một hệ thống mới, chưa có
nhiều thời gian để kiểm chứng, chúng tôi đặc biệt chú
ý đến sự đơn giản. Điều này giúp chúng tôi triển khai
hệ thống làm việc được trong vòng vài tháng thay vì vài
năm. Haystack có 3 đóng góp chính là:
• Haystack, một hệ thống lưu trữ đối tượng được tối ưu
cho việc lưu trữ hiệu quả và phục vụ truy xuất hàng
tỉ bức ảnh .
• Các bài học thu được trong việc xây dựng và mở rộng
hệ thống lưu trữ ảnh không tốn kém, đáng tin cậy và
có sẵn.
• Một đặc trưng của của những truy vấn để tạo lên ứng
dụng chia sẻ ảnh - Facebook.
Phần còn lại của bài báo này được tổ chức theo các
phần sau: Phần 2 cung cấp kiến thức nền tảng và những
thách thức nổi bật trong kiến trúc trước đây của chúng
tôi. Phần 3 mô tả về thiết kế và triển khai của Haystack.
Trong phần 4 sẽ nói về các công việc đọc, ghi hình ảnh,
phần này sẽ thể hiện được mục tiêu thiết kế Haystack.
Chúng tôi thực hiện các so sánh trong phần 5 và kết luận
của bài báo trong phần. 6.
2 Cơ sở và thiết kế trước đây
Trong phần này, chúng tôi sẽ mô tả kiến trúc của hệ thống
đã tồn tại trước Haystack và các bài học kinh nghiệm nổi
bật chúng tôi học được.
2.1 Cơ sở
Chúng ta bắt đầu với tóm lược tổng quan về thiết kế cho
các máy chủ web, content delivery networks (CDN) và hệ
thống lưu trữ tương tác để phục vụ những hình ảnh trên
một website phổ biến. Hình 1 mô tả các bước từ khi người
dùng ghé thăm một website có chứa một hình ảnh cho
tới khi họ tải nó xuống ổ đĩa máy tính. Khi truy cập vào
website, đầu tiên trình duyệt sẽ gửi một HTTP request tới
máy chủ web để lấy các nội dung hiển trị lên trình duyệt.
Với mỗi hình ảnh, máy chủ web xây dựng lên 1 url để trình
duyệt có thể tải nó về. Hầu hết các website phổ biến thì
URL thường trỏ tới một CDN. Nếu CDN đang lưu tạm
hình ảnh này trên cache thì nó sẽ được trả về ngay lập
1Có tính đến dung lượng tài khoản được tiêu thụ bởi các yếu tố
như cấp độ RAID, sao chép, và hệ thống tập tin cơ bản
Hình 1: Thiết kế phổ biến.
tức. Nếu không, CDN kiểm tra URL này xem có đủ thông
tin để lấy hình ảnh từ hệ thống lưu trữ của site. Sau đó,
CDN sẽ cập nhật hình ảnh này vào cache và gửi ảnh về
cho trình duyệt của người dùng.
2.2 Thiết kế cơ sở của NFS
Trong thiết kế đầu tiên, chúng tôi đã triển khai hệ thống
lưu trữ hình ảnh dựa trên hướng tiếp cập theo NFS. Bài
học chính mà chúng tôi đã học được từ các CDN là chúng
không cung cấp giải pháp thực tiễn để phục vụ các hình
ảnh trên một mạng xã hội. Các CDN làm việc hiệu quả
khi phục vụ các hình ảnh hót nhất như hình trang cá nhân
hay các ảnh mới tải lên gần đây. Nhưng với một mạng xã
hội như Facebook cũng cần phục vụ một lượng lớn các
hình ảnh kém phổ biến hơn. Ví dụ như hình ảnh của một
số tài khoản không thường xuyên đăng nhập. Những hình
ảnh này tốn đáng kể lưu lượng truy cập của chúng tôi, hầu
hết chúng phải truy cập trở lại máy chủ lưu trữ sau khi
không tìm thấy ở các CDN. Trong khi nó sẽ rất tiện lợi
khi được lưu trữ trên cache nhưng sẽ rất tốn kém vì yêu
cầu kích thước cache rất lớn.
Thiết kế dựa trên NFS lưu trữ mỗi hình ảnh thành một
file trong tập hợp các ứng dụng NAS thương mại. Một tập
hợp các máy, Photo Store Server, sau đó tất cả các volume
được xuất ra bởi ứng dụng NAS thông qua NFS. Hình 2
thể hiện kiến trúc và thể hiện các máy Photo Store server
xử lý các request HTTP cho hình ảnh. Từ một URL hình
ảnh, máy chỉ Photo Store giải nén volume và đường dẫn
đầy đủ tới file, đọc dữ liệu thông qua NFS và trả về kết
quả cho CDN.
Chúng tôi khởi tạo ban đầu lưu trữ hàng ngàn file trong
mỗi thư mục của một NFS volume. Dẫn đến việc ổ đĩa phải
hoạt động quá nhiều cho dù chỉ đọc 1 hình ảnh. Nguyên
nhân do cách NAS quản lý metadata của thư mục, đặt
hàng ngàn file trong một thư mục là vô cùng kém hiệu
quả. Hậu quả là, nó cần nhiều hơn 10 hoạt động ổ đĩa để
lấy về được một hình ảnh. Sau khi giảm thiểu kích thước
thư mục xuống hàng trăm hình ảnh trong một thư mục,
kết quả là hệ thống vẫn cần khoảng 3 hoạt động ổ đĩa để
2

3. Hình 2: Thiết kế trên NFS
lấy về được một hình ảnh: thứ nhất là đọc metadata của
thư mục trên bộ nhớ chính, thứ hai là tải inode lên bộ nhớ
chính, và thứ 3 là đọc nội dung file.
Để giảm thiểu nhiều hơn nữa hoạt động đọc ổ đĩa, chúng
tôi thêm cache cho các máy chủ Photo Store để quản lý file
trả về từ NAS. Khi đọc file lần đầu tiên, máy chủ Photo
Store mở file như bình thường, nhưng đồng thời cũng lưu
cache tên file để file-handle ánh xạ trong memcache[18].
Khi yêu cầu một file, máy chủ Photo Store mở file trực
tiếp sử dụng một lời gọi hệ thống open-by-filehandle. Một
lập luận cho rằng, hướng tiếp cận mà tất cả các file-handle
được lưu trữ trong memcache có thể là một giải pháp khả
thi. Tuy nhiên nó chỉ giải quyết được một phần vấn đề
giống như việc tất cả các ứng dụng NAS lưu trữ inode
trên bộ nhớ chính. Một yêu cầu đắt đỏ cho hệ thống file
truyền thống. Chúng tôi đã học được bài học từ hướng
tiếp cận theo NAS chỉ tập chung vào việc lưu cache. liệu
rằng cache của ứng dụng NAS hay một cache bên ngoài
như memcache thì sẽ giảm thiểu được hoạt động của ổ đĩa.
Hệ thống lưu trữ kết thúc việc xử lý các yêu cầu đối với
hình ảnh kém phổ biến hơn, không được lưu trên CDN và
không tìm thấy trong cache.
2.3 Thảo luận
Rất khó cho chúng tôi để tóm lược những hướng dẫn khi
nào nên hay không nên xây dựng một hệ thống lưu trữ
tùy biến. Tuy nhiên, chúng tôi tin rằng nó sẽ hữu ích cho
cộng đồng có cái nhìn sâu sắc về việc tại sao chúng tôi
quyết định xây dựng Haystack.
Phải đối mặt với việc quá tải trong thiết kế dựa theo
NFS. Chúng tôi đã khám phá liệu sẽ rất hữu ích khi xây
dựng một hệ thống tương tự như GFS [9]. Vì chúng tôi
lưu trữ hầu hết dữ liệu người dùng người dùng của chúng
tôi trong cơ sở dữ liệu MySQL. Các công cụ NAS cung
cấp giải pháp giá cả rất tốt và hiệu năng cao cho công
việc phát triển và dữ liệu log. Hơn nữa chúng tôi tận dụng
Hadoop cho các dữ liệu log cực kỳ lớn. Phục vụ các yêu
cầu hình ảnh đã lâu không được truy cập là một vấn đề
mà cả MySQL, NAS hay Hadoop đều không phù hợp.
3 Thiết kế và triển khai
Facebook sử dụng một server CDN để lưu trữ những hình
ảnh phổ biến và hỗ trợ Haystack trả về những hình ảnh
người dùng yêu cầu một cách hiệu quả. Thông thường,
CDN được dùng để giải quyết vấn đề quá tải của một
website khi có quá nhiều các truy vấn đến các nội dung
tĩnh như hình ảnh hoặc file css. . . Theo hướng tiếp cận
truyền thống thì hệ thống Facebook sẽ phải lưu trữ một
lượng rất lớn các file tĩnh tại CDN điều này là không hợp
lý.
Cần phải hiểu rằng, trong tương lai gần thì những CDN
sẽ không giải quyết được hết các vấn đề của chúng tôi,
chúng tôi đã thiết kế ra Haystack để giải quyết vấn đề
nghẽn cổ chai trong hoạt động đọc ghi ổ đĩa dựa trên NFS
của chúng tôi. Chúng tôi chấp nhận những truy vấn tới
các hình ảnh kém phổ biến sẽ cần đọc trực tiếp từ ổ đĩa,
nhưng mục đích chính là để hạn chế số hoạt động như vậy,
chỉ cần một lần đọc duy nhất từ ổ đĩa cho mỗi bức ảnh
khi cần. Haystack đạt được mục tiêu này vì đã giảm đáng
kể bộ nhớ cần sử dụng cho việc lưu trữ metadata của hệ
thống file. Tất cả các metadata sẽ được lưu trữ tại bộ nhớ
chính.
Haystack lưu trữ nhiều hình ảnh trong một file duy nhất
vì thế những file sẽ có kích thước rất lớn. Nhưng hướng
tiếp cận này hiệu quả đáng kể. Hơn thế, chính việc lưu
trữ đơn giản này là điểm mạnh của nó, dễ triển khai cài
đặt. Bây giờ, chúng ta cùng thảo luận về công nghệ cốt
lõi và các thành phần kiến trúc xung quanh một hệ thống
lưu trữ đáng tin cậy. Với Haystack chúng ta cần phân biệt
hai loại metadata. Application metadata miêu tả thông tin
cần để cấu trúc một URL mà trình duyệt có thể sử dụng
để lấy hình ảnh về. Filesystem metadata để định danh dữ
liệu cần thiết cho một máy chủ khi cần lấy về hình ảnh
nằm trên ổ đĩa của máy chủ đó.
3.1 Tổng quan
Kiến trúc của Haystack gồm 3 thành phần cốt lõi:
Haystack Store, Haystack Directory và Haystack Cache.
Haystack Store là hệ thống vật lý lưu trữ ảnh và quản lý
Filesystem metadata cho hình ảnh. Chúng tôi tổ chức sức
chứa của các Store theo các volume vật lý. Ví dụ, chúng
ta có thể tổ chức một máy chủ có khả năng lưu trữ 10
terabytes thành 100 volume vật lý trong đó mỗi volume
có thể lưu trữ được 100 gigabyte. Chúng tôi còn nhóm
các volume vật lý trên các máy khác nhau thành các logi-
cal volume. Khi Haystack lưu trữ một hình ảnh trên một
logical volume, hình ảnh này sẽ được ghi lên tất cả các
volume vật lý tương ứng. Sự dư thừa này nhằm giảm mất
3

4. Hình 3: Serving a photo
mát dữ liệu khi ổ địa bị lỗi hoặc hỏng. Haystack Direc-
tory quản lý ánh xạ giữa volume logic và volume vật lý
cùng với các application metadata khác. Chẳng hạn như
quản lý số volume đã dùng và còn trống. Chức năng của
Haystack Cache giống như là một CDN nội bộ, nơi lưu trữ
tạm các bức ảnh phổ biến nhất và cung cấp cơ chế backup
cho CDN khi gặp lỗi.
Hình 3 miêu tả các thành phần Haystack Store, Direc-
tory, Cache kết hợp với nhau để phục vụ truy vấn từ trình
duyệt của người dùng. Trong kiến trúc của Haystack, trình
duyệt có thể trực tiếp truy vấn đến cả CDN hoặc Cache.
Chú ý rằng, về bản chất thì Cache cũng chính là một CDN,
để tránh nhầm lẫn chúng tôi sử dụng ‘CDN’ cho hệ thống
nằm bên ngoài kiến trúc Haystack và ‘Cache’ để miêu tả
cái nằm trên trong kiến trúc Haystack để lưu hình ảnh
tạm thời. Cache nội bộ nhằm mục đích giảm thiểu sự phụ
thuộc vào các CDN bên ngoài.
Khi một người dùng vào xem một trang web, máy chủ
Web Server sẽ sử dụng Directory để xây dựng lên một
URL cho mỗi bức ảnh. URL này chứa một vài thông tin
mà mỗi thông tin đó sẽ tương ứng với tuần tự các bước từ
khi trình duyệt của người dùng truy vấn đến CDN (hoặc
Cache) để lấy về hình ảnh từ một máy nào đó trong hệ
thống Haystack Store. Một URL chuyển hướng truy vấn
tới CDN thì có cấu trúc như sau:
http://(CDN)/(Cache)/(Machine id)/(Logical
volume, Photo)
Phần đầu tiên của URL xác định CDN nào để truy vấn
hình ảnh. CDN có thể tìm kiếm hình ảnh đó bằng cách chỉ
cần sử dụng phần cuối cùng của URL: volume logic và id
của ảnh. Nếu CDN không tìm thấy ảnh, thì CDN sẽ hỏi
sang Cache. Tương tự, Cache cũng sẽ tìm kiếm hình ảnh
đó, nếu không thấy Cache sẽ truy vấn trực tiếp vào một
máy cụ thể trong Haystack Store.
Hình 4 minh hoạ việc tải lên Haystack một hình ảnh
Hình 4: Uploading a photo
mới. Khi một người dùng tải lên một hình ảnh, đầu tiên
họ gửi dữ liệu tới máy chủ Web Server. Tiếp theo, máy chủ
gửi yêu cầu đến Directory để kiểm tra xem volume logic
có thể ghi hay không. Cuối cùng, Web Server chỉ định một
id duy nhất cho ảnh và tải nó lên volume vật lý được ánh
xạ với volume logic đã được đăng ký trước đó.
3.2 Haystack Directory
Haystack Directory (Directory) đảm nhiệm bốn chức năng
chính. Đầu tiên, nó cung cấp một ánh xạ từ các volume
logic tới volume vật lý. Các máy chủ web sẽ sử dụng ánh xạ
này khi tải lên hình ảnh mới và khi cần xây tạo ra URL
cho mỗi bức ảnh mà trang web đang yêu cầu. Thứ hai,
Directory cân bằng tải khi có nhiều yêu cầu ghi vào các
volume logic và đọc ở các volume vật lý. Thứ ba, Directory
xác định xem một bức ảnh đang yêu cầu thì nên được quản
lý bởi CDN hay Cache. Chức năng này cho phép chúng
tôi điều chỉnh được sự phụ thuộc vào các CDN. Thứ tư,
Directory xác định những volume logic chỉ có thể đọc khi
nó đã đầy hoặc vì lý do nào đó trong quá trình vận hành.
Khi chúng ta tăng thêm sức chứa cho Haystack Store
(Store) bằng cách thêm các máy vật lý mới, những máy
này sẽ có trạng thái là có thể ghi; chỉ những máy có thể
ghi mới được nhận ảnh tải lên. Qua thời gian sử dụng,
không gian lưu trữ còn trống của những máy này giảm
xuống. Khi một máy không còn trống thì chúng ta đánh
dấu nó là chỉ-đọc. Trong phần tiếp theo, chúng ta sẽ thảo
luận về sự khác nhau này và ảnh hướng của nó đến Cache
và Store.
Directory lưu trữ thông tin của nó trong một cơ sở dữ
liệu đã được sao lưu và truy cập thông qua một giao diện
PHP sử dụng memcache để giảm độ trễ. Trong trường hợp
chúng ta làm mất dữ liệu trên một máy vật lý, chúng ta
xoá ánh xạ tương ứng với nó và thêm lại khi một máy vật
4

5. lý mới được thêm vào.
3.3 Haystack Cache
Cache nhận các lượt truy vấn HTTP cho các hình ảnh từ
CDN và cũng có thể nhận trực tiếp từ trình duyệt của
người dùng. Chúng tôi tổ chức Cache giống như một bảng
băm phân tán và sử dụng id của ảnh làm key để lưu dữ
liệu trong cache. Nếu Cache không chứa ảnh cần tìm, thì
nó sẽ lấy từ các máy vật lý dựa theo id có trong URL của
truy vấn đồng thời cũng trả về cho cả CDN và trình duyệt
của người dùng.
Bây giờ chúng ta làm nổi bật đặc điểm quan trọng của
Cache. Nó lưu tạm hình ảnh khi một trong hai điều kiện
sau xảy ra: (a) truy vấn đến trực tiếp từ người dùng và
không qua CDN, (b) hình ảnh được lấy từ một máy vật
lý có trạng thái có-thể-ghi. Để biện hộ cho điều kiện đầu
tiên, đó là kinh nghiệm của chúng tôi với thiết kế dựa trên
NFS, việc lưu tạm trên CDN là không hiệu quả, nó không
phải là truy vấn không tìm thấy ảnh ở CDN thì chuyển
sang Cache. Nguyên nhân cho điều kiện thứ 2 là gián tiếp.
Chúng ta sử dụng Cache để hỗ trợ cho các máy vật lý vì
hai điều thú vị sau: các hình ảnh được xem nhiều nhất
khi người dùng vừa tải chúng lên và các hệ thống tập tin
hoạt động tốt hơn khi làm một trong hai việc đọc hoặc
ghi nhưng không đồng thời cả hai (Phần 4.1). Như vậy,
các máy lưu trữ vật lý (Store) sẽ phải xử lý tất cả các lần
đọc nếu không có Cache. Với đặc điểm này, để tối ưu hoá
chúng tôi lên kế hoạch triển khai chủ động đẩy các hình
ảnh được tải lên gần đây vào Cache và chúng ta kỳ vọng
nó sẽ được xem sớm và thường xuyên.
3.4 Haystack Store
Các lần đọc tạo ra truy vấn rất đầy đủ và cụ thể về một
hình ảnh với id của volume logic và từ một máy lưu trữ
vật lý cụ thể. Máy này trả về đúng hình ảnh nếu nó tìm
thấy. Nếu không, nó sẽ trả về lỗi.
Mỗi máy lưu trữ quản lý nhiều volume vật lý. Mỗi vol-
ume chứa hàng triệu hình ảnh. Ta có thể tưởng tượng về
volume vật lý giống như một tập tin rất lớn (100 GB)
được lưu theo đường dẫn giống như ’/hay/haystack <log-
ical volume id>’. Một máy lưu trữ có thể truy cập hình
ảnh nhanh bằng cách chỉ cần dùng id của volume logic
tương ứng và địa chỉ tương đối của bức ảnh trên volume
đó. Điều này này là chìa khoá của thiết kế Haystack: nhận
tên file, địa chỉ tương đối (offset), và kích thước cụ thể
của ảnh mà không cần phải đọc trực tiếp từ ổ đĩa. Một
máy lưu trữ giữ metadata cho mỗi volume vật lý mà nó
quản lý và cũng duy trì một bảng ánh xạ từ id ảnh tới
metadata (mô tả tệp tin, địa chỉ tương đối và kích thước
theo byte) của hệ thống tệp tin nằm trên bộ nhớ chính.
Bây giờ chúng ta mô tả các lớp của mỗi volume vật
lý, làm sao để đưa được ánh xạ lên bộ nhớ chính từ các
volume. Một máy lưu trữ đại diện cho một volume vật
lý giống như một tệp tin lớn chứa một khối đặc biệt (su-
perblock) có các cây kim (needles) nằm tuần tự nhau. Mỗi
Hình 5: Cách bố trí Haystack Store file
Trường Mô tả
Header Magic number used for recov-
ery
Cookie Random number to mitigate
brute force lookups
Key 64-bit photo id
Alternate key 32-bit supplemental id
Flags Signifies deleted status
Size Data size
Data The actual photo data
Footer Magic number for recovery
Data Checksum Used to check integrity
Padding Total needle size is aligned to
8 bytes
Bảng 1: Mô tả các trường trong một needle
needles đại diện cho một ảnh được lưu trong Haystack.
Hình 5 mô tả một tệp volume và định dạng cho mỗi nee-
dle. Bảng 1 mô tả các trường của mỗi needle.
Để lấy về các needle một cách nhanh chóng, mỗi máy
lưu trữ duy trì một cấu trúc dữ liệu trên bộ nhớ RAM cho
mỗi volume. Cấu trúc dữ liệu này ánh xạ các cặp (key,
alternate key)2
tới các cờ needle tương ứng, kích thước
theo byte, và địa chỉ tương đối của volume.Trong trường
hợp máy lưu trữ gặp sự cố. nó có thể tái cấu trúc bảng
ánh xạ này trực tiếp từ tập tin volume trước khi xử lý
truy vấn. Bây giờ chúng ta mô tả cách mà một máy lưu
trữ quản lý các volume bằng bảng ánh xạ nằm trên RAM
để phục vụ và yêu cầu đọc, ghi, và xoá ảnh.
2Id của ảnh tương ứng với khoá chính trong khi đó Type được sử
dụng cho khóa thay thế. Trong quá trình tải lên, máy chủ web chia
tỷ lệ mỗi ảnh thành bốn kích cỡ khác nhau (hoặc loại) và lưu trữ
chúng dưới dạng các needle riêng biệt, nhưng có cùng một khóa. Sự
phân biệt quan trọng giữa các needle này là trường then chốt thay
thế, theo thứ tự giảm dần có thể là ’n’, ’a’, ’s, hoặc ’t’.
5

6. 3.4.1 Đọc hình ảnh
Khi Cache yêu cầu một hình ảnh, nó cung cấp các thông
tin cần thiết như id của volume logic, key, alternate key,
và cookie của máy lưu trữ. Cookie là một số nhúng trong
URL của hình ảnh. Giá trị của cookie được sinh ngẫu
nhiên và lưu ở hệ thống Directory tại thời điểm hình ảnh
được tải lên. Cookie rất hiệu quả trong việc tránh các cuộc
tấn công dựa trên việc đoán các URL hợp lệ cho ảnh.
Khi một máy lưu trữ (Store) nhận một yêu cầu hình
ảnh từ Cache, máy lưu trữ tìm kiếm metadata liên quan
trong ánh xạ trên bộ nhớ chính. Nếu ảnh chưa bị xoá, máy
lưu trữ sẽ tìm địa chỉ tương đối trên tập tin volume sau
đó đọc needle từ ổ đĩa, xác định cookie và tính toán vẹn
của dữ liệu. Nếu các điều kiện đều thoả mãn, máy lưu trữ
sẽ trả về ảnh cho Cache.
3.4.2 Ghi hình ảnh
Khi tải một ảnh lên Haystack máy chủ sẽ cung cấp id của
volume logic, key, alternate key, cookie, và dữ liệu cho máy
lưu trữ. Máy lưu trữ sẽ thêm ảnh vào cuối tập tin volume
vật lý và cập nhật bảng ánh xạ trên bộ nhớ chính nếu cần.
Mặc dù đơn giản nhưng việc chỉ thêm vào cuối tập tin sẽ
làm phức tạp một số thao tác sửa đổi ảnh như xoay ảnh
chẳng hạn. Haystack không cho phép ghi đè lên needle,
ảnh chỉ có thể sửa bằng cách tải lên ảnh mới với cùng key
và alternate key. Nếu một needle mới được ghi tại một
volume logic khác, thì Directory sẽ cập nhật application
metadata của nó và những truy vấn trong tương lai sẽ
không bao giờ lấy được ảnh cũ. Nếu needle mới được ghi
lên cùng volume logic, thì máy lưu trữ sẽ thêm needle mới
vào cuối cùng volume vật lý tương ứng. Haystack phân
biệt các needle bị lặp lại dựa trên địa chỉ tương đối của
chúng. Needle được chập nhận là needle có địa chỉ tương
đối lớn nhất.
3.4.3 Xóa hình ảnh
Việc xoá một ảnh rất minh bạch. Máy chủ lưu trữ thiết
lập cờ delete trong cả bảng ánh xạ trên bộ nhớ chính và
đồng bộ với tập tin volume. Nếu có một truy vấn tới ảnh
đã xoá, đầu tiên sẽ kiểm tra cờ delete trong bộ nhớ và trả
về lỗi nếu cờ delete được thiết lập. Cần chú ý rằng, không
gian lưu trữ bị chếm bởi các needle đã xoá được lấy lại
bằng cách nén lại tập tin volume.
3.4.4 Index File
Máy lưu trữ sử dụng một giải pháp tối ưu hoá quan trọng
là index file . Theo lý thuyết, một máy tính có thể tái cấu
trúc các bảng ánh xạ trên bộ nhớ bằng cách đọc tất cả
các volume vật lý. Nếu làm vậy thì sẽ rất mất thời gian
khi lượng dữ liệu lên tới hàng terabyte. Đánh chỉ mục file
cho phép máy lưu trữ xây dựng các bảng ánh xạ trên bộ
nhớ một cách nhanh chóng, rút ngắn thời gian khởi động
lại.
Hình 6: Cách bố trí của Haystack Index file
Máy lưu trữ duy trì một file chỉ mục cho mỗi volume.
File chỉ mục này như một trạm kiểm soát có cấu trúc
dữ liệu trên bộ nhớ được sử dụng để cấp phát các needle
hiệu quả trên ổ đĩa. Một tầng file chỉ mục giống như một
volume file, việc chứa một supperblock được cho phép bởi
các bản ghi chỉ mục tuần tự tương ứng với mỗi needle
trong supperblock. Những bản nghi này phải xuất hiện
theo thứ tự tương ứng với các needle xuất hiện trong file
volume. Hình 6 thể hiện một tầng của file chỉ mục và Bảng
2 giải thích các trường khác nhau trên mỗi bản ghi.
Khởi động lại bằng cách sử dụng chỉ mục phức tạp hơn
một chút hơn là chỉ đọc các chỉ số và khởi tạo các ánh xạ
trong bộ nhớ. Có nhiều vấn đề phát sinh, vì chỉ mục được
cập nhất bất đồng bộ, có nghĩa là chỉ mục có thể bị dã bị
cũ hơn so với thực tế. Khi chúng ta ghi một ảnh mới, máy
lưu trữ đồng bộ và thêm một needle vào cuối volume đồng
thời cũng đồng bộ thêm một bản ghi vào index. Khi chúng
ta xoá hình ảnh, máy lưu trữ đồng bộ thiết lập các cờ của
ảnh mà không thực hiện cập nhật vào index. Những thiết
kế đó quyết định cho phép ghi và xoá nhanh hơn, bời vì
chúng tránh được việc phải đồng bộ thao tác ghi ổ đĩa.
Chúng cũng gây ra tác dụng phụ như là: các needle có thể
tồn tại mà không tương ứng với một bản ghi index nào và
các bản ghi index không thể hiện được ảnh nào đã xoá.
Chúng ta coi những needle mà không tương tứng với một
Field Explanation
Key 64-bit key
Alternate key 32-bit alternate key
Flags Currently unused
Offset Needle offset in the Haystack
Store
Size Needle data size
Bảng 2: Mô tả các trường in index file
bản ghi index nào là một orphans. Trong quá trình khởi
động lại, máy lưu trữ sẽ tuần tự kiểm tra các orphans, so
khớp với bản ghi index, và thêm vào cuối file chỉ mục. Chú
ý rằng chúng ta có thể nhanh chóng xác định được orphan
bởi vì bản ghi cuối cùng trong chỉ mục tương ứng với non-
6

7. orphan needle cuối cùng trong volume file. Để hoàn thành
việc khởi động lại, máy chủ Store bây giờ khởi tạo một
ánh xạ trên bộ nhớ chỉ cần sử dụng file index.
Vì các bản ghi chỉ mục không phản ảnh các ảnh đã xóa,
một Máy lưu trữ có thể tìm kiếm một bức ảnh trên thực
tế đã bị xóa. Để xử lý vấn đề này, sau khi một máy chủ
Store đọc toàn bộ needle cho một bức ảnh sau đó kiểm tra
cờ bị xóa. Nếu một needle được đánh dấu là deleted thì
máy chủ Store sẽ cập nhật vào bảng ánh xạ trên bộ nhớ
theo như vậy và thông báo cho Cache rằng đối tượng đó
không tìm thấy.
3.4.5 Hệ thống file
Chúng tôi mô tả Haystack như là một hệ lưu trữ đối tượng
sử dụng hệ thống file giống như Unix. Nhưng một số hệ
thống tập tin phù hợp hơn với Haystack so với những hệ
thống khác. Trong thực tế, các máy lưu trữ nên sử dụng
một hệ thống tập tin không cần quá nhiều bộ nhớ để có
thể thực hiện tìm kiếm ngẫu nhiên file kích thước lớn một
cách nhanh chóng. Hiện tại, mỗi máy lưu trữ sử dụng
XFS[24] - một hệ thống tập tin dựa trên phạm vi. XFS có
hai lợi thế chính cho Haystack. Thứ nhất, các block maps
cho các tập tin lớn liền kề đủ nhỏ để được lưu trữ trong
bộ nhớ chính. Thứ hai, XFS cung cấp sự phân bổ tập tin
hiệu quả, chống phân mảnh và kiềm chế các block maps
lớn hơn.
Việc sử dụng XFS giúp Haystack có thể loại bỏ các hoạt
động ổ đĩa cho việc đọc metadata của hệ thống tập tin khi
có truy vấn đọc hình ảnh. Tuy nhiên, lợi ích này không
ngụ ý rằng Haystack có thể đảm bảo mỗi bức ảnh được
đọc sẽ phải chịu chính xác một hoạt động ổ đĩa. Có các
trường hợp, trong đó hệ thống tập tin yêu cầu nhiều hơn
một thao tác ổ đĩa khi dữ liệu ảnh dữ liệu vượt qua phạm
vi mở rộng hoặc RAID. Haystack cấp phát trước khoảng
1 gigabyte và sử dụng 256 kilobyte RAID để đáp ứng tình
huống trong thực tế khi chúng ta gặp phải những trường
hợp này.
3.5 Phục hồi từ lỗi
Giống như nhiều hệ thống quy mô lớn khác chạy trên
phần cứng thương mại [5, 4, 9], Haystack cần phải chịu
được một loạt các lỗi: ổ đĩa cứng bị hỏng, bộ điều khiển
RAID không hoạt động, bo mạch chủ kém, v.v ... Chúng
tôi sử dụng hai kỹ thuật tiên tiến để chịu lỗi - một cái để
phát hiện và một cái để sửa chữa.
Để chủ động tìm các máy lưu trữ đang có vấn đề, chúng
tôi duy trì một nhiệm vụ chạy nền, được gọi là pitchfork
định kỳ kiểm tra sức khỏe của mỗi máy lưu trữ. Pitchfork
thực hiện các bài kiểm tra từ xa kết nối tới mỗi máy lưu
trữ, kiểm tra sự sẵn có của mỗi volume, và có gắng đọc
dữ liệu từ máy lưu trữ. Nếu pitchfork xác định rằng một
máy Store bị lỗi nó sẽ tự động đánh các volumn logic trên
máy này là chỉ có thể đọc. Chúng tôi tiến hành kiểm tra
offline để tìm nguyên nhân lỗi.
Sau khi được chẩn đoán, chúng tôi có thể khắc phục
được vấn đề một cách nhanh chóng. Thỉnh thoảng, tình
huống đòi hỏi phải có một hoạt động đồng bộ hóa số lượng
lớn hơn (bulk sync), khi đó chúng tôi đặt lại dữ liệu của
máy lưu trữ sử dụng các volume được cung cấp bởi một
bản sao. Đồng bộ hoá số lượng lớn hiếm khi xảy ra (vài
tháng một lần) và rất đơn giản mặc dù tiến độ rất chậm.
Các nút cổ chai chính là số lượng dữ liệu được đồng bộ
hóa lớn thường được các đơn yêu cầu cường độ lớn hơn
tốc độ của NIC trên mỗi máy lưu trữ, kết quả là phải tốn
hàng giờ để phục hồi. Chúng tôi đang tích cực tìm hiểu
các kỹ thuật để giải quyết hạn chế này.
3.6 Tối ưu hóa
Bây giờ chúng ta thảo luận về một số tối ưu hóa quan
trọng cho sự thành công của Haystack.
3.6.1 Nén và tối ưu không gian lưu trữ
Compaction là hoạt động trực tuyến để thu hồi lại không
gian lưu trữ được sử dụng bởi các needle có cờ deleted hoặc
các needle trùng nhau (needle với cùng key và alternate
key). Một máy lưu trữ thực hiện nén volume bằng cách
sao chép các needle vào một tập tin mới trong khi bỏ qua
tất cả needle trùng lặp hoặc đã gán cờ xóa. Khi hoạt động
này đến cuối tệp tin, nó sẽ khóa bất kì thao tác chỉnh sửa
trên volume, xáo trộn các thành phần của file và cấu trúc
trong bộ nhớ.
Chúng tôi sử dụng việc nén này để giải phóng không
gian lưu trữ từ các ảnh đã xóa. Tần xuất xóa tương tự
như chế độ xem ảnh: Những bức ảnh mới sẽ có nhiều khả
năng bị xóa cao hơn, khoảng 25% các bức ảnh sẽ bị xóa.
3.6.2 Tiết kiệm bộ nhớ nhiều hơn
Như được mô tả, một máy lưu trữ duy trì một cấu trúc dữ
liệu trên bộ nhớ bao gồm các cờ, nhưng hệ thống hiện tại
của chúng tôi chỉ sử dụng trường cờ để đánh dấu needle là
đã xóa hoặc chưa. Các giá trị offset của needle trong bảng
ánh xạ trên bộ nhớ cũng được thiết lập về 0 đối với hình
ảnh đã xóa. Ngoài ra, máy lưu trữ không duy trì lưu trữ
giá trị cookie trong bộ nhớ chính và thay vào sẽ kiểm tra
cookie sau khi đọc một needle từ ổ đĩa. Nhờ đó, các máy
lưu trữ đã giảm thiểu 20% chi phí cho bộ nhớ chính
Hiện tại, Haystack sử dụng trung bình 10 bytes bộ nhớ
chính cho một hình ảnh. Nhớ lại phân trước, mỗi ảnh tải
lên sẽ được lưu lại với 4 kích thước khác nhau và tất cả
có cùng key (64 bits), alternate keys khác nhau (32 bits),
do đó kích thước dữ liệu có sự khác nhau(16 bits). Ngoài
ra có khoảng 32 bytes phát sinh cho các bảng băm, xấp xỉ
2 byte trên một hình ảnh. Tổng cộng chi phí cho việc mở
rộng ảnh ra làm 4 kích thước là 40 byte. So sánh với cấu
trúc xfs-inode-t trong Linux là 536 byte.
3.6.3 Upload theo lô
Ổ đĩa hoạt động tốt hơn khi ghi liên tiếp các file lớn thay
vì ghi ngẫu nhiên các file nhỏ. Vì thế chúng cố gắng tải
7

8. Hình 7: Hàm phân phối tích lũy của số ảnh yêu cầu trong
một ngày được phân loại theo độ tuổi (thời gian kể từ khi
nó được tải lên).
lên đồng thời nhiều lô nhất có thể. Rất may là nhiều người
thường xuyên tải lên cả album ảnh thay vì từng ảnh đơn,
điều này mang lại nhiều lợi ích cho hoạt động xem các ảnh
trong cùng album.Chi tiết trong phần 4.
4 Đánh giá
Chúng tôi chia đánh giá thành bốn phần. Đầu tiên chúng
tôi mô tả các truy vấn xem ảnh trên Facebook. Trong
phần thứ hai và thứ ba chúng tôi trình bày hiệu quả của
Directory và Cache. Cuối cùng chúng tôi phân tích Store
hoạt động tốt như thế nào.
4.1 Đặc điểm của các truy vấn ảnh
Ảnh là một trong những loại nội dung chính mà người
dùng chia sẻ trên facebook. Người dùng tải lên hàng triệu
ảnh mỗi ngày và ảnh đã tải lên gần đây có xu hướng được
xem nhiều hơn các ảnh cũ. Hình 7 minh họa mức độ phổ
biến mỗi bức ảnh cũng như là tuổi của ảnh. Hình dạng
của biểu đồ bên dưới rất hữu ích để thảo luận điều gì thúc
đẩy truy vấn ảnh của Facebook.
4.1.1 Các đặc điểm của truy vấn ảnh
Có 2 tính năng chiếm 98% truy vấn ảnh của Facebook là
NewFeed và Albums. NewFeed hiển thị những nội dung
gần đầy mà bạn bè họ chia sẻ, còn tính năng album cho
phép người dùng duyệt qua những bức ảnh của bạn bè.
Họ có thể xem các ảnh đã tải lên gần đây và cũng có thể
duyệt tất cả các album cá nhân. Hình 7 cho thấy sự gia
tăng mạnh các yêu cầu cho các bức ảnh một vài ngày tuổi.
Các yêu cầu từ NewFeed tăng mạnh cho những bức ảnh
gần đây và giảm mạnh khoảng 2 ngày sau. Khi nhiều câu
Operations Daily Counts
Photos Uploaded ~120 Million
Haystack Photos Written ~1.44 Billion
Photos Viewed 80-100 Billion
[Thumbnails] 10.2 %
[Small] 84.4 %
[Medium] 0.2 %
[Large] 5.2 %
Haystack Photos Read 10 Billion
Bảng 3: Lưu lượng truy cập ảnh hàng ngày.
Hình 8: Khối lượng của các hoạt động multi-write gửi đến
9 máy Haystack Store khác nhau. Hình trên có 9 đường
khác nhau.
chuyện ngừng hiển thị trong NewFeed. Có 2 điểm nhấn
từ hình trên. Đầu tiên, lượng yêu cầu đọc các bức ảnh
mới gia tăng nhanh chóng đẫn đến việc sử dụng CDN và
Cache để lưu các nội dung phổ biến là rất hiệu quả. Thứ
hai, biểu đồ có phần đuôi dài chỉ ra rằng một số lượng yêu
cầu đáng kể không thể được phục vụ bởi cache.
4.1.2 Lưu lượng truy cập vào volume
Bảng 3 thể hiện lưu lượng truy cập vào các volume hình
ảnh của Facebook. Một hình ảnh sẽ được ghi 12 lần trong
hệ thống Haystack, vì nó được xử lý thành 4 loại kích
thước và lưu tại 3 vị trí khác nhau. Bảng cho thấy rằng
Haystack đáp ứng khoảng 10% trong tổng số yêu cầu ảnh
từ CDN. Quan sát thấy rằng hình ảnh nhỏ hơn chiếm
phần lớn ảnh đã xem. Đặc điểm này nhấn mạnh mong
muốn của chúng tôi để giảm thiểu metadata phát sinh.
Ngoài ra, việc đọc các hình ảnh nhỏ hơn rất dễ mang lại
trải nghiệm tồi nếu độ trễ tải ảnh lớn. Chúng tôi hiển thị
các hình ảnh lớn hơn trên NewFeed theo dạng Album, có
thể tìm nạp trước để ẩn đi độ trễ.
8

9. Hình 9: Tỷ lệ Cache hit đối với hình ảnh có thể được lưu
trữ trong Haystack Cache.
4.2 Haystack Directory
Haystack Directory cân bằng đọc và ghi giữa các máy lưu
trữ Haystack Store. Hình 8 miêu tả như mong đợi, chính
sách băm của Directory để phân tán việc đọc và ghi rất
hiệu quả. Mỗi máy Store chứa tập các hình ảnh khác nhau.
Theo đồ thị trên, các đường gần nhau gần như trùng nhau,
điều này cho thấy Directory cân bằng ghi rất hiệu quả.
4.3 Haystack Cache
Hình 9 cho thấy tỷ lệ Cache hit. Nhớ lại rằng, Cache chỉ
lưu trữ hình ảnh nếu nó được lưu tại máy Store write-
enabled. Đó là những hình ảnh gần đây có tỉ lệ Cache hit
khoảng 80%. Vì thế, Cache rất hiệu quả trong việc giảm
các truy vấn đọc đến máy Store
4.4 Haystack Store
Nhớ lại mục tiêu của hệ thống Haystack là phục vụ số
lượng truy vấn ảnh lớn với thông lượng cao và độ trễ thấp
mặc dù việc đọc gần như là ngẫu nhiên..
4.4.1 Thiết lập thử nghiệm
Chúng tôi triển khai các máy Store trên các lưỡi(blades)
lưu trữ thương mại. Loại cấu hình phần cứng của một
lưỡi lưu trữ 2U có 2 siêu luồng 4 lõi Intel Xeon CPUs, 48
GB bộ nhớ, một phần cứng raid controller với 256–512MB
NVRAM, và 12 x 1TB SATA ổ đĩa
Mỗi lưỡi lưu trữ có sức chứa khoảng 9TB, được cấu
hình giống như một phân vùng RAID-6 và được quản lý
bởi phần cứng RAID controller. RAID-6 cung cấp cung
cấp hiệu suất đọc tuyệt vời trong khi giữ chi phí lưu trữ
thấp. NVRAM của bộ điều khiển ghi trở lại cache làm
giảm nhẹ hiệu suất ghi đĩa của RAID-6. Từ kinh nghiệm
của chúng tôi cho thầy rằng việc lưu cache hình ảnh trên
máy Store thì không hiệu quả, chúng tôi chuẩn bị NVRAM
đủ để ghi. Chúng tôi cũng vô hiệu hóa cache của ổ đĩa để
đảm bảo nhất quán dữ liệu trong trường hợp bị crash hoặc
mất điện.
4.4.2 Điểm chuẩn hiệu năng
Chúng tôi đánh giá hiệu suất của một máy Store bằng
cách sử dụng hai điểm chuẩn: Randomio [22] và Haystress.
Randomio là một chương trình mã nguồn mở có đa luồng
đọc ghi ổ đĩa. Chúng tôi sử dụng để đo khả năng ghi của
thiết bị lưu trữ. Nó đọc ngẫu nhiên 64KB trực tiếp từ ổ
đĩa và báo cáo thông lượng bền vững tối đa. Chúng tôi sử
dụng Randomio để thành lập một đường cơ bản cho thông
lượng đọc một lần nữa nhờ đó chúng tôi có thể so sánh
các điểm đánh giá.
Haystress là một chương trình đa luồng được xây dựng
tùy biến, chúng tôi sử dụng để đánh giá các máy Store
cho các khối lượng công việc khác nhau. Nó giao tiếp với
máy Store bằng giao thức HTTP và truy cập tối đọc , ghi
với thông lượng tối đa mà máy Store có thể chịu được.
Haystress sinh ngẫu nhiên một tập hợp lớn các hình ảnh
giả để giảm ảnh hưởng của bộ nhớ cache của máy. Trong
bài báo này, chúng tôi sử dụng bảy Haystress khác nhau
để đánh giá máy Store.
Table 4 mô tả thông lượng đọc và ghi, kết hợp các độ
trễ mà một máy Store có thể duy trì theo điểm chuẩn của
chúng tôi. Workload A thực hiện đọc ngẫu nhiên đến hình
ảnh 64KB trên một máy lưu trữ với 201 Volume. Kết quả
chỉ ra rằng Haystack chuyển 85% thông lượng ghi của thiết
bị trong khi độ trễ phát sinh chỉ khoảng 17%.
Chúng tôi tính một chi phí của máy Store trên bốn yếu
tố: (a) nó chạy trên một hệ thống file thay vì truy cập
trực tiếp vào ổ đĩa, (b) ổ đĩa đọc một file lớn hơn 64KB
giống như thực tế một needle cần để đọc. (c) những hình
ảnh đã lưu trữ có thể không được liên kết với một thiết bị
RAID-6 nào. và (d) chi phí CPU của máy chủ Haystack
(index access, checksum calculations, etc.).
Trong workload B, một lần nữa chúng tôi kiểm tra khối
lượng công việc chỉ-đọc nhưng thay đổi 70% số lần đọc để
chúng yêu cầu hình ảnh kích thước nhỏ hơn (8KB thay
vì 64KB). Trong thực tế, chúng tôi thấy rằng hầu hết các
yêu cầu không phải là cho hình ảnh kích thước lớn nhất
mà là cho hình thu nhỏ và hình ảnh tiểu sử. Workloads C,
D, và E chỉ ra thông lượng ghi của một máy Store. Nhớ
lại rằng, Haystack có thể ghi theo lô.
Workloads C, D, và E nhóm 1,4, và 16 thao tác ghi vào
một multi-write. Bảng cho thấy rằng khấu hao chi phí cố
định của thao ghi trên 4 và 16 hình ảnh, cải thiện thông
qua lần lượt 30% và 78%. Theo dự kiến, điều này sẽ làm
giảm mỗi độ trễ ảnh.
Cuối cùng, chúng ta nhìn vào hiệu suất trong sự hiện
diện của cả hai hoạt động đọc và ghi. Workload F sử dụng
kết hợp 98% số lần đọc và 2% ghi trong khi G sử dụng
96% đọc và 4% multi-wite, trong đó mỗi chương trình
multi-write ghi 16 bức ảnh. Những tỷ lệ phản ánh những
gì thường được quan sát thấy trong production. Bảng cho
thấy rằng Store cung cấp thông lượng đọc cao ngay cả khi
9

10. Reads Writes
Benchmark Config # Operations Thoughput
images/s
Latency (in ms) Thoughput
images/s
Latency (in ms)
Avg. Std.
dev.
Avg. Std.
dev.
RandomIO [Only Reads] 902.3 33.2 26.8 – – –
Haystress [A # Only Reads] 770.6 38.9 30.2 – – –
Haystress [B # Only Reads] 877.8 34.2 28.1 – – –
Haystress [C # OnlyMulti–Writes] – – – 6099.4 4.9 16.0
Haystress [D # OnlyMulti–Writes] – – – 7899.7 15.2 15.3
Haystress [E # OnlyMulti–Writes] – – – 10843.8 43.9 16.3
Haystress [F#Reads&MultiWrites] 718.1 41.6 31.6 232.0 11.9 6.3
Haystress [G#Reads&MultiWrites] 692.8 42.8 33.7 440.0 11.9 6.9
Bảng 4: Thông lượng và độ trễ của hoạt động đọc và multi-write trên khối lượng công việc tổng hợp. Cấu hình B được
sử dụng để trộn một Hình ảnh 8KB và 64KB. Các cấu hình còn lại sử dụng các hình ảnh 64KB.
đang ghi.
4.4.3 Production workload
Trong phần này chúng ta sẽ kiểm tra hiệu suất của Store
trên production-machines. Như chú ý ở phần 3, chúng ta
có 2 lớp là Store-write-enabled và read-only. Write-enabled
phục vụ các request đọc và ghi, read-only chỉ phục vụ
request đọc. Với 2 lớp khác biệt này, chúng ta tiến hành
phân tích một nhóm các máy trong mỗi lớp. Tất cả các
máy có cùng cấu hình phần cứng.
Ở mức độ chi tiết, trong mỗi giây có thể có một khối
lượng lớn thao tác đọc và ghi mà Store nhìn thấy trong
volume. Để đảm bảo độ trễ hợp lý, chúng tôi sử dụng một
số lượng lớn các máy có khả năng write-enabled. Điều này
đảm bảo trung bình khối lượng thao tác đọc và ghi ở mức
thấp. Hình 10 thể hiện tần suất của 2 thao tác: read-only
và write-enabled. Chú ý rằng, chúng ta nhìn thấy thao tác
upload ảnh nhiều nhất vào Chủ Nhật và thứ Hai-thể hiện
ở hai đỉnh đầu tiên của đồ thị, sau đó giảm dần và tăng trở
lại vào thứ Sáu và thứ Bảy. Sau đó, một ngày Chủ Nhật
mới đến và chúng ta nhận một đỉnh mới cao hơn (tăng
0.2% đến 0.5%).
Như chú ý ở 3, thao tác ghi vào Store luôn luôn là multi-
write trên production-machine để giảm chi phí cố định từ
thao tác ghi. Việc tìm kiếm các nhóm hình ảnh khá đơn
giản vì có 4 kích cỡ khác nhau của mỗi bức ảnh được lưu
trữ trong Haystack. Người dùng cũng thường xuyên tải
lên nhiều ảnh cho vào một album ảnh. Chúng ta có tỷ số:
(số lượng bức ảnh được upload)/multi-write = 9.27 trong
trường hợp sử dụng write-enabled machine.
Phần 4.1.2 đã giải thích rằng: đối với các bức ảnh đã
tải lên gần đây, chúng có tỷ lệ đọc và xóa cao. Sau đó, tỷ
lệ này giảm theo thời gian. Có thể nhìn thấy rõ ở hình 10
Một xu hướng đáng chú ý khác là khi dữ liệu ghi tăng
lên dẫn tới tỷ lệ đọc cũng tăng theo.
Hình 11 thể hiện độ trễ của thao tác đọc và multi-write
trên 2 máy giống như hình 10 so với cùng thời điểm.
Độ trễ của thao tác multi-write là thấp (khoảng 1ms
Hình 10: Tốc độ khác nhau trên 2 máy Haystack Store:
Một chỉ-đọc còn lại thao tác ghi được thiết lập.
10

11. Hình 11: Độ trễ trung bình của hoạt động Đọc và Viết
nhiều lần trên hai máy của Haystack Store trong Hình 10
trong cùng kỳ 3 tuần.
đến 2ms) và ổn định ngay cả khi lưu lượng truy cập thay
đổi đáng kể. Haystack có raid-controller hỗ trợ NVRAM.
Như đã mô tả trong phần 3, NVRAM cho phép chúng ta
ghi không đồng bộ, sau đó xuất ra một file fsync để tạo ra
volume file ngay khi multi-write hoàn tất. Thời gian trễ
của thao tác multi-write là rất ít và ổn định.
Độ trễ của thao tác đọc trên khối read-only là ổn định
ngay cả khi lưu lượng truy cập thay đổi lớn. Trong khi khối
write-enabled thì thao tác đọc bị ảnh hưởng bởi 3 yếu tố.
Đầu tiên, khi số lượng ảnh lưu trữ trên một máy tăng thì
lưu lượng truy cập vào máy đó cũng tăng (So sánh trên
hình 10). Yếu tố thứ 2, ảnh trên các máy write-enabled
được lưu trữ trong Cache (CDN nội bộ) còn ảnh trên các
máy read-only thì không3
. Điều này cho thấy bộ nhớ đệm
cache (cache trên máy) sẽ hiệu quả hơn cho một máy read-
only. Thứ 3, những bức ảnh được ghi gần đây luôn được
đọc lại ngay bởi Facebook thường làm nổi bật những nội
dung mới. Các lần đọc trên các khối write-enabled sẽ luôn
truy cập đến bộ nhớ đệm cache và giúp cải thiện tốc độ
truy cập. Hình dạng của đường cong trong ảnh là kết quả
của sự kết hợp cả 3 yếu tố đã nêu.
CPU trên các máy Store ít được sử dụng. Thời gian chờ
của CPU giao động từ 92-96%.
5 Công việc có liên quan
Theo hiểu biết của chúng tôi, Haystack nhắm đến một
điểm thiết kế mới tập trung vào các yêu cầu ảnh được
xem bởi một trang web mạng xã hội lớn.
Filesystems tập tin Haystack mất sau khi các hệ thống
tập tin có cấu trúc đăng nhập[23] mà Rosenblum và
3Lưu ý rằng đối với lưu lượng truy cập thông qua CDN, chúng
được lưu trữ trong CDN và không có trong Cache trong cả hai trường
hợp
Ousterhout được thiết kế để tối ưu hóa thông lượng ghi với
ý tưởng rằng hầu hết các lần đọc có thể được đưa ra khỏi
bộ nhớ cache. Trong khi các phép đo[3] và mô phỏng[6]
đã chỉ ra rằng các hệ thống tập tin có cấu trúc đăng nhập
chưa đạt được tiềm năng đầy đủ của chúng trong các hệ
thống tập tin cục bộ, những ý tưởng cốt lõi rất có liên
quan đến Haystack.Hình ảnh được nối vào các tập tin thể
tích vật lý trong Haystack Store và các máy ghi đè lên của
Haystack Cache không bị quá tải bởi tỷ lệ yêu cầu cho dữ
liệu được tải lên gần đây. Sự khác biệt chính là (a) các
máy của Haystack Store viết dữ liệu của họ theo cách sao
cho chúng có thể phục vụ các lần đọc một cách hiệu quả
khi chúng trở thành chỉ đọc và (b) tỷ lệ yêu cầu đọc đối
với dữ liệu cũ sẽ giảm theo thời gian.
Một vài works[8, 19, 28] Đã đề xuất cách quản lý các
tệp nhỏ và siêu dữ liệu hiệu quả hơn. Các chủ đề phổ
biến trên những đóng góp này là làm thế nào để nhóm
liên quan tập tin và siêu dữ liệu với nhau một cách thông
minh. Haystack bỏ qua những vấn đề này vì nó duy trì
siêu dữ liệu trong bộ nhớ chính và người dùng thường tải
lên các ảnh có liên quan với số lượng lớn.
Lưu trữ dựa trên đối tượng Kiến trúc của Haystack
có nhiều điểm tương đồng với các hệ thống lưu trữ đối
tượng được đề xuất bởi Gibson et al[10] Trong Đĩa bảo mật
Đính kèm Mạng (NAS). Directory và Store của Haystack
có lẽ tương tự như các khái niệm File and Storage Manag-
er, tương ứng, trong NASD tách biệt lưu trữ hợp lý.Đơn
vị từ những vật lý. Trong OBFS[25]Wang et al xây dựng
một hệ thống tập tin dựa trên người dùng dựa trên đối
tượng là 1/25 (th) kích thước của XFS. Mặc dù OBFS đạt
được viết lớn hơn. Thông qua hơn XFS, thông lượng đọc
của nó (mối quan tâm Haystack’smain) là hơi tồi tệ hơn.
Quản lý siêu dữ liệu Weil et al. [26, 27] Địa chỉ quản
lý siêu dữ liệu trong Ceph, một cửa hàng đối tượng quy
mô petabytescale. Ceph thêm decouples các bản đồ từ hợp
lý. Đơn vị để thể chất bằng cách giới thiệu các chức năng
tạo ra thay vì ánh xạ rõ ràng. Khách hàng có thể tính toán
các siêu dữ liệu phù hợp hơn là tìm kiếm nó. Thực hiện
kỹ thuật này trong Haystack vẫn là công việc trong tương
lai. Hendricks et. al [13] Nhận thấy các thuật toán tìm
nạp siêu dữ liệu truyền thống ít hiệu quả hơn đối với các
cửa hàng đối tượng bởi vì các đối tượng liên quan, được
xác định bởi một số duy nhất, thiếu nhóm ngữ nghĩa mà
các thư mục ngầm đặt ra. Giải pháp của họ là nhúng mối
quan hệ giữa các đối tượng vào id đối tượng. Ý tưởng này
là trực giao với Haystack khi Facebook lưu trữ các mối
quan hệ ngữ nghĩa này một cách rõ ràng. Trong Spyglass
[15], Leung et al. Đề xuất một thiết kế để nhanh chóng và
có thể tìm kiếm thông qua siêu dữ liệu của hệ thống lưu
trữ quy mô lớn. Manber và Wu cũng đề xuất một cách
để tìm kiếm thông qua toàn bộ hệ thống tập tin trong
GLIMPSE [17]. Patil et al. [20] Sử dụng một thuật toán
tinh vi trong GIGA + để quản lý siêu dữ liệu liên kết với
hàng tỉ tệp trong mỗi thư mục. Chúng tôi thiết kế một giải
pháp đơn giản hơn nhiều công trình hiện tại vì Haystack
không phải cung cấp các tính năng tìm kiếm cũng như các
ngữ nghĩa hệ thống tập tin UNIX truyền thống.
11

12. Hệ thống tệp phân tán Hệ thống tập tin phân tán
Quan niệm của Haystack về khối lượng hợp lý tương tự
như các đĩa ảo của Lee và Thekkath [14] trong Petal. Dự
án Boxwood[16] khám phá việc sử dụng các cấu trúc dữ
liệu cao cấp làm nền tảng cho việc lưu trữ. Trong khi
thuyết phục cho các thuật toán phức tạp hơn, trừu tượng
như B-trees có thể không có tác động lớn đến giao diện
và ý nghĩa ngữ nghĩa của Haystack. Tương tự, các chức
năng minutransactions của Sinfonia[1] và chức năng cơ sở
dữ liệu PNUTS[5] cung cấp nhiều tính năng hơn và mạnh
mẽ hơn.Bảo đảm hơn nhu cầu của Haystack. Ghemawat
et al [9] Đã thiết kế Hệ thống tệp của Google cho khối
lượng công việc bao gồm phần lớn các hoạt động nối tiếp
và các lần đọc tuần tự lớn. Bigtable [4] Cung cấp một hệ
thống lưu trữ dữ liệu có cấu trúc và cung cấp tính năng
giống như các tính năng giống hệt nhau cho nhiều dự án
của Google. Không rõ liệu nhiều tính năng này có được
trong một hệ thống tối ưu hóa cho việc lưu trữ ảnh.
6 Giải pháp
Bài báo này mô tả Haystack, một hệ thống lưu trữ đối
tượng được thiết kế cho ứng dụng Facebook’s Photos.
Chúng tôi thiết kế Haystack để phục vụ đuôi dài của các
yêu cầu được nhìn thấy Bằng cách chia sẻ ảnh trong mạng
xã hội lớn. Cái nhìn sâu sắc quan trọng là để tránh các thao
tác đĩa khi truy cập siêu dữ liệu. Haystack cung cấp các
giải pháp chịu lỗi để lưu trữ hình ảnh với chi phí thấp hơn
đáng kể và cao hơn thông qua một cách tiếp cận truyền
thống sử dụng các thiết bị NAS. Hơn nữa, Haystack có
khả năng mở rộng từng bước, một chất lượng cần thiết
khi người dùng của chúng tôi tải hàng trăm triệu bức ảnh
mỗi tuần.
Tài liệu
[1] M. K. Aguilera, A. Merchant, M. Shah, A. Veitch, and
C. Karamanolis. Sinfonia a new paradigm for building
scalable dis- tributed systems. In SOSP ’07: Proceed-
ings of twenty-first ACM SIGOPS symposium on ,
pages159–174.New York, NY, USA, 2007. ACM.
[2] Akamai.http://www.akamai.com/
[3] M. G. Baker, J. H. Hartman, M. D. Kupfer, K. W.
Shirriff, and J. K. Ousterhout. Measurements of a
distributed file system. In Proc. 13th SOSP, pages
198–212, 1991.
[4] F. Chang, J. Dean, S. Ghemawat, W. C. Hsieh, D.
A. Wallach, M. Burrows, T. Chandra, A. Fikes, and
R. E. Gruber. Bigtable:A distributed storage sys-
tem for structured data. ACM Trans. Comput. Syst.,
26(2):1–26, 2008.
[5] B. F. Cooper, R. Ramakrishnan, U. Srivastava, A.
Silberstein, P. Bohannon, H.-A. Jacobsen, N. Puz,
D. Weaver, and R. Yer- neni. Pnuts: Yahoo!’s host-
ed data serving platform. Proc. VLDB Endow.,
1(2):1277–1288, 2008.
[6] M. Dahlin, R. Wang, T. Anderson, and D. Patterson.
Cooper- ative Caching: Using Remote Client Memory
to Improve File System Performance. In Proceedings
of the First Symposium on Operating Systems Design
and Implementation, pages 267–280, Nov 1994.
[7] M. Factor, K. Meth, D. Naor, O. Rodeh, and J.
Satran. Object storage: the future building block for
storage systems. In LGDI ’05: Proceedings of the 2005
IEEE International Symposium on Mass Storage Sys-
tems and Technology, pages 119–123, Wash- ington,
DC, USA, 2005. IEEE Computer Society.
[8] G. R. Ganger and M. F. Kaashoek. Embedded inodes
and ex- plicit grouping: exploiting disk bandwidth for
small files. In ATEC ’97: Proceedings of the annual
conference on USENIX Annual Technical Conference,
pages 1–1, Berkeley, CA, USA, 1997. USENIX Asso-
ciation.
[9] S. Ghemawat, H. Gobioff, and S.-T. Leung. The
google file system. In Proc. 19th SOSP, pages 29–43.
ACM Press, 2003.
[10] G. A. Gibson, D. F. Nagle, K. Amiri, J. Butler,
F. W. Chang, H. Gobioff, C. Hardin, E. Riedel,
D. Rochberg, and J. Zelenka. A cost-effective, high-
bandwidth storage architecture. SIGOPS Oper. Syst.
Rev., 32(5):92–103, 1998.
[11] The hadoop project. http://hadoop.apache.org/.
[12] S. He and D. Feng. Design of an object-based storage
device based on i/o processor. SIGOPS Oper. Syst.
Rev., 42(6):30–35, 2008.
[13] J. Hendricks, R. R. Sambasivan, S. Sinnamohideen,
and G. R. Ganger. Improving small file performance
in object-based storage. Technical Report 06-104,
Parallel Data Laboratory, Carnegie Mellon Univer-
sity, 2006.
[14] E. K. Lee and C. A. Thekkath. Petal: distributed vir-
tual disks. In ASPLOS-VII: Proceedings of the sev-
enth international confer- ence on Architectural sup-
port for programming languages and operating sys-
tems, pages 84–92, New York, NY, USA, 1996. ACM.
[15] A. W. Leung, M. Shao, T. Bisson, S. Pasupathy, and
E. L. Miller. Spyglass: fast, scalable metadata search
for large-scale storage systems. In FAST ’09: Procced-
ings of the 7th conference on File and storage tech-
nologies, pages 153–166, Berkeley, CA, USA, 2009.
USENIX Association.
[16] J. MacCormick, N. Murphy, M. Najork, C. A.
Thekkath, and L. Zhou. Boxwood: abstractions as
12

13. the foundation for storage infrastructure. In OSDI’04:
Proceedings of the 6th conference on Symposium on
Opearting Systems Design & Implementation, pages
8–8, Berkeley, CA, USA, 2004. USENIX Association.
[17] U. Manber and S. Wu. Glimpse: a tool to search
through entire file systems. In WTEC’94: Proceed-
ings of the USENIX Winter 1994 Technical Confer-
ence on USENIX Winter 1994 Technical Conference,
pages 4–4, Berkeley, CA, USA, 1994. USENIX As-
sociation.
[18] memcache. http://memcached.org/.
[19] S. J. Mullender and A. S. Tanenbaum. Immediate
files. Softw. Pract. Exper., 14(4):365–368, 1984.
[20] S. V. Patil, G. A. Gibson, S. Lang, and M. Polte.
Giga+: scalable directories for shared file systems.
In PDSW ’07: Proceedings of the 2nd internation-
al workshop on Petascale data storage, pages 26–29,
New York, NY, USA, 2007. ACM.
[21] Posix. http://standards.ieee.org/regauth/posix/.
[22] Randomio. http://members.optusnet.com.au/
clausen/ideas/randomio/index.html.
[23] M. Rosenblum and J. K. Ousterhout. The design
and implemen- tation of a log-structured file system.
ACM Trans. Comput. Syst., 10(1):26–52, 1992.
[24] A. Sweeney, D. Doucette, W. Hu, C. Anderson, M.
Nishimoto, and G. Peck. Scalability in the xfs file
system. In ATEC ’96: Proceedings of the 1996 annu-
al conference on USENIX Annual Technical Confer-
ence, pages 1–1, Berkeley, CA, USA, 1996. USENIX
Association.
[25] F. Wang, S. A. Brandt, E. L. Miller, and D. D. E.
Long. Obfs: A file system for object-based storage
devices. In In Proceedings of the 21st IEEE / 12TH
NASA Goddard Conference on Mass Storage Systems
and Technologies, pages 283–300, 2004.
[26] S. A. Weil, S. A. Brandt, E. L. Miller, D. D. E. Long,
and C. Maltzahn. Ceph: a scalable, high-performance
distributed file system. In OSDI ’06: Proceedings of
the 7th symposium on Operating systems design and
implementation, pages 307–320, Berkeley, CA, USA,
2006. USENIX Association.
[27] S. A. Weil, K. T. Pollack, S. A. Brandt, and E.
L. Miller. Dy- namic metadata management for
petabyte-scale file systems. In SC ’04: Proceedings of
the 2004 ACM/IEEE conference on Su- percomput-
ing, page4, Washington, DC,USA,2004.IEEECom-
puter Society.
[28] Z. Zhang and K. Ghose. hfs: a hybrid file system
prototype for improving small file and metadata per-
formance. SIGOPS Oper. Syst. Rev., 41(3):175–187,
2007.
13