2009-02-04 31 views
17

Bối cảnh:Vị trí được đề xuất để lưu trữ tài liệu - trong cơ sở dữ liệu hoặc ở nơi khác?

Chúng tôi có hệ thống lưu trữ tài liệu trong nhà được triển khai từ lâu. Vì lý do gì, sử dụng cơ sở dữ liệu như cơ chế lưu trữ cho các tài liệu đã được chọn.

Câu hỏi của tôi là thế này:

các thực hành tốt nhất để lưu trữ tài liệu là gì? Các lựa chọn thay thế là gì? Những ưu và khuyết điểm là gì? Các câu trả lời không nhất thiết phải là công nghệ hay nền tảng cụ thể, nó là một câu hỏi thực hành tốt nhất chung.

Suy nghĩ của tôi:

Cơ sở dữ liệu không có nghĩa là để lưu trữ tài liệu. Hệ thống tệp hoặc hệ thống quản lý tài liệu của bên thứ ba có thể sử dụng tốt hơn. Lưu trữ tài liệu trong Cơ sở dữ liệu là tốn kém. Hoạt động chậm. Có phải những giả định logic này không? Có lẽ điều này là tốt nhất, nhưng trong tâm trí của tôi, chúng tôi có lựa chọn thay thế tốt hơn. Có thể oracle BFILE của (liên kết đến tài liệu trên NAS hoặc SAN) được tốt hơn so với BLOB/CLOB?

chi tiết:

  • Documents nhiều loại khác nhau (pdf, word, xml)
  • Mã Trung Tier được viết bằng .net 2.0/C#
  • Các tài liệu được lưu trữ trong một 10g Oracle cơ sở dữ liệu trong BLOB với nén (Lưu trữ NAS)
  • Kích thước tệp rage
  • Số lượng tài liệu đang tăng mạnh và không có dấu hiệu làm chậm xuống
  • Chèn thường là trong hunderds mỗi giờ trong đỉnh
  • retreival là điển hình trong hàng ngàn mỗi giờ trong đỉnh
  • lưu trữ NAS và lưu trữ SAN có sẵn

UPDATE (từ câu hỏi dưới đây):

  • nền tảng của tôi là phát triển
  • đó được liên hệ siêu dữ liệu về các tập tin được lưu trữ bên cạnh tập tin trong cơ sở dữ liệu
+0

Bạn có yêu cầu phiên bản, kiểm tra hoặc cấu trúc bảo mật phức tạp không? Bạn có cần phải kết hợp siêu dữ liệu với mỗi tệp không? – Bravax

+0

Bạn có thể muốn xem http://stackoverflow.com/questions/3748/storing-images-in-db-yea-or-nay, câu hỏi đó liên quan đến hình ảnh trong cơ sở dữ liệu, nhưng một số câu trả lời có thể được áp dụng. –

Trả lời

4

Giới hạn duy nhất để lưu trữ tài liệu trong cơ sở dữ liệu là công nghệ.

A relation database có nghĩa là lưu trữ lâu dài các dữ liệu quan trọng của doanh nghiệp. Làm thế nào nó có thể thực hiện chức năng đó thay đổi từ cơ sở dữ liệu đến cơ sở dữ liệu và hệ thống cho hệ thống, tất nhiên. Nhưng lý tưởng là các thuộc tính ACID của relational databasenhằm mục đích để biến nó thành cửa hàng của tất cả enterprise data. Hệ thống tệp, hệ thống điều khiển sửa đổi và các hệ thống lưu trữ lưu trữ cục bộ khác có thể có những lợi thế cụ thể nhưng chúng không được thiết kế để lưu trữ dữ liệu doanh nghiệp như vậy.

Nếu tài liệu bạn đang lưu trữ đủ điều kiện làm dữ liệu doanh nghiệp - nếu chúng được sử dụng liên tục thông qua doanh nghiệp - thì sẽ hợp lý để giữ chúng trong cơ sở dữ liệu. Nếu bạn đang gặp vấn đề với lưu trữ trong cơ sở dữ liệu, có lẽ một DBA có thể tìm thấy một giải pháp tốt hơn. Bạn thậm chí có thể phải di chuyển chúng ra khỏi cơ sở dữ liệu vì lý do hiệu suất nhưng tôi không nghĩ rằng bạn nên di chuyển chúng ra khỏi cơ sở dữ liệu vì lý do thực hành tốt nhất.

Tất nhiên, nếu tài liệu không phải là dữ liệu doanh nghiệp, nếu chúng chỉ được sử dụng cho một ứng dụng, thì việc di chuyển chúng ra khỏi cơ sở dữ liệu cũng sẽ có ý nghĩa.

