Nơi tốt nhất để lưu trữ các tệp nhị phân có liên quan đến dữ liệu trong cơ sở dữ liệu của bạn là gì? Bạn có nên:

1. Lưu trữ trong cơ sở dữ liệu với một đốm màu
2. Lưu trữ trên hệ thống tập tin với một liên kết trong cơ sở dữ liệu
3. Lưu trữ trong hệ thống tệp nhưng đổi tên thành hàm băm của nội dung và lưu trữ hàm băm trên cơ sở dữ liệu
4. Một cái gì đó tôi không nghĩ đến

Ưu điểm của (1) là (trong số những thứ khác) rằng tính nguyên tử của các giao dịch được bảo tồn. Chi phí là bạn có thể tăng đáng kể các yêu cầu về lưu trữ (và liên kết / sao lưu)

Mục tiêu của (3) là duy trì tính nguyên tử ở một mức độ nào đó - nếu bạn có thể thực thi rằng hệ thống tệp bạn đang viết không cho phép các tệp bị thay đổi hoặc bị xóa và luôn có hàm băm chính xác như tên tệp. Ý tưởng sẽ là ghi tệp vào hệ thống tệp trước khi cho phép chèn / cập nhật tham chiếu hàm băm - nếu giao dịch này thất bại sau khi hệ thống tệp ghi nhưng trước cơ sở dữ liệu DML, điều đó tốt vì hệ thống tệp đang 'giả mạo' là kho lưu trữ của tất cả các tệp và băm có thể - không thành vấn đề nếu có một số tệp trong đó không được trỏ đến (và bạn có thể dọn sạch chúng định kỳ nếu bạn cẩn thận)

BIÊN TẬP:

Có vẻ như một số RDBMS có điều này được trình bày theo cách riêng của họ - tôi rất muốn biết những người khác làm điều đó như thế nào - và đặc biệt là trong một giải pháp cho các postgres

1. Lưu trữ trong cơ sở dữ liệu với một đốm màu

   Một bất lợi là nó làm cho các tệp cơ sở dữ liệu của bạn khá lớn và có thể quá lớn để sao lưu với thiết lập hiện tại của bạn. Một lợi thế là tính toàn vẹn và nguyên tử.

2. Lưu trữ trên hệ thống tập tin với một liên kết trong cơ sở dữ liệu

   Tôi đã gặp những thảm họa khủng khiếp như vậy khi làm điều này, và nó làm tôi sợ rằng mọi người cứ gợi ý nó. Một số thảm họa bao gồm:

   • Một người dùng đặc quyền sẽ sắp xếp lại các tệp và thường xuyên phá vỡ các liên kết giữa các đường dẫn trong DB và nơi chúng hiện tại (nhưng bằng cách nào đó, đây đã trở thành lỗi của tôi).
   • Khi chuyển từ máy chủ này sang máy chủ khác, quyền sở hữu một số tệp bị mất do SID cho tài khoản quản trị viên của máy cũ (trang web cũ đang chạy) không phải là một phần của miền và do đó, các tệp được sao chép có ACL có thể không được giải quyết do đó trình bày cho người dùng lời nhắc đăng nhập tên người dùng / mật khẩu / tên miền.
   • Một số đường dẫn cuối cùng dài hơn 256 ký tự từ C:\đường đến .docvà không phải tất cả các phiên bản NT đều có thể xử lý các đường dẫn dài.

3. Lưu trữ trong hệ thống tệp nhưng đổi tên thành hàm băm của nội dung và lưu trữ hàm băm trên cơ sở dữ liệu

   Nơi cuối cùng tôi làm việc này dựa trên lời giải thích của tôi về các tình huống trên đã làm điều này. Họ nghĩ rằng đó là một sự thỏa hiệp giữa việc tổ chức không có kinh nghiệm với cơ sở dữ liệu lớn (bất cứ thứ gì lớn hơn khoảng 40G đều được coi là "quá lớn"), công ty không có khả năng mua ổ cứng lớn và không có khả năng mua một thiết bị hiện đại hơn đưa ra giải pháp và sự cần thiết phải tránh xa rủi ro # 1 & # 3 mà tôi đã xác định ở trên.

