Lưu trữ đám mây, và vì sao không chỉ là S3

Kéo một danh mục về

Đây là nửa còn lại của câu “chúng tôi kéo về, theo lịch, bằng thông tin xác thực mà chủ thư viện đã đưa cho chúng tôi”: dành cho một bucket mà chủ thư viện đã có, trên bất kỳ dịch vụ lưu trữ nào tương thích S3. Không có nhà cung cấp nào được nêu tên ở bất cứ đâu trong này: không trong lược đồ, không trong biểu mẫu kết nối, không trong tài liệu này ngoài chính cụm từ “tương thích S3”.

Kết nối là kiểm chứng, không phải dự đoán. Biểu mẫu hỏi một endpoint, một bucket, một access key id và một secret, cùng một tiền tố thư mục tùy chọn. Region và kiểu địa chỉ path-style hay virtual-hosted nằm sau một mục “nâng cao”, vì cả hai thường suy ra được từ endpoint và chỉ thỉnh thoảng cần một người ghi đè. Khi lưu, hệ thống chạy một ListBucket thật và báo lại bất cứ thứ gì nhận về, kể cả nguyên văn lỗi của dịch vụ lưu trữ, thay vì cố đoán xem thông tin có đúng không.

Chỉ đọc, luôn luôn. Khóa được xin và dùng chỉ để GetObject và ListBucket. Không có đường mã nào ở bất cứ đâu ghi vào, xóa khỏi, hay sửa đổi bucket của ai. Việc đổ dữ liệu vào nó diễn ra trong các công cụ riêng của nhà cung cấp lưu trữ, đúng như việc đổ dữ liệu vào thư mục của bridge diễn ra trong trình quản lý tệp của máy tính.

Lập danh mục là một đợt quét theo lịch, không phải làm một lần. Mỗi mười phút, và một lần ngay sau khi một bucket được kết nối, chúng tôi liệt kê nó (tôn trọng tiền tố) và khớp media theo phần mở rộng: .mp4, .m4v, .webm, .mov, .mp3 và .m4a là phát được, còn .mkv, .avi, .wmv và .flv cũng được ghi vào danh mục và đánh dấu playable: false, vì lý do nêu trong Định dạng. Chúng tôi tách “Artist - Title” khỏi tên tệp theo cùng cách bridge làm (xem bên dưới), và ghi kết quả qua cùng đường nội bộ mà endpoint đồng bộ dùng, để chỉ có đúng một nơi một danh mục được ghi vào, bất kể nó đến từ hướng nào.

Tên tệp chính là tên bài. Phần đuôi bị bỏ và dấu gạch dưới thành dấu cách. Nếu phần còn lại có một dấu cách, một dấu gạch nối và một dấu cách, Artist - Title, thì phần trước dấu ngăn đầu tiên là nghệ sĩ và phần sau là tên bài, và một tên bài tự chứa dấu ngăn đó thì giữ nguyên. Nếu không, không có nghệ sĩ và cả tên là tên bài. Một dấu gạch nối không có dấu cách hai bên không phải dấu ngăn. Các thẻ bên trong tệp không được đọc. Đây là quy tắc bridge dùng cho một tệp trên đĩa, và nó được mô tả cho người dùng trong một đêm karaoke.

Ảnh bìa theo quy ước riêng của bridge: một ảnh nằm cạnh mỗi tệp, cùng tên gốc, một trong các đuôi .jpg, .jpeg, .png hoặc .webp, khớp không phân biệt hoa thường. Vì dịch vụ có thể truy cập trực tiếp vào bucket, hình được lấy một lần và lưu dưới dạng các byte, theo cùng đường như một lần đẩy tới /providers/art (xem Ảnh bìa), thay vì một liên kết, thứ sẽ hết hạn trong danh mục từ lâu trước khi ai đó nhìn tới. ETag của chính đối tượng được dùng để bỏ qua việc lấy lại một hình không đổi kể từ đợt quét trước, và giới hạn 1 MB như cũ cũng áp dụng.

Khóa của đối tượng là externalId. Khác với dấu vân tay nội dung của bridge, điều này nghĩa là đổi tên một đối tượng trong bucket sẽ mất mọi chỉnh sửa gắn với nó. Lược đồ không có chỗ nào khác để giữ một id ổn định cho thứ mà chúng tôi chỉ liệt kê, không bao giờ tự lấy dấu vân tay.

Xác định media là phát ra một liên kết, không phải một token. Nơi địa chỉ của bridge mang một bí mật bearer không hết hạn, một track trên đám mây được xác định thành một liên kết GetObject presigned có hiệu lực vài phút: đủ lâu cho một bài hát thông thường, đủ ngắn để một liên kết bị lộ không đáng giá bao nhiêu. Chính Stage xin liên kết này khi một bài sắp phát, giữ nó, và xin lại trước khi nó hết hạn, hoặc khi tiếp tục một bài đã tạm dừng quá thời hạn của liên kết.

canSeek được đo. Ở mỗi đợt quét, chúng tôi xin bucket một range của một trong các tệp phát được của nó và ghi nhận nó có đáp ứng không, thay vì giả định. Một bucket không bao giờ được khai báo canAnalyseAudio.

Vì sao đây không chỉ là S3

Một gợi ý lặp đi lặp lại: bỏ hết những gì ở trên và nói “một provider là một bucket tương thích S3”. Đó là một bản năng tốt — một giao thức, máy chủ có sẵn, một liên kết presigned thay cho media token — và nó đã được cân nhắc rồi bị bác bỏ. Các lý do, để không phải bàn lại từ đầu:

Nửa đắt giá thì không dùng chung được. Nói S3 nghĩa là phải xác minh SigV4 trên mọi yêu cầu: canonical request, signed header, payload hash, lệch đồng hồ. Đó là mã nhạy cảm về bảo mật thay cho một phép so sánh token, và một bộ ký phía client, thứ mà chúng tôi vẫn phải viết để dùng các bucket, không giúp được gì cho việc đó.

Nó không thống nhất được thứ thực sự bị tách đôi. Danh mục di chuyển theo hai hướng ngược nhau tùy vào việc chúng tôi có liên lạc được với bạn hay không, và đó là chuyện khả năng truy cập, không phải giao thức. Một bucket trên NAS gia đình vẫn không thể bị thăm dò từ bên ngoài. S3 không thay đổi gì về điều đó.

Nó mở rộng thứ một provider để lộ ra. Ngày nay hợp đồng là một động từ trên một đường dẫn. Một endpoint S3 thật mời gọi ListObjects, tức một danh mục mà ai trong mạng cũng duyệt được.

Nó nâng ngưỡng cho mọi người khác. “Phục vụ một GET có hỗ trợ range” là hai mươi dòng trong bất kỳ ngôn ngữ nào, đó là toàn bộ ý nghĩa. “Triển khai S3” thì không, và hợp đồng tồn tại để một provider có thể được viết bởi người chưa từng nghe đến chúng tôi.

Một bucket vẫn là một nguồn hoàn toàn tốt. Nó chỉ dùng hợp đồng này thay vì thay thế nó, với liên kết được phát ra thay vì được nối chuỗi, như mô tả ở trên. Việc ký là tính toán thuần túy, nên liên kết đó thậm chí có thể trỏ tới một địa chỉ mà chính chúng tôi không với tới: một NAS có thể được một thứ trong mạng của nó đẩy danh mục lên trong khi media được xác định qua một liên kết presigned mà Stage gọi thẳng. Vấn đề chứng chỉ cũng là vấn đề bridge gặp, và có cùng lời giải, mô tả trong Một cái tên và một chứng chỉ.