11

Tôi thích cửa hàng văn bản trong hệ thống tập tin và sau đó cửa hàng một liên kết đến tập tin và liên quan đến tập tin siêu dữ liệu trong cơ sở dữ liệu.

Nó đã được chứng minh thuận tiện hơn, dễ bảo trì hơn và ít tốn kém hơn thay thế.

+2

tại sao nó rẻ hơn? –

+0

Đồng ý. Miễn là bản sao lưu tương tự/giống với bản sao lưu db. Mạnh mẽ và thân thiện. Ngoài ra, một cấu trúc thư mục tốt làm cho nó dễ dàng cho các công nghệ để xem xét thông qua. –

+0

Câu trả lời này không được hỗ trợ. Tại sao nó được đánh giá rất cao? Nó không khủng khiếp nhưng cũng chẳng có gì đặc biệt cả. –

0

Lưu trữ tài liệu của bạn dưới dạng tệp như .doc nếu bạn muốn có thể truy cập các tệp và chỉnh sửa và lưu lại chúng.

Lưu trữ tài liệu của bạn dưới dạng tệp như .pdf hoặc.tiff nếu bạn muốn các bản sao lịch sử thực sự có thể được kéo lên và sao chép.

Lưu trữ tất cả thông tin liên quan đến tệp của bạn (chẳng hạn như ngày, tác giả, vị trí) trong cơ sở dữ liệu của bạn.

2

Tôi đã lưu trữ hình ảnh dưới dạng BLOB trong cơ sở dữ liệu một lần và hối tiếc lần đầu tiên tôi phải thực hiện thao tác hàng loạt trên những hình ảnh đó. Nó sẽ dễ dàng hơn để làm điều đó trong hệ thống tập tin. Ngoài ra, như bạn đã đề cập, sẽ nhanh hơn khi truy xuất tài liệu nếu chúng sống trên hệ thống tệp.

Chế độ xem đơn giản của tôi: hệ thống tệp phải lưu trữ tệp và cơ sở dữ liệu quan hệ phải lưu trữ dữ liệu quan hệ.

+0

+1 cho các công cụ lô hàng tốt hơn để hoạt động trên các tệp được lưu trữ trong hệ thống tệp – dthrasher

0

Tôi luôn lưu trữ thông tin cốt lõi và đường dẫn tệp cho tài liệu trong cơ sở dữ liệu, nhưng không bao giờ bản thân tài liệu. Hiếm khi toàn bộ tài liệu cần phải có trong cơ sở dữ liệu.

Điều này cho phép linh hoạt hơn nhiều trong việc sử dụng các tài liệu đó. Ví dụ: muốn sử dụng cơ chế lưu trữ và lưu trữ sao lưu theo tầng? Hãy thử điều đó trong Oracle BLOB.

13

Dựa trên kinh nghiệm của tôi, tôi muốn nói rằng hãy giữ chúng trong cơ sở dữ liệu. Chúng tôi đã di chuyển hai hệ thống của mình để thực hiện việc này.

Cách để nó vào cơ sở dữ liệu có nghĩa là:

  • Thật dễ dàng để truy cập, thậm chí từ nhiều máy chủ
  • Nó sao lưu tự động (thay vì phải có một công việc riêng biệt để làm điều đó)
  • Bạn không phải lo lắng về không gian (vì mọi người giữ cho DB không nạp quá nhiều đĩa, nhưng có thể quên theo dõi vị trí lưu trữ tài liệu)
  • Bạn không cần phải có một sơ đồ thư mục phức tạp

Chúng tôi đã có tài liệu trong cơ sở dữ liệu. Nó trở thành một vấn đề với rất nhiều tài liệu. Một thư mục bình thường trong Linux là một khối, thường là 4K. Chúng tôi có một thư mục là 58MB vì nó có quá nhiều tệp trong đó (nó chỉ là một thư mục phẳng, không có phân cấp). Nó có rằng nhiều khối gián tiếp. Mất hơn một giờ để xóa. Phải mất vài phút để đếm số lượng tệp trong thư mục. Đó là điều vô cùng. Đây là trên ext3.

Với hệ thống tập tin mà bạn cần:

  • cơ chế sao lưu riêng biệt (từ bản sao lưu DB)
  • Để giữ cho mọi thứ được đồng bộ hóa (vì vậy kỷ lục không tồn tại trong DB mà không có tập tin là có)
  • Phân cấp lưu trữ (để ngăn sự cố được liệt kê ở trên, vì vậy không có thư mục nào kết thúc với 10.000 tệp)
  • Một số cách để xem chúng từ các máy chủ khác nếu bạn cần cụm (vì vậy có thể là NFS hoặc một số loại như vậy)