Ý kiến ​​của tôi là lưu trữ trong DB dưới dạng blob là một giải pháp tốt hơn và có khả năng mở rộng hơn trong một kịch bản đa máy chủ, đặc biệt là với các mối quan tâm về chuyển đổi dự phòng và khả dụng.

Số 1 cho toàn vẹn dữ liệu. Sử dụng các tùy chọn khác nếu bạn không quan tâm đến chất lượng dữ liệu. Nó đơn giản mà.

Hầu hết RDBMS đều có tối ưu hóa để lưu trữ BLOB (ví dụ: SQL Server filestream)

Nếu đi tìm orory, hãy xem dbfs và Secure Files.

Tệp bảo mật nói lên tất cả, giữ TẤT CẢ dữ liệu của bạn an toàn trong cơ sở dữ liệu. Nó được tổ chức trong thùy. Secure Files là phiên bản hiện đại hóa của thùy, cần được kích hoạt.

dbfs là một hệ thống tập tin trong cơ sở dữ liệu. Bạn có thể gắn kết nó tương tự như hệ thống tệp mạng, trên máy chủ Linux. Nó thực sự mạnh mẽ. Xem blog Nó cũng có rất nhiều tùy chọn để điều chỉnh theo nhu cầu cụ thể của bạn. Là một dba, được cung cấp một hệ thống tệp (dựa trên cơ sở dữ liệu, được gắn trên Linux), tôi đã tạo Cơ sở dữ liệu Oracle trên đó mà không gặp vấn đề gì. (cơ sở dữ liệu, được lưu trữ trong ... cơ sở dữ liệu). Không phải điều này sẽ rất hữu ích nhưng nó cho thấy sức mạnh.

Nhiều lợi thế hơn là: sẵn có, sao lưu, phục hồi, tất cả đều đọc phù hợp với các dữ liệu quan hệ khác.

Đôi khi kích thước được đưa ra như một lý do để không lưu trữ tài liệu trong cơ sở dữ liệu. Dữ liệu đó có thể phải được sao lưu bằng mọi cách để đó không phải là lý do chính đáng để không lưu trữ trong cơ sở dữ liệu. Đặc biệt trong một tình huống mà các tài liệu cũ chỉ được xem là chỉ đọc, thật dễ dàng để làm cho các phần lớn của cơ sở dữ liệu chỉ đọc. Trong trường hợp đó, những phần của cơ sở dữ liệu không còn cần phải sao lưu thường xuyên nữa.

Một tham chiếu trong bảng tới một cái gì đó bên ngoài cơ sở dữ liệu là không an toàn. Nó có thể bị thao túng, khó kiểm tra và có thể dễ dàng bị mất. Làm thế nào về giao dịch? Cơ sở dữ liệu cung cấp giải pháp cho tất cả các vấn đề này. Với Oracle DBFS, bạn có thể cung cấp tài liệu của mình cho các ứng dụng không phải là cơ sở dữ liệu và họ thậm chí sẽ không biết họ đang chọc vào cơ sở dữ liệu.

Một điều ngạc nhiên cuối cùng, hiệu năng của hệ thống tệp dbfs thường tốt hơn hệ thống tệp thông thường. Điều này đặc biệt đúng nếu các tệp lớn hơn một vài khối.

Tôi nghĩ rằng câu trả lời đúng ở đây phụ thuộc rất nhiều vào ứng dụng của bạn và tầm quan trọng của những tài liệu đó.

Đối với hệ thống quản lý tài liệu hoặc hệ thống có khả năng phục hồi các tài liệu được lưu trữ là rất quan trọng (vì vậy hầu hết mọi thứ liên quan đến tài chính, nhân sự hoặc CRM), lưu trữ tài liệu nội tuyến hoặc sử dụng công nghệ tài liệu độc quyền của nhà cung cấp DB yêu thích của bạn có vẻ như Quyền phải làm.

