Nếu bạn đang sử dụng S3 như để lưu trữ dữ liệu từ các tệp tải lên của người dùng, đặc biệt là trong môi trường phân tán, một điều cần cân nhắc lớn là thực tế là S3 'nhất quán' (mặc dù, một số vùng có tính nhất quán sau khi đọc). Hậu quả của việc này là bạn có thể tải lên thành công một tệp, nhưng nếu bạn kiểm tra sự tồn tại của nó ngay sau đó, có thể thấy nó không tồn tại. Vấn đề này rõ rệt hơn đối với các tình huống như cập nhật hoặc xóa, trong đó ngay cả tính nhất quán đọc sau khi viết cũng không giúp được gì.
Những điều trên sẽ áp dụng cho việc tải lên S3 của bạn bất kể cách tiếp cận bạn thực hiện. Trên thực tế, điều này đúng với hầu hết các vấn đề mà người ta có thể mong đợi ở S3 - đó không phải là cách tiếp cận được sử dụng để lưu trữ dữ liệu vì đó là những hạn chế của S3 có thể sẽ gây ra nhiều vấn đề nhất.
S3fs sử dụng API S3 - giống như SDK PHP (hoặc loại khác). Hơn nữa, S3 được thiết kế để xử lý mức độ tương tranh khá cao - vì vậy (ngoài các vấn đề về tính nhất quán) không nên có vấn đề khi cài đặt nó trên nhiều trường hợp (hãy nhớ rằng đó không phải là một hệ thống tệp truyền thống - các vấn đề như khóa, vv được xử lý ở phía S3).
Điều đó nói rằng, có một số lợi thế và bất lợi tiềm năng của mỗi thực hiện:
S3fs:
- Không hỗ trợ tải xuống một phần / chunked (theo như tôi biết) - vì vậy bạn phải tải xuống toàn bộ tệp để đọc bất kỳ phần nào của nó - có thể không phải là vấn đề nếu bạn chỉ sử dụng nó để lưu trữ (và phục vụ) tải lên.
- Viết bằng C ++ hiệu suất có thể đạt được
- Ứng dụng của bạn được hưởng lợi từ mọi cập nhật cho s3fs
- Triển khai bộ nhớ đệm (cả tệp đầy đủ và thông tin tệp) - có khả năng cải thiện tốc độ một chút và giảm chi phí
- Giới hạn các chức năng mà cầu chì tiếp xúc
SDK:
- Tiếp xúc với bộ tính năng đầy đủ mà S3 cung cấp - tùy thuộc vào trường hợp sử dụng của bạn, điều này có thể đủ để sử dụng SDK
- Khả năng tích hợp chặt chẽ hơn với ứng dụng của bạn - các lỗi được trả về, v.v. có thể cho phép ứng dụng của bạn đưa ra các lựa chọn sáng suốt hơn (và do đó chính xác hơn)
- Bất kỳ lợi thế nào có thể cần được mã hóa - ứng dụng của bạn phải tận dụng chúng và được cập nhật với các thay đổi trong tương lai cho S3
- Sự phức tạp và chi phí cao hơn cho mã của bạn
Về mặt 'an toàn', bạn có thể có nghĩa là 'ngăn ngừa tham nhũng dữ liệu' hoặc 'ngăn chặn truy cập trái phép'. Đối với trước đây, SDK có thể giúp một chút để xử lý tính nhất quán cuối cùng (dưới dạng nhiều lỗi dài dòng hơn), nhưng bộ nhớ cơ bản là như nhau và tôi hy vọng sự khác biệt là nhỏ. Liên quan đến kiểm soát truy cập - bạn có thể sử dụng IAM để tạo một tài khoản giới hạn, nhưng tài khoản đó vẫn sẽ cần quyền truy cập đọc / ghi vào các tệp S3 của bạn. Cả hai phải được bảo mật đầy đủ, trong cả hai trường hợp, hệ thống của bạn cần được thỏa hiệp để có quyền truy cập vào nhóm S3 của bạn - tuy nhiên tôi sẽ đề xuất rằng với S3fs (vì thông tin đăng nhập thường được lưu trữ bên ngoài webroot và hoàn toàn không thể truy cập được PHP) có bảo mật tốt hơn một chút.
Ý kiến cá nhân: Tôi thích s3fs cho trường hợp có một thư mục tải lên (ví dụ: một trang web sử dụng nó) và nơi truy cập sẽ khá đơn giản (chỉ cần tải lên tệp và thỉnh thoảng cập nhật / xóa). Nếu bạn sẽ cần truy cập phức tạp hơn (ví dụ: tải xuống một phần, nhiều nhóm, v.v.) hoặc sẽ sử dụng SDK S3 cho các mục đích khác, thì tôi cũng sẽ gắn bó với SDK để tải lên.