Nó thực sự là một nỗi đau. Đối với bất kỳ số lượng tài liệu không tầm thường nào, tôi khuyên bạn nên chống lại hệ thống tệp dựa trên những gì tôi đã thấy.

+1

+1 đối số tốt cho lưu trữ DB. Bây giờ chúng ta chỉ cần một câu trả lời có chất lượng tương tự cho cách tiếp cận hệ thống tập tin. :-) – Darron

+0

Cảm ơn. Như tôi đã nói, chúng tôi không thể xóa được thư mục mà không có thời gian chết!) Hầu hết mọi người đều thích cách tiếp cận của FS, và nếu nó được thiết kế tốt, nó sẽ hoạt động (chúng tôi sẽ không chạy vào vấn đề chúng tôi đã làm). Nhưng chúng ta không được thiết kế cho rất nhiều tài liệu. – MBCook

+0

Tôi không gặp vấn đề gì khi sử dụng DB để lưu trữ tệp. Nhưng tôi chỉ có thể xem xét làm điều này nếu tôi có tổng số cam kết từ nhóm để CHỈ lưu trữ tài liệu trong cơ sở dữ liệu, và để loại bỏ các tài liệu từ bất cứ nơi nào khác mà họ đã xảy ra được. Nhưng bạn đang thực sự tạo ra một hệ thống quản lý tài liệu. Không có bất kỳ DMS đã được ra khỏi đó? –

0

Lợi thế duy nhất tôi có thể thấy để lưu trữ tài liệu trong cơ sở dữ liệu là dễ dàng di chuyển các tài liệu đó sang môi trường khác. Ngoài ra, tôi sẽ không làm điều đó vì tất cả những lý do đã được đề cập.

0

Ngược lại tôi sẽ đi cho lưu trữ trong cơ sở dữ liệu cho một vài lý do:

  1. đơn giản chiến lược sao lưu
  2. Tài liệu lưu trữ trong cơ sở dữ liệu có thể được lập chỉ mục và tìm kiếm
  3. Bạn không phải lo lắng về các tệp đang được di chuyển/bảo mật bị giả mạo với
  4. Dễ dàng chuyển đến máy chủ khác trong trường hợp xảy ra sự cố
  5. Nếu chính phủ ủy quyền, bạn phải lưu trữ dữ liệu trở lại x năm, quản lý việc này bằng cơ sở dữ liệu dễ dàng hơn nhiều

Cơ sở dữ liệu được thực hiện để lưu trữ dữ liệu. Tệp chỉ là dữ liệu.

Mặc dù đã nói rằng có những lợi ích để lưu trữ tệp trên hệ thống tệp, nhưng nguyên tắc chính là hiệu suất cơ sở dữ liệu tốt hơn và kích thước được giữ nguyên. SQL Server 2008 cho phép bạn tận dụng tối đa cả hai thế giới bằng FileStream. Read this whitepaper để biết thêm thông tin

5

Mối quan tâm lớn nhất của tôi khi lưu trữ các tệp trong cơ sở dữ liệu là quản lý kích thước và độ phức tạp của các bản sao lưu và các hoạt động bảo trì db khác.

Một chiến lược để giảm thiểu khó khăn này (ít nhất là trong MS SQL) là tạo phân vùng cơ sở dữ liệu riêng biệt, có khả năng được lưu trữ trên các ổ đĩa khác nhau.

Sau đó, tách giản đồ dữ liệu của bạn sao cho siêu dữ liệu của bạn về các tệp nằm trên một phân đoạn và tệp BLOB thực tế được đặt trong một phân vùng riêng biệt.

Những phân vùng này có thể được sao lưu trên các lịch biểu khác nhau hoặc thậm chí được khôi phục riêng.

+0

+1 khi tạo nhóm tệp riêng cho các loại dữ liệu hình ảnh/BLOB –

+0

Có, tôi đã thấy chính xác vấn đề này. Làm thế nào để các giải pháp sao lưu/phục hồi cho phân vùng riêng biệt khác nhau và làm thế nào trong điều kiện thực tế nó đã làm cho vấn đề dễ dàng hơn? –

+0

Chia phân vùng theo cách tôi đã phác thảo ở trên sẽ cho phép bạn thực hiện khôi phục * siêu dữ liệu * (nếu xảy ra sự cố) mà không phải khôi phục tất cả các tệp lớn. Tuy nhiên, bạn vẫn gặp sự cố khi cố khôi phục các tệp riêng lẻ, vì bạn không thể khôi phục chỉ một hàng * duy nhất của một bảng; bạn phải khôi phục toàn bộ phân vùng (không có công cụ của bên thứ 3 như Quest Lightspeed). – BradC