Tuy nhiên, có nhiều ứng dụng mà tôi tin rằng quyết định ngược lại là phù hợp.

Các hệ thống trợ giúp và các hệ thống kiểu wiki là những hệ thống mà tôi nghĩ nó có ý nghĩa rất lớn để giữ dữ liệu ra khỏi cơ sở dữ liệu. Tôi tin rằng một số, như Jira, thực sự cung cấp một tùy chọn để chọn xem bạn có muốn lưu trữ tài liệu nội tuyến hay không.

Đối với một doanh nghiệp có quy mô trung bình, việc lưu trữ tài liệu cho hệ thống bán vé nội tuyến có thể có nghĩa là sự khác biệt giữa một bản sao lưu nén được đo bằng megabyte và một tài liệu được đo bằng gigabyte.

Cá nhân tôi muốn đưa hệ thống bán vé trở lại trực tuyến sau vài phút và vật lộn với các tài liệu (nói chung ít quan trọng hơn) trong vài giờ, hơn là tăng "nó bị hỏng và CTO đang thở dốc" RTO bằng cách khôi phục và phát lại các bản ghi từ một bản sao lưu lớn hơn nhiều.

Có những lợi ích khác của việc giữ tài liệu riêng biệt.

• Bạn có thể dễ dàng chạy các quy trình riêng biệt để phân loại siêu dữ liệu tài liệu, thực hiện quét vi-rút, thực hiện lập chỉ mục từ khóa, v.v.
• Bạn có thể tận dụng các công cụ để hỗ trợ sao lưu hoặc khôi phục - rsync, ảnh chụp lưu trữ, v.v. - cho vay bản thân tốt hơn nhiều cho các tệp so với cơ sở dữ liệu
• Bạn thực sự có thể sử dụng bộ lưu trữ hỗ trợ nén hoặc sao chép (nội dung mà quản trị viên SAN của bạn đã làm mờ trong nhiều năm, hay còn gọi là nguyên nhân của các quản trị viên cơ sở dữ liệu trên toàn thế giới)
• Để cài đặt trên nhiều trang web, bạn có thể bổ sung cơ sở dữ liệu tập trung bằng hệ thống tệp phân tán

Tôi nghĩ rằng sự kết hợp lai giữa # 2 và # 3 có thể là thông minh. Giữ tên tệp gốc, nhưng tính toán và lưu trữ hàm băm / tổng kiểm tra của tài liệu để bạn có một số điểm tham chiếu sẽ hỗ trợ khôi phục trong trường hợp ai đó di chuyển hoặc đổi tên tệp.

Lưu trữ các tệp với tên tệp gốc của chúng có nghĩa là các ứng dụng có thể lấy chúng trực tiếp từ hệ thống tệp và gửi chúng qua dây hoặc trong thế giới máy khách dày, thậm chí có thể trỏ người dùng trực tiếp đến máy chủ tệp.

Đừng làm điều đó.

Thực sự không có một mặt trái nào để có các tệp được lưu trữ trong cơ sở dữ liệu.

Không phải nó đã cảm thấy kỳ lạ và tanh khi bạn nghĩ cho chính mình:

Tôi nên lưu trữ các tệp trong cơ sở dữ liệu hoặc hệ thống tệp ?

Thậm chí tốt hơn, nói ra thành tiếng.

Về sự thật:

Sử dụng cơ sở dữ liệu

" PROS " ... nhưng không hoàn toàn :

• "Nguyên tử" là chính xác nhưng nó là con dao hai lưỡi. Bởi vì nó kéo nhược điểm cùng với nó.
• Chính trực. Giống như trên.

Tôi thực sự không muốn bị thiên vị nhưng tôi không nghĩ có thêm điều gì để thêm vào. Ưu điểm không thực sự tuyệt vời nếu bạn nghĩ về nó.

Nếu tôi quên một cái gì đó bình luận bên dưới, trong khi đó hãy tiếp tục đọc bên dưới.

Nhược điểm:

