Có phải là một thực tế xấu khi lưu trữ các tệp lớn (10 MB) trong cơ sở dữ liệu?

Tôi hiện đang tạo một ứng dụng web cho phép người dùng lưu trữ và chia sẻ tệp, kích thước 1 MB - 10 MB.

Dường như với tôi rằng việc lưu trữ các tệp trong cơ sở dữ liệu sẽ làm chậm đáng kể việc truy cập cơ sở dữ liệu.

Đây có phải là một mối quan tâm hợp lệ? Có tốt hơn để lưu trữ các tệp trong hệ thống tệp và lưu tên tệp và đường dẫn trong cơ sở dữ liệu? Có cách thực hành tốt nhất nào liên quan đến việc lưu trữ tệp khi làm việc với cơ sở dữ liệu không?

Tôi đang làm việc trong PHP và MySQL cho dự án này, nhưng vấn đề này giống nhau đối với hầu hết các môi trường ( Ruby on Rails , PHP , .NET ) và cơ sở dữ liệu (MySQL, PostgreQuery ).

Lý do ủng hộ việc lưu trữ tệp trong cơ sở dữ liệu:

1. Tính nhất quán của ACID bao gồm cả bản cập nhật của bản cập nhật rất phức tạp khi các tệp được lưu trữ bên ngoài cơ sở dữ liệu. Đây không phải là để được che đậy nhẹ. Có các tệp và cơ sở dữ liệu đồng bộ và có thể tham gia vào các giao dịch có thể rất hữu ích.
2. Các tập tin đi với cơ sở dữ liệu và không thể mồ côi từ nó.
3. Sao lưu tự động bao gồm các tệp nhị phân.

Lý do chống lưu trữ tệp trong cơ sở dữ liệu:

1. Kích thước của tệp nhị phân khác nhau giữa các cơ sở dữ liệu. Trên SQL Server, ví dụ, khi không sử dụng đối tượng FILESTREAM, nó là 2 GB. Nếu người dùng cần lưu trữ các tệp lớn hơn (như nói một bộ phim), bạn phải nhảy qua các vòng để biến điều kỳ diệu đó thành hiện thực.
2. Tăng kích thước của cơ sở dữ liệu. Một khái niệm chung bạn nên thuộc nằm lòng: Mức độ kiến ​​thức cần thiết để duy trì cơ sở dữ liệu tăng tỷ lệ thuận với kích thước của cơ sở dữ liệu.Tức là, cơ sở dữ liệu lớn phức tạp hơn để duy trì hơn cơ sở dữ liệu nhỏ. Lưu trữ các tệp trong cơ sở dữ liệu có thể làm cho cơ sở dữ liệu lớn hơn nhiều. Ngay cả khi nói rằng một bản sao lưu đầy đủ hàng ngày sẽ có hiệu lực, với kích thước cơ sở dữ liệu lớn hơn, bạn có thể không còn có thể làm điều đó. Bạn có thể phải xem xét việc đặt các tệp vào một nhóm tệp khác (nếu cơ sở dữ liệu hỗ trợ điều đó), tinh chỉnh các bản sao lưu để tách bản sao lưu dữ liệu khỏi bản sao lưu của các tệp, v.v. thêm phức tạp để bảo trì có nghĩa là chi phí cho doanh nghiệp. Cơ sở dữ liệu lớn hơn cũng tiêu tốn nhiều bộ nhớ hơn khi họ cố gắng nhồi càng nhiều dữ liệu vào bộ nhớ càng tốt.
3. Tính di động có thể là mối quan tâm nếu bạn sử dụng các tính năng cụ thể của hệ thống như FILESTREAMđối tượng của SQL Server và cần di chuyển sang hệ thống cơ sở dữ liệu khác.
4. Mã ghi các tệp vào cơ sở dữ liệu có thể là một vấn đề. Một công ty mà tôi đã tham khảo cách đây không nhiều mặt trăng tại một số điểm đã kết nối giao diện Microsoft Access với máy chủ cơ sở dữ liệu của họ và sử dụng khả năng của Access để tải lên "bất cứ thứ gì" bằng cách sử dụng điều khiển Ole Object. Sau đó, họ đổi sang sử dụng một điều khiển khác vẫn dựa vào Ole. Nhiều người sau đó đã thay đổi giao diện để lưu trữ nhị phân thô. Trích xuất những đối tượng Ole đó là một cấp độ địa ngục mới. Khi bạn lưu trữ tệp trên hệ thống tệp, sẽ không có lớp bổ sung nào liên quan để bọc / chỉnh / thay đổi tệp nguồn.
5. Nó phức tạp hơn để phục vụ các tập tin vào một trang web. Để làm điều đó với các cột nhị phân, bạn phải viết một trình xử lý để truyền tệp nhị phân từ cơ sở dữ liệu. Bạn cũng có thể làm điều này ngay cả khi bạn lưu trữ đường dẫn tệp nhưng bạn không phải làm điều này. Một lần nữa, thêm một trình xử lý không phải là không thể nhưng thêm phức tạp và là một điểm thất bại khác.
6. Bạn không thể tận dụng lưu trữ đám mây. Giả sử một ngày nào đó bạn muốn lưu trữ các tệp của mình trong nhóm Amazon S3. Nếu những gì bạn lưu trữ trong cơ sở dữ liệu là các đường dẫn tệp, bạn có khả năng thay đổi các đường dẫn đó thành các đường dẫn tại S3. Theo như tôi biết, điều đó là không thể trong bất kỳ kịch bản nào với bất kỳ DBMS nào.

