2 điểm bởi GN⁺ 2024-03-11 | 1 bình luận | Chia sẻ qua WhatsApp

S3 là tệp, nhưng không phải hệ thống tệp

  • Amazon S3 là một công nghệ đám mây nguyên bản được ra mắt vào năm 2006, thường được gọi là "object storage", nhưng trên thực tế là dành cho tệp.
  • Việc nghĩ S3 là một "Amazon Cloud Filesystem" là một niềm tin hữu ích giúp thúc đẩy mọi người chấp nhận S3, nhưng sự thật là S3 không phải là hệ thống tệp.

Hệ thống tệp là gì, và "độ sâu" của mô-đun

  • API tệp của Unix gồm năm hàm cơ bản, và chúng cung cấp mọi thứ cần thiết để đọc và ghi tệp.
  • Các hàm này xử lý nhiều vấn đề như buffering, page cache, phân mảnh, quyền hạn, lập lịch IO và nhiều thứ khác, nhưng không phơi bày chúng cho người dùng.
  • Mô-đun sâu có ưu điểm là cho phép người dùng sử dụng chức năng mà không cần phải nghĩ về sự phức tạp.

Đặc điểm của S3 (đây cũng là một mô-đun sâu)

  • S3 không tái triển khai API hệ thống tệp Unix, và cách gọi cơ bản của nó là khác.
  • API S3 đơn giản hơn API tệp Unix, nhưng có hạn chế là không thể ghi đè một phần lên object.

Phần mềm hệ thống tệp, đặc biệt là cơ sở dữ liệu, không thể chuyển sang Amazon S3

  • Cơ sở dữ liệu cần một nơi để lưu dữ liệu, và nơi đó thường là nhiều tệp khác nhau trong một hệ thống tệp.
  • Cơ sở dữ liệu phụ thuộc rất nhiều vào khả năng ghi đè từng phần, và điều này là không thể trong S3.

Điều S3 làm tốt và điều S3 không làm tốt

  • Điểm mạnh của S3 là băng thông đọc và ghi rất cao.
  • Tuy nhiên, S3 không có ghi đè từng phần, không có thao tác đổi tên hoặc di chuyển, và việc liệt kê danh sách tệp cũng chậm.
  • Dù vậy, S3 đòi hỏi ít bảo trì hơn và đơn giản hóa các công việc như thiết lập sao lưu, sao chép và provisioning.

Tầm quan trọng của độ sâu mô-đun giữa các tổ chức

  • Không có gì ngạc nhiên khi S3 trở thành API đám mây phổ biến đầu tiên, vì API sâu giúp quản lý sự phức tạp giữa các tổ chức.
  • Việc tích hợp phần mềm doanh nghiệp phức tạp như SAP là một công việc đầy đau đớn, và đó là vì SAP không phải là một mô-đun sâu.

Thông tin khác

  • Bài viết này không nhằm gợi ý rằng S3 bị đánh giá quá cao, mà để giải thích khái niệm mô-đun sâu so với mô-đun tương đối nông.
  • Một số cơ sở dữ liệu đã được thiết kế để dùng API S3 làm storage, điều này là khả thi nhưng không hề trong suốt.
  • Trong S3, nhiều định dạng tệp có hiệu năng kém hơn so với đĩa.

Ý kiến của GN⁺

  • Điều quan trọng là phải hiểu rằng S3 không phải là vật thay thế cho hệ thống tệp, mà là một giải pháp lưu trữ được tối ưu cho các trường hợp sử dụng cụ thể. Ví dụ, nó phù hợp để lưu trữ và truyền các tệp bất biến quy mô lớn, nhưng không phù hợp với các ứng dụng cần cập nhật từng phần thường xuyên như cơ sở dữ liệu.
  • Hiệu năng và khả năng mở rộng của S3 rất cao, nhưng khi cân nhắc hiệu quả chi phí và độ phức tạp trong quản lý, nó không phù hợp với mọi dự án. Ví dụ, dự án mã nguồn mở MinIO có thể là một lựa chọn thay thế tốt cho các tổ chức muốn xây dựng storage tương thích S3 trên hạ tầng riêng.
  • Khi sử dụng S3, còn có các yếu tố cần cân nhắc thêm như tính nhất quán dữ liệu, chi phí mạng và kiểm soát truy cập; những yếu tố này có thể ảnh hưởng đến thiết kế toàn bộ hệ thống.
  • Dù trường hợp sử dụng của S3 có thể bị giới hạn, nó vẫn là một công cụ rất mạnh trong các ứng dụng cụ thể như data lake hoặc giải pháp sao lưu. Khả năng lưu trữ dữ liệu an toàn và truy xuất nhanh khi cần mang lại giá trị quan trọng cho nhiều doanh nghiệp.
  • Bài viết này có thể giúp đưa ra các quyết định kỹ thuật bằng cách cung cấp hiểu biết sâu sắc về các chi tiết kỹ thuật của S3 và các trường hợp sử dụng thực tế của nó.