• Công cụ sai cho công việc
• Khó bảo trì hơn
• Chậm
• Hãy quên việc lưu trữ hàng trăm MB / gigabyte dữ liệu người dùng PER .
• Sao lưu các trang web đang phát triển nhanh chóng sẽ là một cơn ác mộng.
• Khôi phục / di chuyển cũng sẽ hút.

Sử dụng hệ thống tập tin

PROS:

• Cách dễ dàng hơn để duy trì
• Nhanh
• Sao lưu cơ sở dữ liệu không có gì để làm với điều này
• Tính di động cao hơn *

Nhược điểm :

• Không ai*

*Bản in đẹp

Ngay bây giờ bạn đang tự hỏi chính mình, giữ bạn có nghĩa là không có khuyết điểm?! Làm thế nào mà?

Những sai lầm lớn nhất ở đây là mọi người đang cố gắng vặn ốc vít bằng búa.

Nguyên nhân chủ yếu và tôi muốn đi xa để nói chỉ vì lý do này đã được hỏi là vì các liên kết tập tin .

Đây là một vấn đề mà cơ sở dữ liệu không có nghĩa là phải giải quyết. Nó thậm chí nghe có vẻ ngớ ngẩn nếu bạn nghĩ về nó.

"Cơ sở dữ liệu sẽ khắc phục sự cố liên kết tệp của tôi."

Khi trong thực tế, ứng dụng thực sự phải chịu trách nhiệm xử lý và phục vụ các liên kết.

Một giải pháp:

1. Làm cho ứng dụng của bạn xử lý các yêu cầu URL với các tuyến tùy chỉnh.
2. Lưu tuyến đường này vào cơ sở dữ liệu của bạn.
3. Bên trong mỗi khi tuyến đường này được gọi là ánh xạ tới tệp bạn muốn.
4. Nếu bạn từng di chuyển các tệp của mình đi nơi khác, chỉ cần thay đổi giá trị tên tệp của tuyến và tuyến đó sẽ luôn phục vụ cùng một tệp cho dù nó được lưu trữ hoặc được tham chiếu trên web ở đâu.

Điều này cũng sẽ trừu tượng hóa các đường dẫn riêng, làm cho ứng dụng dễ di chuyển hơn, có thể bảo trì và cho phép chuyển sang bất kỳ loại hệ thống tập tin nào mà không phá vỡ bất cứ điều gì.

Về cách thực hiện nó nằm ngoài phạm vi của câu trả lời này, nhưng bạn có thể xem một ví dụ chung bằng ngôn ngữ web được sử dụng rộng rãi nhất (PHP):

https://github.com/symfony/Routing

https://github.com/kriswallsmith/assetic

Cả hai cùng nhau thực sự mạnh mẽ.

Tôi muốn thêm kinh nghiệm của tôi ở đây để đánh đổi. Trong PostgreSQL, ít nhất, các tác động hiệu năng khá tối thiểu về mặt máy chủ db. Các đốm màu lớn được lưu trữ trong các tệp riêng biệt, không phải trong các bảng heap chính để di chuyển chúng ra khỏi cách hoạt động có thể đếm số lượng lớn các bản ghi. Các dbs khác có thể làm một cái gì đó tương tự.

Ưu điểm chính là khả năng giữ tất cả dữ liệu liên quan ở một nơi cho mục đích nguyên tử và sao lưu. Điều này làm giảm đáng kể khả năng xảy ra sự cố.

Nhược điểm lớn không phải là cái tôi đã thấy ở trên, và đó là việc sử dụng bộ nhớ ở mặt trước. Tôi không biết chính xác làm thế nào mọi db xử lý việc này để điều này có thể phụ thuộc vào việc triển khai nhưng đối với PostgreQuery, dữ liệu được đưa vào dưới dạng một chuỗi ASCII đã thoát (có thể là thập lục phân, có thể có các lối thoát được nội tuyến). Điều này sau đó phải được chuyển đổi trở lại thành nhị phân ở mặt trước. Nhiều khung tôi đã thấy để thực hiện điều này liên quan đến việc chuyển giá trị (không phải là tham chiếu) và sau đó xây dựng một chuỗi nhị phân mới dựa trên nó. Tôi đã tính toán rằng sử dụng Perl để làm điều này đã kết thúc bằng cách sử dụng nhiều lần bộ nhớ của nhị phân ban đầu để thực hiện.