IMO, coi việc lưu trữ các tệp trong cơ sở dữ liệu hay không là "xấu" đòi hỏi nhiều thông tin hơn về hoàn cảnh và yêu cầu. Có phải kích thước và / hoặc số lượng tệp sẽ luôn nhỏ? Không có kế hoạch sử dụng lưu trữ đám mây? Các tệp sẽ được phục vụ trên một trang web hoặc tệp thực thi nhị phân như ứng dụng Windows?

Nói chung, kinh nghiệm của tôi đã phát hiện ra rằng việc lưu trữ các đường dẫn ít tốn kém hơn cho doanh nghiệp thậm chí còn thiếu ACID và khả năng của trẻ mồ côi. Tuy nhiên, điều đó không có nghĩa là internet không phải là quân đoàn với những câu chuyện thiếu kiểm soát ACID bị sai khi lưu trữ tệp nhưng điều đó có nghĩa là nói chung giải pháp đó dễ xây dựng, hiểu và duy trì hơn.

Trong nhiều trường hợp, đây là một ý tưởng tồi. Nó sẽ làm nở các tệp cơ sở dữ liệu và gây ra một số vấn đề về hiệu suất. Nếu bạn dán các đốm màu trong một bảng với số lượng lớn các cột thì điều đó còn tồi tệ hơn.

Tuy nhiên! Một số cơ sở dữ liệu, như SQL Server có loại cột FILESTREAM. Trong trường hợp này, dữ liệu của bạn thực sự được lưu trữ trong một tệp riêng trên máy chủ cơ sở dữ liệu và chỉ một ID cho tệp được lưu trong bảng. Trong trường hợp này, tôi không thấy nhiều lý do để không giữ dữ liệu trong máy chủ SQL. Các tệp được tự động đưa vào như một phần của bản sao lưu máy chủ và cơ sở dữ liệu và các tệp không bao giờ không đồng bộ. Vấn đề với đề xuất lưu trữ tên tệp của Tony là cơ sở dữ liệu và hệ thống tệp có thể không đồng bộ. Cơ sở dữ liệu sẽ yêu cầu một tệp tồn tại khi nó bị xóa trên đĩa. Nếu một quá trình đang sửa đổi cơ sở dữ liệu và sau đó gặp sự cố, các tệp và cơ sở dữ liệu sẽ không khớp (nghĩa là không có ACID với các tệp bên ngoài cơ sở dữ liệu).

Vâng, đó là một thực hành xấu.

Hiệu suất tác động lên DB:

• nếu bạn thực hiện SELECTvới bất kỳ cột BLOB nào, bạn sẽ luôn truy cập đĩa, trong khi không có BLOB, bạn có cơ hội lấy dữ liệu trực tiếp từ RAM (DB thông lượng cao sẽ được tối ưu hóa để phù hợp với các bảng trong RAM);
• Sao chép sẽ chậm, sao chép chậm trễ cao, vì nó sẽ phải đẩy BLOB sang nô lệ. Độ trễ sao chép cao sẽ gây ra tất cả các loại điều kiện cuộc đua và các vấn đề đồng bộ hóa khác, trừ khi bạn rõ ràng tính đến điều đó;
• Sao lưu / khôi phục DB sẽ mất nhiều thời gian hơn;