1 bình luận

 
GN⁺ 2024-03-11
Ý kiến trên Hacker News
  • Tôi chưa từng nghe nói có vấn đề nào về độ bền của S3, nhưng cũng chưa từng thấy những tuyên bố này được kiểm chứng. Dù vậy tôi vẫn khá tò mò về chúng.

    • Độ bền của S3 đang dẫn đầu ngành và không thể so sánh với các hệ thống tệp truyền thống.
    • Việc tách biệt vùng khả dụng của AWS vượt trội hơn các nhà cung cấp đám mây khác.
    • S3 rất chú trọng đến tính toàn vẹn dữ liệu và các rủi ro từ thiên tai.
    • S3 được vận hành ở quy mô đủ lớn để có thể phát hiện cả "bit rot".
    • Dữ liệu quan trọng sẽ không được lưu ở đâu khác ngoài S3.
    • Nguồn: người đã viết hệ thống batch của S3.
  • Việc liệt kê danh sách tệp rất chậm. S3 đọc và ghi rất nhanh, nhưng liệt kê danh sách tệp thì rất chậm.

    • Thứ hữu ích không phải là khả năng đọc và ghi nhanh của S3, mà là chức năng liệt kê danh sách tệp.
    • Với các bucket không bật versioning, việc liệt kê theo tiền tố cho trước trên thực tế có thể đạt thời gian gần như hằng số.
    • Có thể phân vùng dữ liệu theo nhiều cách khác nhau và dùng các định danh cần thiết mà không phải lo về hiệu năng.
  • Gần đây tôi khá bất ngờ khi thấy việc liệt kê danh sách tệp lại chậm. Khi làm script để quản lý asset trên S3, tôi nhận ra mình cần cache danh sách tệp.

    • Có khoảng 100.000 thư mục ở cấp gốc, và mỗi thư mục lại có vài thư mục con chứa một số tệp.
    • Mất 15 phút để liệt kê tệp theo cách đệ quy.
    • Tôi tự hỏi vì sao Amazon vẫn chưa giải quyết vấn đề này.
  • Amazon S3 là công nghệ đám mây nguyên bản, ra mắt vào năm 2006. "Object" là khái niệm rất thịnh hành vào thời điểm đó, và S3 được gọi là "object store".

    • S3 không phải là hệ thống tệp mà là object store.
    • S3 không phải là file, cũng không phải là hệ thống tệp.
    • Điều người ta kỳ vọng từ sự trừu tượng của file là tính có thể thay đổi.
    • S3 cung cấp một danh sách có thể thay đổi của các object bất biến.
    • S3 giải quyết một bài toán khác, và những nỗ lực biến nó trông giống hệ thống tệp xuất phát từ sự hiểu lầm của khách hàng.
  • Có thảo luận so sánh API do object_store của Apache Arrow và Apache OpenDAL cung cấp.

    • Apache OpenDAL là thư viện cung cấp API giống FS cho nhiều dịch vụ lưu trữ đám mây, bao gồm cả S3.
    • Một số hệ quản trị cơ sở dữ liệu như GreptimeDB và Databend dùng OpenDAL để truy cập dữ liệu trên lưu trữ đám mây.
    • Các giải pháp khác như Alluxio và JuiceFS cũng quản lý giao diện giống hệ thống tệp trên S3.
  • Phần mềm hệ thống tệp, đặc biệt là cơ sở dữ liệu, không thể được port sang Amazon S3.

    • Tuy nhiên vẫn có thể.
    • Không cần phải ghi đè toàn bộ file DB mỗi lần thực hiện INSERT/UPDATE/DELETE.
    • Với SQLite, có các công cụ như Litestream hỗ trợ sao chép và khôi phục lên S3.
  • Tôi dùng Minio làm "S3" cục bộ để lưu dataset và checkpoint của mô hình.

    • Minio có nhiều tính năng mà tôi không cần.
    • Lựa chọn tự host, một node, tốt nhất hiện nay cho một "thứ" giống S3 tối thiểu, có thể CRUD file và xem danh sách, là gì?
  • Nhân lúc nói về S3, cũng đáng để nhắc đến Backblaze B2.

    • Tôi rất hài lòng với mức giá rẻ hơn S3 tới 3 lần.
  • S3 có thể bị dùng sai như một hệ thống tệp.

    • S3 muốn làm việc với object, và ở đây có các object 512 hoặc 4096 byte được gọi là cluster.