0

Chuyên môn cá nhân: Bạn có phải là quản trị viên hoặc lập trình viên db không?

Bảo mật: một cài đặt cho cơ sở dữ liệu so với 2 cho cơ sở dữ liệu và hệ thống tệp. Có phải lo ngại về việc ai đó vô tình di chuyển/xóa các tệp không? Trong một thiết lập phức tạp, quản trị viên có thể chọn di chuyển tệp sang máy chủ khác và chỉ cần thay đổi Chia sẻ hoặc ánh xạ. Tôi biết, điều này sẽ không bao giờ xảy ra.

Cơ sở dữ liệu mới đang cải thiện trong lĩnh vực này.

1

Lưu trữ các tệp nhị phân trong hệ thống tệp. Tạo một ứng dụng ASP.NET cho các hoạt động lưu trữ và truy xuất. Bạn có thể ưa thích với ứng dụng web (phiên bản doc, bảo mật nhiều tầng, v.v.). Tôi nghĩ đây là sự đồng thuận trong ngành quản lý tài liệu.

Vì "số lượng tài liệu của bạn đang tăng lên đáng kể", có vẻ như điều này đang trở nên quy mô lớn. Bạn có thể muốn bắt đầu xem xét các giải pháp của bên thứ ba, out-of-the-box (chẳng hạn như http://kofax.com/capture/ - Tôi có một kinh nghiệm sâu rộng với điều này!) Để làm "công việc bẩn thỉu" cho bạn. Hoặc tốt hơn, hãy xem xét nhìn vào SaaS cung cấp như những kẻ http://www.edocumentsolutionsllc.com/

:-)

0

Nên cất giữ tài liệu của bạn trong lật đổ, hoặc hệ thống kiểm soát phiên bản khác. Bạn sẽ có một bản sao lưu tốt, khả năng xem các phiên bản cũ của tài liệu và truy cập mạng lộng lẫy. Xem "My life on subversion".

6

Hầu hết các hệ thống quản lý tài liệu cấp doanh nghiệp KHÔNG lưu trữ tệp đối tượng trong cơ sở dữ liệu. Chỉ vì bạn có thể không có nghĩa là bạn nên. Nếu khả năng mở rộng và hiệu suất là quan trọng với bạn và bạn có một bộ tài liệu lớn, bạn cần phải rất cẩn thận về việc lưu trữ các đối tượng trong db. Hãy xem xét những điều sau đây:

Trong trường hợp hình ảnh tài liệu, 200 triệu tệp TIFF có thể được coi là một hệ thống tương đối lớn nhưng không lớn. Các hệ thống có quy mô lớn hơn có thể có hơn 1 tỷ tệp đối tượng. Tại, nói rằng, 20KB mỗi bitonal TIFF bạn có thể có 4TB lưu trữ tập tin đối tượng. Sao lưu DB của bạn sẽ mất bao lâu? Các truy vấn của bạn sẽ mất bao lâu? Tần suất truy cập cho các đối tượng này là bao nhiêu? Nếu các đối tượng này có tần suất truy cập cao, bạn có muốn máy chủ DB cao cấp của bạn dành tất cả thời gian để phân phối các tệp không? Nếu bạn có hàng triệu đối tượng thì bạn cần phải khá cẩn thận về cách bạn kiến ​​trúc sư một giải pháp nơi các đối tượng được lưu trữ trong db.

Giả sử bạn hiện được giao nhiệm vụ chuyển đổi các tệp TIFF 200M đó thành tệp PDF. Hãy chuẩn bị sẵn sàng để đưa giải pháp của bạn đến đầu gối khi máy chủ cơ sở dữ liệu của bạn lãng phí thời gian của nó để phục vụ từng tệp đối tượng cho quá trình chuyển đổi và sau đó lưu lại kết quả.

Giống như một ví dụ, Sharepoint nổi tiếng để lưu trữ các đối tượng trong db. Sharepoint cũng nổi tiếng với các vấn đề về khả năng mở rộng.

Câu trả lời của tôi:
Đối với các hệ thống nhỏ (< 1M tệp) lưu trữ tệp trong DB có thể được xem xét. Đối với các hệ thống lớn (> 1 triệu tệp) lưu trữ tệp trong DB là lỗi.

+0

Các phương pháp hay nhất để lưu trữ các tệp> 1 M ở cấp hệ thống tệp là gì? Có những giải pháp sản xuất cứng mà người ta có thể sử dụng mà không cần phát minh lại bánh xe và tránh những cạm bẫy phổ biến? – yagooar

Các vấn đề liên quan