Lợi thế về tốc độ - không có gì ! Mặc dù một số hệ thống tệp cũ hơn sẽ không xử lý tốt các thư mục có hàng triệu tệp, nhưng hầu hết hiện đại không có vấn đề gì cả và trên thực tế sử dụng cùng loại cấu trúc dữ liệu như BDs (điển hình là cây B). Ví dụ ext4 (hệ thống tệp Linux mặc định) sử dụng Htree .

Kết luận: nó sẽ cản trở hiệu suất DB của bạn và sẽ không cải thiện hiệu suất truy xuất tệp.

Ngoài ra, kể từ khi bạn đang nói về ứng dụng web - phục vụ các tập tin tĩnh trực tiếp từ hệ thống tập tin sử dụng máy chủ web hiện đại, có thể làm sendfile()syscall là to lớn cải thiện hiệu suất. Điều này tất nhiên là không thể nếu bạn đang tìm nạp các tệp từ DB. Ví dụ, hãy xem xét điểm chuẩn này , cho thấy Ngnix thực hiện 25 nghìn req / s với 1000 kết nối đồng thời trên máy tính xách tay cấp thấp. Loại tải trọng đó sẽ chiên bất kỳ loại DB nào.

Tôi sẽ thực dụng về nó và tuân theo nguyên tắc "chưa tối ưu hóa". Làm cho giải pháp có ý nghĩa tại thời điểm này, và một giải pháp mà bạn có các tài nguyên phát triển để thực hiện đúng. Có rất nhiều vấn đề tiềm ẩn . Nhưng những điều đó không nhất thiết trở thành vấn đề thực sự. Ví dụ: Có thể không có vấn đề gì nếu bạn có 100 người dùng. Nó có thể là một vấn đề nếu bạn có 100.000 hoặc 10.000.000 người dùng. Nhưng trong trường hợp sau, cần có cơ sở cho nhiều nguồn lực phát triển hơn để giải quyết tất cả các vấn đề.

Nhưng việc lưu trữ dữ liệu trong cơ sở dữ liệu sẽ giúp bạn giải quyết các vấn đề khác, ví dụ như các tệp nên được lưu trữ ở đâu, chúng nên được sao lưu như thế nào, v.v. Vì bạn đang viết một ứng dụng web, đó là một ý tưởng rất tốt vì lý do bảo mật để đảm bảo rằng quá trình lưu trữ ứng dụng không có quyền ghi vào hệ thống tệp, vì vậy bạn cần định cấu hình máy chủ để quá trình đó có quyền truy cập đọc / ghi vào thư mục lưu trữ dữ liệu.

Cá nhân tôi sẽ chọn lưu trữ dữ liệu trong cơ sở dữ liệu, nhưng đảm bảo rằng BLOBS không được đọc cho đến khi chúng thực sự cần thiết, tức là không thực hiện "CHỌN * TỪ ..." trên các bảng có chứa blog. Và tôi sẽ đảm bảo rằng thiết kế giúp dễ dàng di chuyển dữ liệu ra khỏi cơ sở dữ liệu, vào hệ thống tập tin, nếu bạn gặp vấn đề về hiệu năng. Ví dụ: lưu trữ thông tin tệp trong một bảng Tệp riêng biệt , do đó giữ thông tin tệp cách xa các thực thể kinh doanh khác.

Giả sử rằng bạn có một lớp Tệp để biểu diễn một tệp được đọc trong cơ sở dữ liệu, thì tác động mã hóa của việc di chuyển nó sau này sẽ là tối thiểu.

Microsoft đã phát hành một tờ giấy trắng về điều này một vài năm trước. Nó tập trung vào SqlServer, nhưng bạn có thể tìm thấy một số thông tin thú vị trong đó:

Đến BLOB hay không BLOB? Lưu trữ đối tượng lớn trong cơ sở dữ liệu hoặc hệ thống tập tin?

Một phiên bản rất súc tích của kết luận của họ là:

Khi so sánh hệ thống tệp NTFS và SQL Server 2005, BLOBS nhỏ hơn 256KB được SQL Server xử lý hiệu quả hơn, trong khi NTFS hiệu quả hơn đối với BLOBS lớn hơn 1MB.

Tôi khuyên bạn nên viết một số thử nghiệm nhỏ cho trường hợp sử dụng cụ thể của bạn. Hãy nhớ rằng bạn phải cẩn thận với các hiệu ứng bộ đệm. (Tôi đã rất ngạc nhiên khi lần đầu tiên tôi có tốc độ lưu vào đĩa dường như có thông lượng cao hơn mức có thể thực hiện được!)