Phán quyết: Nếu các tệp chỉ thỉnh thoảng được truy cập, tôi sẽ lưu trữ trong db. Nếu chúng được truy cập thường xuyên và liên tục, ít nhất là với PostgreSQL, tôi nghĩ rằng chi phí vượt xa lợi ích.

Trước đây, Microsoft đã tăng cường khả năng lưu trữ hình ảnh (và các loại dữ liệu blob tương tự) trong cơ sở dữ liệu. Đây là một tính năng mới thú vị của SQL Server 2000 (tôi khá chắc chắn đó là 2000 chứ không phải 7.0) và nhiều người đã nhảy vào bandwagon.

Lưu trữ BLOBS trong cơ sở dữ liệu có những ưu điểm và nhược điểm:

Một mặt, tất cả dữ liệu và hình ảnh hoặc tài liệu liên quan của bạn có thể được lưu trữ và truy cập ở một nơi. Người dùng ứng dụng không yêu cầu quyền truy cập mạng đặc biệt, vì đó là SQL đang phục vụ hình ảnh / tệp / tài liệu.

Mặt khác, cơ sở dữ liệu của bạn có thể phát triển khá lớn, tùy thuộc vào kích thước và số lượng BLOBS bạn đang lưu trữ. Điều này ảnh hưởng đến sao lưu, yêu cầu lưu trữ, hoạt động phục hồi nhạy cảm với thời gian, v.v.

SQL Server 2008 giới thiệu truyền phát tệp. Cơ sở dữ liệu chứa con trỏ tới các tệp, các tệp nằm trên máy chủ không có trong cơ sở dữ liệu, nhưng khi bạn sao lưu cơ sở dữ liệu, các tệp cũng được sao lưu.

Các bản sao lưu của bạn có thể trở nên khá lớn, nhưng bạn không kết thúc với các tệp / tài liệu / blobs / hình ảnh mồ côi.

Sở thích cá nhân của tôi là để cho cơ sở dữ liệu lưu trữ các con trỏ / vị trí mạng và để một máy chủ tệp xử lý các tệp. Máy chủ tập tin được tối ưu hóa tốt hơn cho các nhiệm vụ như vậy dù sao.

Không lưu trữ tệp trong cơ sở dữ liệu.

Mọi người, không có ngoại lệ, có thể chạy bất kỳ RDBMS nào trên thị trường đã có cơ sở dữ liệu đặc biệt để lưu trữ các tệp và chính RDBMS đang sử dụng nó! Cơ sở dữ liệu đó là hệ thống tập tin . Bây giờ hãy nói về một số nhược điểm tiềm năng của việc lưu trữ tệp trong cơ sở dữ liệu, cũng như một số yếu tố giảm thiểu cụ thể để lưu trữ tệp trong cơ sở dữ liệu.

• Không filehandes đến tập tin trong cơ sở dữ liệu. Điều đó có nghĩa là gì?

  • Lập trình viên nói chuyện: Bạn KHÔNG THỂ tìm kiếm ( fseek), không có khả năng quản lý tài nguyên với quyền truy cập không đồng bộ ( asynciohoặc epoll), không có sendfile(tiết kiệm cho bạn bản sao từ không gian kernel).

  • Ứng dụng thực tế: Bạn muốn gửi video hoặc hình ảnh cho khách hàng qua HTTP2 / 3? Nếu nó có trong cơ sở dữ liệu, thì trước tiên bạn sẽ phải truy vấn nó. Đối với bất kỳ truy vấn nào trả về tệp đó, bạn sẽ phải đợi toàn bộ truy vấn kết thúc trước khi tệp đó có thể chuyển sang bước tiếp theo. Trong sản xuất cài đặt với một RDBMS trên một máy chủ khác với máy chủ web, bạn sẽ lần đầu tiên phải chuyển hồ sơ hoàn toàn từ rdbms đến webserver chứ không phải là truyền nó qua. Tuy nhiên, nếu lớp vận chuyển cung cấp sự trừu tượng hóa hệ thống tệp (mà thậm chí NFS hỗ trợ), bạn có thể tìm kiếm một nửa thông qua tệp và ngay lập tức bắt đầu truyền nó trở lại máy khách mà không cần đệm thêm tệp nào cần thiết. Điều này được thực hiện thường xuyên bởi máy chủ webnginx , Apache , PureFTP và ProFTP.