Sự khôn ngoan thông thường cũ của việc lưu trữ các tệp bên ngoài cơ sở dữ liệu có thể không còn giữ được nữa. Theo nguyên tắc, tôi thích sự toàn vẹn hơn tốc độ và với một DBMS hiện đại, bạn có thể có cả hai.

Tom Kyte dường như đồng ý :

Tôi biết không có lợi thế để lưu trữ dữ liệu tôi muốn giữ trong một thời gian dài bên ngoài cơ sở dữ liệu.

Nếu nó có trong cơ sở dữ liệu tôi có thể

hãy chắc chắn rằng nó được quản lý chuyên nghiệp

hỗ trợ

có thể phục hồi (với phần còn lại của dữ liệu)

bảo đảm

có thể mở rộng (thử đặt 100.000 tài liệu trong một thư mục, bây giờ, đặt chúng vào bảng - cái nào là 'tỷ lệ' - nó không phải là thư mục)

Tôi có thể phục hồi (hồi tưởng) một cách dễ dàng

Tôi có khóa

Tôi đã đọc tính nhất quán ...

Đúng.

Nếu bạn phục vụ một tệp từ hệ thống tệp của mình, máy chủ Web của bạn có thể sử dụng mã hạt nhân như sendfile () trên BSD hoặc Linux để sao chép tệp trực tiếp vào ổ cắm. Nó rất nhanh và rất hiệu quả.

Phục vụ các tệp ra khỏi cơ sở dữ liệu có nghĩa là bạn phải sao chép dữ liệu từ đĩa của máy chủ cơ sở dữ liệu vào bộ nhớ máy chủ cơ sở dữ liệu, sau đó từ bộ nhớ của máy chủ db sang cổng mạng của máy chủ db, sau đó từ mạng vào quy trình máy chủ Web của bạn, sau đó lại ra kết nối mạng đi.

Trừ khi bạn có lý do thực sự tốt để không, tốt hơn hết là phục vụ các tệp tĩnh từ hệ thống tệp.

Tom Kyte nổi tiếng đã viết rằng họ (Oracle) đang sử dụng cơ sở dữ liệu Oracle làm máy chủ tệp và nó hoạt động hoàn toàn tốt, thậm chí nhanh hơn hệ thống tệp bình thường, với đầy đủ giao dịch, không mất hiệu năng và với một lần sao lưu.

Có, nhưng lưu ý, họ là nhà sản xuất của Oracle DB và đối với bất kỳ người dùng nào khác, có vấn đề về chi phí. Sử dụng DB thương mại như Oracle để lưu trữ các tệp chỉ đơn giản là không hiệu quả.

Tuy nhiên, với PostgreSQL chẳng hạn, bạn chỉ có thể chạy một cá thể DB khác chỉ để lưu trữ blob. Bạn đã hỗ trợ giao dịch đầy đủ. Nhưng chi phí giao dịch không gian DB. Cần có cơ sở dữ liệu để lưu trữ nhiều phiên bản blob cho nhiều giao dịch đồng thời. Trên PostgreSQL, điều này là đau đớn nhất, vì cơ sở dữ liệu này lưu trữ các bản sao của các đốm được thực hiện cho giao dịch được lưu trữ ngay cả khi chúng không còn cần thiết nữa, cho đến khi quá trình VACUUM được thực hiện.

Mặt khác, với lưu trữ hệ thống tệp, bạn phải hết sức cẩn thận khi ai đó sửa đổi tệp, vì giao dịch có thể được khôi phục và bản sao của tệp phải được giữ cho đến khi phiên bản cũ không còn hiển thị.

Trong hệ thống nơi các tệp chỉ được thêm và xóa và truy cập giao dịch vào các tệp không phải là vấn đề, bộ lưu trữ hệ thống tệp sẽ là IMHO sự lựa chọn tốt nhất.

Thông thường tốt nhất là lưu trữ các BLOB lớn trong một bảng riêng biệt và chỉ cần giữ một tham chiếu khóa ngoài đến BLOB trong bảng chính của bạn. Bằng cách đó, bạn vẫn có thể truy xuất tệp từ cơ sở dữ liệu (vì vậy bạn không cần bất kỳ mã đặc biệt nào) và bạn tránh các vấn đề xung quanh các phụ thuộc DB bên ngoài (giữ DB và hệ thống tệp đồng bộ hóa, v.v.), nhưng bạn chỉ phải chịu chi phí đó nếu bạn rõ ràng tham gia vào bảng đó (hoặc thực hiện một cuộc gọi riêng). 10MB không phải là quá lớn, hầu hết các cơ sở dữ liệu thương mại hiện đại sẽ không có vấn đề gì. Lý do duy nhất tôi lưu trữ một tệp trong hệ thống tệp là để cắt giảm băng thông cơ sở dữ liệu. Nếu cơ sở dữ liệu của bạn sẽ xáo trộn rất nhiều các tệp này, thì bạn có thể cần phải phân chia khối lượng công việc và chỉ lưu trữ một mô tả tệp thuộc loại nào đó. Sau đó, bạn có thể có một cuộc gọi riêng để tải tệp từ máy chủ khác,