• Sao chép đôi trên RDBMS. Bởi thực tế là nó có trong cơ sở dữ liệu, bạn có thể sẽ viết nó hai lần. Một lần trong một bản ghi viết trước (WAL), và sau đó một lần nữa vào không gian bảng.

• Không có bản cập nhật, bao giờ MVCC có nghĩa là không có gì được cập nhật, chỉ được sao chép một lần nữa với các sửa đổi và sau đó hàng cũ được đánh dấu là hết hạn (đã xóa). Bất kỳ cập nhật nào cho tệp, sẽ yêu cầu ghi toàn bộ hàng , không chỉ tệp toàn bộ hàng. Hệ thống tập tin cũng có thể cung cấp điều này, với nhật ký dữ liệu nhưng bạn hiếm khi cần điều đó.

• Đọc và chuyển tệp để làm chậm truy vấn Nếu chính tệp được lưu trữ trên một hàng mà bạn cần truy vấn, toàn bộ hàng sẽ phải đợi tệp được chuyển hoặc bạn sẽ phải đưa ra hai truy vấn riêng .

• Sử dụng bộ nhớ trên máy khách DB. DB-client (libpq, jdbc, odbc, freetds, v.v.) hoặc tương tự sẽ có khả năng đệm truy vấn trong bộ nhớ. Khi bộ đệm trong bộ nhớ đó cạn kiệt, nó có thể khởi động bộ đệm đĩa hoặc tệ hơn nữa là nó có thể rơi trở lại kernel để được phân trang vào đĩa.

• Truy vấn điều tiết nhiều cơ sở dữ liệu cung cấp khả năng tiêu diệt và gặt các truy vấn khi chúng chiếm quá nhiều thời gian hoặc tài nguyên. Hãy nhớ rằng việc chuyển tập tin sẽ không được thực hiện trong bất kỳ triển khai nào. Có phải truy vấn đó đã bị giết sau 3 giây? Hoặc phải mất 1 giây và phần phụ trợ đã mất 2 giây để truyền tệp? Không chỉ "ghi thành từng mục", bạn sẽ nêu rõ hiệu quả của một truy vấn sẽ mất bao nhiêu thời gian khi 99,9% truy vấn trả về 1 KB và truy vấn còn lại trả về 1 GB?

• Không sao chép trên ghi hoặc khử trùng lặp XFS và BTRFS hỗ trợ sao chép trên ghi và khử trùng lặp trong suốt. Điều này có nghĩa là có cùng một hình ảnh ở khắp mọi nơi hoặc cần một bản sao thứ hai của nó có thể được xử lý trong suốt bởi hệ thống tập tin. Tuy nhiên, nếu tệp không đứng một mình và nằm trên một hàng hoặc trong một cửa hàng, hệ thống tệp có khả năng không thể khấu trừ nó.

• Tính toàn vẹn rất nhiều người ở đây đang nói về tính toàn vẹn. Bạn nghĩ gì tốt hơn trong việc phát hiện tham nhũng hệ thống tệp, một ứng dụng sử dụng các tiện ích cốt lõi của hệ thống tệp hoặc hệ thống tệp? Lưu trữ một tệp liên tiếp hoặc ngoài dòng và bất kỳ tham nhũng hệ thống tệp nào sẽ bị che khuất cơ sở dữ liệu. xfs_repairPhục hồi rất tốt khi bạn bị hỏng hệ thống tập tin hoặc ổ cứng, và nếu thất bại, việc làm pháp y dữ liệu sẽ dễ dàng hơn rất nhiều.