Bạn có thể gặp phải một số vấn đề này:

• Làm một SELECT *việc liên quan đến hàng với blob lớn mất rất nhiều thời gian, ngay cả khi bạn không cần blob (Tất nhiên bạn nên thực hiện một lựa chọn cụ thể, nhưng đôi khi các ứng dụng được viết như thế này)
• Làm một bản sao lưu có thể mất nhiều thời gian hơn. Tùy thuộc vào nhu cầu của bạn, bạn có thể cần phải khóa các bảng của mình trong thời gian sao lưu, vì vậy bạn có thể muốn giữ thời gian sao lưu của mình ở mức thấp
• Khôi phục cũng sẽ mất nhiều thời gian hơn.
• Nếu bạn hết dung lượng, bạn phải nghĩ ra một cách nào đó (có thể di chuyển toàn bộ cơ sở dữ liệu sang một máy chủ mới) để giải quyết vấn đề này. Lưu trữ các tệp trên hệ thống tệp, bạn luôn có thể gắn ổ đĩa cứng khác và đặt liên kết mềm.
• Đơn giản chỉ cần nhìn vào một tập tin để gỡ lỗi hoặc thông tin khác là không dễ dàng. Điều này cũng bao gồm các tập lệnh có thể không có quyền truy cập vào cơ sở dữ liệu nhưng cần một số thông tin từ các tệp khác nhau.

Tất nhiên bạn cũng nhận được một số lợi ích:

• Sao lưu dữ liệu và tệp menas chúng được đồng bộ hóa
• Loại bỏ các tập tin mà không có cơ sở dữ liệu biết là không thể
• Bạn không cần phải đọc tệp từ đĩa nhưng có thể làm điều đó trong một câu lệnh sql
• Bạn có thể tải xuống cơ sở dữ liệu, bao gồm kết xuất vào môi trường phát triển của bạn và có tất cả các phụ thuộc ngay tại đó

Cá nhân tôi không làm điều đó vì tôi thấy khuyết điểm nặng hơn nhiều so với ưu điểm. Nhưng như đã nêu ở trên, nó hoàn toàn phụ thuộc vào trường hợp sử dụng của bạn và như vậy.

Một số Hệ thống quản lý nội dung Enterpirse, như SiteCore, đang sử dụng một cơ sở dữ liệu để lưu trữ dữ liệu trang và cơ sở dữ liệu khác để lưu trữ tệp. Họ đang sử dụng MS SQL Server.

Để thực hiện thực tế, đây là những gì bạn có thể quan tâm:

Lợi ích:

1. Tất cả nội dung tập tin chắc chắn được đồng bộ hóa với bảng của bạn. Như các ý kiến ​​trên đã nói, sao lưu dữ liệu hoàn toàn thuận tiện vì bạn không cần phải giữ dữ liệu được đồng bộ hóa với hệ thống tệp.
2. Từ mã hóa, bạn có thể lấy nội dung tệp trực tiếp từ SQL chọn.
3. Từ một truy vấn, bạn thậm chí có thể lọc nội dung tệp hoặc kích thước của nó một cách rõ ràng từ câu lệnh SQL.

Nhược điểm:

1. So với một cơ sở dữ liệu có cấu trúc giống nhau về mặt ngữ nghĩa nhưng không lưu trữ nội dung tệp, cơ sở dữ liệu của bạn có xu hướng tiêu thụ nhiều bộ nhớ hơn khi thực hiện truy vấn.
2. Tự động sao lưu có thể gây ra vấn đề hiệu suất nhưng không nhiều. Hãy tưởng tượng máy chủ cơ sở dữ liệu của bạn đang sao lưu mọi thứ cứ sau 6 giờ và những cơ sở dữ liệu mà bạn có đang lưu trữ tệp 10 MB cho mỗi bản ghi. Kịch bản đó không phải là điều bạn muốn.