• Di chuyển đám mây nếu bạn muốn lưu trữ các tệp trên SAN hoặc đám mây, bạn sẽ gặp nhiều khó khăn hơn bởi vì bây giờ di chuyển lưu trữ là di chuyển cơ sở dữ liệu. Nếu các tệp của bạn chẳng hạn được lưu trữ trên hệ thống tệp, bạn hoàn toàn có thể dễ dàng di chuyển chúng sang S3 (và với thứ gì s3fsđó có thể trong suốt).

Ngoại lệ

Lưu trữ các tệp trong cơ sở dữ liệu có một vài trường hợp sử dụng hợp lệ,

• Khi bạn cần chỉnh sửa tập tin chuyển tiếp. Điều đó có nghĩa là nó thực sự là một phần của giao dịch của bạn để chỉnh sửa tệp. Hoặc bạn cần có khả năng khôi phục lại các chỉnh sửa trên tệp nếu giao dịch không thành công đối với các vấn đề toàn vẹn dữ liệu trong các mối quan hệ (bảng).
• Khi bạn cần đảm bảo hệ thống tệp được phiên bản chính xác với dữ liệu và bạn không thể chịu bất kỳ rủi ro nào trong việc giữ chúng đồng bộ.
• Khi bạn cơ sở dữ liệu thực sự có thể phân tích cú pháp tệp và bạn có thể truy vấn nó. Ví dụ, trong PostgreSQL, các cấu trúc liên kết có thể là các truy vấn với PostGIS. Tại thời điểm này, trong khi đó là một tệp, nó cũng là dữ liệu cho truy vấn và không phải là kết xuất lưu trữ.

Giảm nhẹ

• Một số cơ sở dữ liệu có khái niệm "tài nguyên được quản lý bên ngoài" trong đó cơ sở dữ liệu sẽ quản lý tệp riêng tư trên đĩa, chẳng hạn như

  • PostgreQuery thông qua cơ sở hạ tầng Đối tượng lớn cung cấp một tệp tài nguyên cho một tài nguyên trong suốt thời gian giao dịch.

  • Cơ sở hạ tầng filestream của SQL Server 2017 cung cấp quyền truy cập tạm thời kéo dài trong suốt thời gian giao dịch mà bạn có thể sử dụng để nhận Đường dẫn tệp và mở Xử lý tệp.

  • Oracle cung cấp BFILE(điều này không liên quan gì đến công cụ LOB nội bộ của họ được gọi làSecureFile

• Một số cơ sở dữ liệu lưu trữ các đối tượng nhị phân lớn ngoài luồng hoặc có thể, như Oracle SecureFile. Điều này cho phép bạn cập nhật hàng, mà không cần viết lại tệp.

• Một số cơ sở dữ liệu như Oracle thực hiện MVC mà không có nhật ký WAL và không phải tăng gấp đôi - ghi tệp.

• Một số cơ sở dữ liệu, như SQL Server và Oracle cung cấp khả năng "truyền phát" dữ liệu từ tệp mà không cần phải xử lý tệp. Điều này có thể hoặc không thể chạy trên một kết nối khác với truy vấn databaes. Nhưng mấu chốt ở đây là trong khi bạn có thể truyền phát tệp (về lý thuyết), tôi không thể tìm thấy bất kỳ bằng chứng nào về bất kỳ sản phẩm nào không được cung cấp bởi nhà cung cấp sử dụng tính năng đó. Ví dụ, cầu NGINX / Apache ở đâu để cho phép bạn làm điều này?

• Oracle cung cấp tùy chọn sao chép, nén và mã hóa thông qua lưu trữ Internal-LOB (như SecureFile).

Phần kết luận

Trường hợp xấu nhất khi bạn đặt một tệp vào cơ sở dữ liệu là rất tệ cho hiệu năng và khả năng tương thích với công cụ. Nó luôn luôn thực hiện phụ thuộc đặc biệt. Không có cách nào là cơ sở dữ liệu tốt hơn là một hệ thống tệp sau đó là hệ thống tệp. Theo mọi cách, đó là một sự thỏa hiệp và ngay cả khi bạn có các tính năng giảm thiểu mạnh mẽ (như trường hợp của SecureFile), công cụ rất kém đến nỗi nó thực sự không khác gì một điểm tiếp thị trừ khi toàn bộ ngăn xếp của bạn được cung cấp bởi nhà cung cấp RDBMS.

Giữ cho nó đơn giản và quy tắc chung là giữ các tệp ra khỏi DB .

Giải pháp

Làm thế nào bạn nên lưu trữ các tệp, hoặc trừu tượng một hệ thống tệp theo cách như vậy để hoạt động hiệu quả cho nhiều người thuê và người dùng? Tôi là một phần để băm nội dung tập tin. Điều này là khá phổ biến những ngày này và hoạt động tốt.

Mặc dù nó một phần phụ thuộc vào ứng dụng / môi trường (bao gồm mọi người), tôi sẽ tìm kiếm blob.

Giữ mọi thứ trong cơ sở dữ liệu có nghĩa là sao chép hoạt động cho dữ liệu tệp. Bạn sẽ cần một cơ chế riêng để đồng bộ hóa các tệp FS.

Trong một số ứng dụng, hệ thống tập tin không nên được sửa đổi. Ví dụ: trên một trang web sản xuất, tôi sẽ tránh sử dụng hệ thống tập tin cho bất kỳ dữ liệu không dùng một lần nào (trang web nằm dưới SCM, dữ liệu trong cơ sở dữ liệu).

Giả sử chúng ta có nhiều người dùng / ứng dụng với các quyền riêng biệt, thì bất kỳ bộ lưu trữ hệ thống tệp nào cũng cung cấp cơ hội cho sự khác biệt về quyền truy cập DB và FS.

Việc sàng lọc mà tôi xem xét thực hiện đối với lưu trữ BLOB là phân đoạn dữ liệu nếu nó có ý nghĩa; nếu bạn chỉ cần 512 byte từ BLOB 20Mb, quyền truy cập giống như khu vực này là một lợi ích thực sự, đặc biệt nếu bạn đang xử lý các máy khách từ xa (và một lần nữa, cập nhật một phần sẽ tạo ra lưu lượng truy cập sao chép ít hơn nhiều).

Phiếu bầu của tôi sẽ không dành cho cả. Lưu trữ dữ liệu trong một hệ thống như Amazon S3 hoặc microsft's CDN và lưu URL đó trong cơ sở dữ liệu.

Bằng cách này, bạn có được độ tin cậy của việc dữ liệu luôn có thể truy cập mà không cần phải xử lý các cơ sở dữ liệu có kích thước khổng lồ.

Đối với bưu điện:

Đó thực sự là lời nói đầu. Có một BYTEAloại có thể được sử dụng để lưu trữ chuỗi nhị phân. Theo mặc định, không có bản dựng nào được sử dụng như các ứng dụng được đề cập cho MS hoặc Oracle. Vì vậy, lưu trữ nhiều tệp lớn và truy xuất chúng có thể trở nên tẻ nhạt. Bạn cũng cần thực hiện chuyển đổi các tệp trong ứng dụng (như với một ByteStreamhoặc tương tự, không biết mặc dù cách này hoạt động với tệp MS / Oracle cụ thể <-> giải pháp cơ sở dữ liệu). Ngoài ra còn có một loloại, giúp cho công việc quản lý BLOB vì một số quản lý nội bộ của các loại này có thể không theo dõi các tài liệu tham khảo.

Chia sẻ kinh nghiệm của tôi về máy chủ Ms SQL và một số lượng lớn tệp. Chúng tôi lưu các tập tin trên một máy chủ tập tin. Cơ sở dữ liệu có hai bảng, một cho các thư mục tệp và thông tin truy cập, một cho tên tệp. Nó rất dễ dàng để duy trì cơ sở dữ liệu và các tập tin. Bạn có thể dễ dàng di chuyển các tập tin thậm chí qua các máy chủ, chỉ cần sửa đổi bảng thư mục.