데이터베이스의 데이터와 관련된 이진 파일을 저장하는 가장 좋은 장소는 무엇입니까? 당신이해야 :

1. 얼룩과 함께 데이터베이스에 저장
2. 데이터베이스에 링크가있는 파일 시스템에 저장
3. 파일 시스템에 저장하지만 컨텐츠의 해시로 이름을 바꾸고 데이터베이스에 해시를 저장하십시오.
4. 내가 생각하지 못한 것

(1)의 장점은 거래의 원 자성이 보존된다는 것입니다. 비용은 스토리지 (및 관련 스트리밍 / 백업) 요구 사항을 크게 증가시킬 수 있다는 것입니다.

(3)의 목표는 원 자성을 어느 정도 보존하는 것입니다. 작성하려는 파일 시스템이 파일을 변경하거나 삭제할 수 없으며 항상 올바른 해시를 파일 이름으로 사용하도록 강제 할 수 있다면. 해시를 참조하는 삽입 / 업데이트를 허용하기 전에 파일 시스템에 파일을 작성하는 것이 좋습니다. 파일 시스템이 작성된 후 데이터베이스 DML 전에이 트랜잭션이 실패하면 파일 시스템이 모두의 저장소이므로 '가짜'이므로 문제가 없습니다. 가능한 파일 및 해시-지정되지 않은 일부 파일이 있는지 여부는 중요하지 않습니다 (주의를 기울이면 주기적으로 정리할 수 있습니다)

편집하다:

일부 RDBMS는 개별 방식으로이를 다루는 것처럼 보입니다. 다른 사람들이 어떻게하는지 알고 싶습니다. 특히 postgres 솔루션에 관심이 있습니다.

1. 얼룩과 함께 데이터베이스에 저장

   단점은 데이터베이스 파일이 너무 커서 기존 설정으로 백업하기에는 너무 클 수 있다는 것입니다. 장점은 무결성과 원 ​​자성입니다.

2. 데이터베이스에 링크가있는 파일 시스템에 저장

   나는 이렇게 끔찍한 재앙을 겪었고 사람들이 계속해서 그것을 제안한다는 것이 무섭습니다. 재난 중 일부는 다음과 같습니다.

   • 파일을 재정렬하고 DB의 경로와 현재 위치 사이의 링크를 자주 끊는 특권 사용자
   • 한 서버에서 다른 서버로 이동할 때 이전 컴퓨터의 관리자 계정 (이전 웹 사이트가 실행중인)의 SID가 도메인의 일부가 아니기 때문에 일부 파일의 소유권이 손실되어 복사 된 파일에 ACL이 생겼습니다. 사용자 이름 / 암호 / 도메인 로그인 프롬프트가 표시됩니다.
   • 일부 경로는 C:\끝까지 256 자보다 길어 .doc졌으며 모든 NT 버전에서 긴 경로를 처리 할 수있는 것은 아닙니다.

3. 파일 시스템에 저장하지만 컨텐츠의 해시로 이름을 바꾸고 데이터베이스에 해시를 저장하십시오.

   내가 근무했던 마지막 장소는 위의 시나리오에 대한 나의 설명을 바탕 으로이 작업을 수행했습니다. 그들은 조직이 큰 데이터베이스에 대한 경험을 얻지 못하고 (약 40G보다 큰 것은 "너무 큰"것으로 지명 됨) 회사가 큰 하드 드라이브를 구매할 수없고, 더 현대적인 백을 구입할 수 없다는 점에서 절충안이라고 생각했습니다. 업 솔루션과 위에서 설명한 위험 # 1 및 # 3에서 벗어날 필요가 있습니다.

필자는 DB에 BLOB으로 저장하는 것이 더 나은 솔루션이며 다중 서버 시나리오에서, 특히 페일 오버 및 가용성 문제와 관련하여 확장 성이 뛰어나다 고 생각합니다.

완벽한 데이터 무결성을위한 1 번. 데이터 품질에 신경 쓰지 않으면 다른 옵션을 사용하십시오. 그렇게 간단합니다.

대부분의 RDBMS에는 BLOB (예 : SQL Server 파일 스트림)를 저장하기위한 최적화 기능이 있습니다.

오라클을 원한다면 dbfs와 Secure Files를 살펴보십시오.

안전한 파일은 모든 것을 말하고 데이터베이스에 모든 데이터를 안전하게 보관하십시오. 그것은 덩어리로 구성되어 있습니다. 보안 파일은 최신 버전의 로브이며 활성화해야합니다.

dbfs는 데이터베이스의 파일 시스템입니다. Linux 호스트에서 네트워크 파일 시스템과 유사하게 마운트 할 수 있습니다. 정말 강력합니다. 블로그 참조 또한 특정 요구에 맞게 조정할 수있는 많은 옵션이 있습니다. dba이기 때문에 (Linux에 마운트 된 데이터베이스 기반의 파일 시스템) 아무런 문제없이 Oracle Database를 만들었습니다. (... 데이터베이스에 저장된 데이터베이스). 이것이 매우 유용하지는 않지만 그 힘을 보여줍니다.

가용성, 백업, 복구, 다른 관계형 데이터와 일치하는 모든 읽기의 이점이 있습니다.

때로는 데이터베이스에 문서를 저장하지 않기 위해 크기가 제공되기도합니다. 해당 데이터는 어떤 식 으로든 백업해야하므로 데이터베이스에 저장하지 않는 것이 좋습니다. 특히 오래된 문서를 읽기 전용으로 간주해야하는 상황에서는 데이터베이스의 큰 부분을 읽기 전용으로 만드는 것이 쉽습니다. 이 경우 데이터베이스의 해당 부분은 더 이상 자주 백업 할 필요가 없습니다.

데이터베이스 외부에있는 테이블에 대한 참조는 안전하지 않습니다. 조작이 가능하고 점검하기가 어렵고 쉽게 길을 잃을 수 있습니다. 거래는 어떻습니까? 데이터베이스는 이러한 모든 문제에 대한 솔루션을 제공합니다. Oracle DBFS를 사용하면 비 데이터베이스 응용 프로그램에 문서를 제공 할 수 있으며 데이터베이스에서 파고 들었다는 사실조차 알 수 없습니다.

마지막으로 놀랍게도 dbfs 파일 시스템의 성능은 종종 일반 파일 시스템보다 낫습니다. 파일이 몇 블록보다 큰 경우 특히 그렇습니다.

여기에 정답은 응용 프로그램과 문서의 중요성에 달려 있습니다.

문서 관리 시스템 또는 저장된 문서의 복구 가능성이 중요한 시스템 (대부분의 재무, HR 또는 CRM 관련)의 경우 문서를 인라인으로 저장하거나 선호하는 DB 공급 업체의 독점 문서 기술을 사용하는 것이 올바른 일처럼 보입니다.

그러나 반대 결정이 적절하다고 생각되는 응용 프로그램이 많이 있습니다.

헬프 데스크 시스템과 위키 형 시스템은 내가 데이터를 유지하기 위해 많은 이해 생각하는 것들 에서 데이터베이스. Jira와 같은 일부 문서는 실제로 문서를 인라인으로 저장할지 여부를 선택할 수있는 옵션을 제공한다고 생각합니다.

중간 규모 비즈니스의 경우 티켓 시스템의 문서를 인라인으로 저장하면 메가 바이트 단위로 측정 된 압축 백업과 기가 바이트 단위로 측정 된 압축 백업의 차이를 의미 할 수 있습니다.

저는 개인적으로 몇 분 안에 발권 시스템을 온라인으로 다시 가져 와서 몇 시간 동안 (일반적으로 덜 중요한) 문서와 씨름하는 것을 선호합니다. 훨씬 더 큰 백업에서 로그를 재생할 수 있습니다.

문서를 별도로 유지하면 다른 이점이 있습니다.

• 문서 메타 데이터를 카탈로그 화하고 바이러스 검색을 수행하며 키워드 색인 작성 등을 수행하는 별도의 프로세스를 쉽게 실행할 수 있습니다.
• rsync, 스토리지 스냅 샷 등의 백업 또는 복구를 지원하는 도구를 활용하여 데이터베이스보다 파일에 훨씬 더 적합합니다.
• 실제로 압축 또는 중복 제거를 지원하는 스토리지를 사용할 수 있습니다 (SAN 관리자가 수년간 전 세계 데이터베이스 관리자의 골칫거리였던 것들).
• 여러 사이트에 설치하는 경우 분산 파일 시스템으로 중앙 데이터베이스를 보완 할 수 있습니다

# 2와 # 3의 하이브리드 조합은 영리하다고 생각합니다. 원래 파일 이름은 유지하지만 문서의 해시 / 체크섬을 계산하고 저장하여 누군가 파일을 이동하거나 이름을 바꿀 경우 복구를 도와주는 참조 점이 있습니다.

원래 파일 이름으로 파일을 저장하면 응용 프로그램이 파일 시스템에서 직접 파일을 잡아 당겨 유선으로 또는 두꺼운 클라이언트 환경에서 파일 서버로 직접 보낼 수 있습니다.

하지마

데이터베이스에 파일을 저장하는 것의 장점은 없습니다.

스스로 생각할 때 이미 이상하고 비린 느낌이 들지 않습니까?

데이터베이스 나 파일 시스템에 파일을 저장해야합니까 ?

더 좋게 말해 크게 말하십시오.

사실에 :

데이터베이스 사용

" 총 "... 하지만 꽤 :

• "원자"는 맞지만 양날의 칼입니다. 그것과 함께 단점을 끌기 때문입니다.
• 청렴, 완전 함. 같은 상기와.

나는 편견을 갖고 싶지 않지만 더 추가 할 것이 없다고 생각합니다. 당신이 그것에 대해 생각하면 전문가들은 그렇게 훌륭하지 않습니다.

아래에 의견이 있으면 잊어 버리십시오.

단점 :

• 작업에 대한 잘못된 도구
• 유지하기 어렵다
• 느린
• 사용자 당 수백 MB / 기가 바이트의 데이터를 저장하는 것을 잊어 버리십시오 .
• 빠르게 성장하는 사이트를 백업하는 것은 악몽이 될 것입니다.
• 복원 / 이동도 빨라집니다.

파일 시스템 사용

장점 :

• 유지하기 쉬운 방법
• 빠른
• 데이터베이스 백업은 이와 관련이 없습니다.
• 틀림없이 더 많은 이식성 *

단점 :

• 없음 *

* 미세 인쇄

지금 당신은 자신에게 묻고 있습니다, 당신은 죄수가 없다는 것을 의미합니까?! 어떻게?

여기서 가장 큰 실수는 사람들이 망치로 나사를 조이려고한다는 것입니다.

내가 멀리 갈 것 그리고 가장 큰 이유는 대답 만 이 요구되는 이유 때문이다 파일 링크 .

데이터베이스가 해결하려는 문제가 아닙니다. 당신이 생각하면 어리석게 들립니다.

"데이터베이스가 파일 연결 문제를 해결합니다."

실제로 논리적으로 응용 프로그램 은 실제로 링크 처리 및 서비스 를 담당해야 합니다.

해결책 :

1. 애플리케이션이 사용자 지정 경로로 URL 요청을 처리하도록합니다.
2. 이 경로를 데이터베이스에 저장하십시오.
3. 내부적으로이 경로가 호출 될 때마다 원하는 파일에 매핑합니다.
4. 파일을 다른 곳으로 옮기는 경우 경로의 파일 이름 값만 변경하면 해당 경로는 웹에서 저장되거나 참조되는 위치에 관계없이 항상 동일한 파일을 제공합니다.

또한 기본 경로를 추상화하고 응용 프로그램을보다 이식 가능하고 유지 관리 가능하게 만들며 어떤 파일 시스템도 손상시키지 않고 모든 종류의 파일 시스템으로 전환 할 수 있습니다.

구현 방법은이 답변의 범위를 벗어나지 만 가장 널리 사용되는 웹 언어 (PHP)의 일반적인 예를 살펴볼 수 있습니다.

https://github.com/symfony/Routing

https://github.com/kriswallsmith/assetic

둘 다 함께 강력합니다.

트레이드 오프에 대한 경험을 여기에 추가하고 싶습니다. PostgreSQL에서는 최소한 DB 서버 측면에서 성능 영향이 미미합니다. 큰 Blob은 기본 힙 테이블이 아닌 별도의 파일에 저장되어 많은 수의 레코드를 계산할 수있는 작업 방식을 벗어나게합니다. 다른 DB는 비슷한 것을 할 수 있습니다.

주요 이점은 원 자성 및 백업 목적으로 모든 관련 데이터를 한 곳에 보관할 수 있다는 것입니다. 이것은 무언가 잘못 될 가능성을 크게 줄입니다.

가장 큰 단점은 위에서 설명한 것 중 하나가 아니며 프런트 엔드의 메모리 사용량입니다. 모든 db가 이것을 어떻게 처리하는지 정확히 알지 못하므로 구현에 따라 달라질 수 있지만 PostgreSQL의 경우 데이터는 이스케이프 처리 된 ASCII 문자열 (16 진수, 인라인 이스케이프 가능)으로 제공됩니다. 그런 다음 프런트 엔드에서 이진으로 다시 변환해야합니다. 이 작업을 수행하기 위해 본 많은 프레임 워크는 값이 아닌 참조를 전달한 다음이를 기반으로 새 이진 문자열을 구성합니다. 나는 Perl을 사용 하여이 작업을 수행하기 위해 원래 바이너리의 메모리를 여러 번 사용했다고 계산했습니다.

평결 : 파일에 가끔 액세스하는 경우 db에 저장합니다. 적어도 PostgreSQL을 사용하여 자주 반복적으로 액세스하는 경우 비용이 이점을 능가한다고 생각합니다.

그 당시 Microsoft는 데이터베이스에 이미지 (및 유사한 Blob 데이터 형식)를 저장하는 기능을 강화했습니다. 이 기능은 SQL Server 2000의 멋진 새 기능 (7.0이 아닌 2000 임)으로 많은 사람들이 악단을 뛰어 넘었습니다.

데이터베이스에 BLOBS를 저장하면 다음과 같은 장점과 단점이 있습니다.

한편으로는 모든 데이터와 관련 이미지 또는 문서를 한 곳에 저장하고 액세스 할 수 있습니다. 응용 프로그램 사용자는 이미지 / 파일 / 문서를 제공하는 SQL이므로 특별한 네트워크 권한이 필요하지 않습니다.

반면, 저장하는 BLOBS의 크기와 수에 따라 데이터베이스가 상당히 커질 수 있습니다. 이는 백업, 스토리지 요구 사항, 시간에 민감한 복구 작업 등에 영향을줍니다.

SQL Server 2008은 파일 스트리밍을 도입했습니다. 데이터베이스는 파일에 대한 포인터를 포함하고 파일은 데이터베이스가 아닌 서버에 상주하지만 데이터베이스를 백업하면 파일도 백업됩니다.

백업은 상당히 커질 수 있지만 고아 파일 / 문서 / blobs / image로 끝나지 않습니다.

개인적으로 선호하는 것은 데이터베이스가 포인터 / 네트워크 위치를 저장하고 파일 서버가 파일을 처리하게하는 것입니다. 어쨌든 파일 서버는 이러한 작업에 더 적합합니다.

데이터베이스에 파일을 저장하지 마십시오.

시장에서 RDBMS를 실행할 수있는 모든 사람은 예외없이 이미 파일을 저장하기위한 데이터베이스를 가지고 있으며 RDBMS 자체에서이를 사용하고 있습니다! 그 데이터베이스는 파일 시스템 입니다. 이제 데이터베이스에 파일을 저장하는 경우 발생할 수있는 몇 가지 단점과 데이터베이스에 파일을 저장하기위한 특정 완화 요소에 대해 살펴 보겠습니다.

• 어떤 filehandes하지 데이터베이스 파일에. 이것은 무엇을 의미 하는가?

  • 프로그래머 - 토론 : 당신은 수없는 (구가 fseek), 비동기 액세스 (와 자원 관리 할 능력이없는 asyncio이상 epoll), 더는 없다 sendfile(당신은 커널 공간에서 복사본을 저장).

  • 실용적 응용 : HTTP2 / 3를 통해 비디오 또는 사진을 클라이언트로 보내시겠습니까? 데이터베이스에 있으면 먼저 쿼리해야합니다. 어떤 쿼리가 해당 파일을 반환하는지에 대해서는 해당 파일이 다음 단계로 이동하기 전에 전체 쿼리가 완료 될 때까지 기다려야합니다 . 웹 서버와 다른 서버에 rdbms가있는 프로덕션 설치에서는 먼저 파일을 스트리밍하지 않고 rdbms에서 웹 서버로 파일을 완전히 전송해야합니다 . 그러나 전송 계층이 파일 시스템 추상화 (NFS 지원)를 제공 한 경우 파일을 반쯤 탐색하여 필요한 것보다 많은 파일을 버퍼링하지 않고 즉시 클라이언트로 스트리밍을 시작할 수 있습니다. 이것은 일상적으로 웹 서버에 의해 수행됩니다nginx , Apache , PureFTP 및 ProFTP.

• RDBMS에서 이중 사본. 데이터베이스에 있다는 사실 때문에 두 번 쓸 것입니다. WAL (Write-Ahead Log)에 들어가면 다시 테이블 스페이스에 들어갑니다.

• 업데이트 없음, MVCC 는 업데이트되는 것이 없음을 의미하며 수정 사항으로 새로 복사 한 다음 이전 행이 만료 됨 (삭제됨)으로 표시됩니다. 파일을 업데이트하려면 파일 전체 행 뿐만 아니라 전체 행을 작성해야 합니다. 파일 시스템에서도 데이터 저널링을 제공 할 수 있지만 거의 필요하지 않습니다.

• 쿼리 속도 저하를위한 파일 읽기 및 전송 파일 자체가 쿼리해야하는 행에 저장된 경우 전체 행은 파일이 전송 될 때까지 기다려야합니다. 그렇지 않으면 두 개의 개별 쿼리를 실행해야합니다. .

• DB 클라이언트에서 메모리 사용 . DB- 클라이언트 (libpq, jdbc, odbc, freetds 등) 등은 쿼리를 메모리에 버퍼링합니다. 메모리 내 버퍼가 소진되면 디스크 버퍼가 시작되거나 디스크로 페이징되기 위해 커널로 다시 떨어질 수 있습니다.

• 쿼리 조절 많은 데이터베이스는 시간이나 리소스가 너무 많이 걸리는 쿼리를 종료하고 거두는 기능을 제공합니다. 파일 전송은 어떤 구현에서도 항목별로 분류되지 않습니다. 3 초 후에 해당 쿼리가 종료 되었습니까? 아니면 1 초가 걸렸고 백엔드는 파일을 전송하는 데 2 ​​초가 걸렸습니까? "항목 화"뿐만 아니라 쿼리의 99.9 %가 1KB를 반환하고 다른 하나는 1GB를 반환 할 때 얼마나 많은 시간이 걸리는지를 효과적으로 설명 할 수 있습니까?

• 복사 중 복사 또는 중복 제거 불가 XFS 및 BTRFS는 쓰기 중 복사 및 중복 제거를 투명하게 지원합니다. 즉 , 파일 시스템으로 모든 곳에서 같은 그림을 보거나 두 번째 복사본을 투명하게 처리 할 수 있습니다 . 그러나 파일이 자체적으로 대기하지 않고 행 또는 상점에있는 경우 파일 시스템은 파일을 중복 제거 할 수 없습니다.

• 무결성 많은 사람들이 여기에서 무결성에 대해 이야기하고 있습니다. 파일 시스템이나 파일 시스템의 핵심 유틸리티를 사용하는 응용 프로그램 인 파일 시스템 손상을 감지하는 데 더 나은 점은 무엇이라고 생각하십니까? 파일을 행에 저장하거나 라인 외부에 저장하면 파일 시스템 손상으로 인해 데이터베이스가 가려집니다. xfs_repair파일 시스템이나 하드 드라이브 손상이있을 때 복구에 능숙하며, 실패하면 데이터 포렌식을 수행하는 것이 훨씬 쉽습니다.

• SAN 또는 클라우드에 파일을 저장하려는 경우 클라우드 마이그레이션 이제 스토리지 마이그레이션이 데이터베이스 마이그레이션이므로 더 어려워 질 것입니다. 예를 들어 파일이 파일 시스템에 저장된 경우 S3로 상당히 쉽게 옮길 s3fs수 있습니다 (투명 할 수있는 것).

예외

데이터베이스에 파일을 저장하면 몇 가지 유효한 사용 사례가 있습니다.

• 파일을 일시적으로 편집 해야 할 때 . 그것은 말 그대로 파일을 편집하는 것이 트랜잭션의 일부라는 것을 의미합니다. 또는 관계 (테이블)의 데이터 무결성 문제로 인해 트랜잭션이 실패한 경우 파일에 대한 편집을 롤백 할 수 있어야 합니다.
• 이 때 필요한 파일 시스템을 보장하기 위해 정확하게 데이터 버전이되고 당신은 동기화를 유지 위험을 감당할 수 없습니다.
• 데이터베이스가 실제로 파일을 구문 분석하여 쿼리 할 수있는 경우 예를 들어 PostgreSQL에서 토폴로지는 PostGIS를 사용한 쿼리 일 수 있습니다. 이 시점에서 파일은 스토리지 덤프가 아닌 쿼리에 대한 데이터이기도합니다.

완화

• 일부 데이터베이스는 "외부 관리 자원"이라는 개념을 가지고 있습니다. 여기서 데이터베이스는 디스크에서 파일을 디스크에서 개인적으로 관리합니다.

  • Large Object Infrastructure를 통한 PostgreSQL 은 트랜잭션 기간 동안 리소스에 파일 핸들을 제공합니다.

  • SQL Server 2017의 파일 스트림 인프라 는 파일 경로를 가져오고 파일 핸들을 여는 데 사용할 수있는 트랜잭션 기간 동안 지속되는 임시 액세스를 제공합니다.

  • 오라클은 BFILE(이것은 내부 LOB와 관련이 없습니다.SecureFile

• 일부 데이터베이스는 큰 이진 객체를 오프라인으로 저장하거나 Oracle SecureFile과 같이 저장할 수 있습니다. 파일을 다시 쓰지 않고 행을 업데이트 할 수 있습니다.

• Oracle과 같은 일부 데이터베이스는 WAL 로그없이 MVC를 수행하므로 파일을 두 번 쓰지 않아도됩니다.

• SQL Server 및 Oracle과 같은 일부 데이터베이스는 파일 핸들없이 파일에서 데이터를 "스트리밍"하는 기능을 제공합니다. 이것은 databaes 쿼리와 다른 연결에서 실행되거나 실행되지 않을 수 있습니다. 그러나 여기서 핵심 은 파일을 이론적으로 스트리밍 할 수 는 있지만 해당 기능을 사용하는 공급자가 제조하지 않은 제품에 대한 증거를 찾을 수 없다는 것입니다. 예를 들어, NGINX / Apache 브릿지는 어디에 있습니까?

• Oracle은 SecureFile과 같은 내부 LOB 스토리지를 통해 선택적 중복 제거, 압축 및 암호화를 제공합니다.

결론

데이터베이스에 파일을 넣을 때 최악의 시나리오는 성능 및 툴링과의 호환성 이 매우 나쁩니다 . 항상 예외적으로 구현에 의존합니다. 데이터베이스 가 파일 시스템 보다 파일 시스템 보다 나은 것은 아닙니다 . 모든면에서, 그것은 타협이며 심지어 강력한 완화 기능 (SecureFile의 경우와 같은)을 얻을 때조차도 툴링이 너무 나빠서 전체 스택이 RDBMS 제공자에 의해 구축되지 않는 한 실제로 마케팅 포인트 이상은 아닙니다.

간단하게 유지하고 일반적인 규칙은 파일을 DB 외부에 보관하는 것입니다 .

해결책

여러 테넌트 및 사용자에게 효과적으로 기능하려면 파일을 어떻게 저장하거나 파일 시스템을 추상화해야합니까? 파일 내용을 해싱하는 데 부분적입니다. 이것은 요즘 꽤 일반적이며 잘 작동합니다.

그것은 부분적으로 응용 프로그램 / 환경 (사람 포함)에 달려 있지만 블롭을 위해 갈 것입니다.

데이터베이스에 모든 것을 유지한다는 것은 파일 데이터에 대한 복제 작업을 의미합니다. FS 파일을 동기화하려면 별도의 메커니즘이 필요합니다.

일부 응용 프로그램에서는 파일 시스템을 수정해서는 안됩니다. 예를 들어, 프로덕션 웹 사이트에서는 일회용 데이터가 아닌 사이트 (SCM에 따라 사이트, 데이터베이스에있는 데이터)에 파일 시스템을 사용하지 않는 것이 좋습니다.

별도의 권한을 가진 여러 사용자 / 응용 프로그램이 있다고 가정하면 모든 파일 시스템 저장소는 DB 및 FS 액세스 권한의 차이를 유발할 수 있습니다.

BLOB 스토리지에 대한 개선은 데이터가 의미가있는 경우 데이터를 청크하는 것입니다. 20Mb BLOB에서 512 바이트 만 필요한 경우,이 섹터와 같은 액세스는 특히 원격 클라이언트를 처리 할 때 특히 유용합니다 (일부 업데이트로 인해 복제 트래픽이 훨씬 적음).

내 투표도 마찬가지입니다. Amazon S3 또는 Microsft의 CDN과 같은 시스템에 데이터를 저장하고 해당 URL을 데이터베이스에 저장하십시오.

이런 식으로 괴물 크기의 데이터베이스를 처리하지 않고도 항상 데이터에 액세스 할 수 있다는 안정성을 얻을 수 있습니다.

postgres의 경우 :

실제로는 직설적입니다. BYTEA이진 문자열을 저장하는 데 사용할 수 있는 유형이 있습니다. 기본적으로 MS 또는 Oracle에 대해 언급 된 것과 같은 유틸리티에는 빌드가 없습니다. 따라서 많은 큰 파일을 저장하고 검색하면 지루할 수 있습니다. 또한 응용 프로그램 내에서 파일을 변환해야합니다 (예 : ByteStream특정 MS / Oracle 파일 <-> 데이터베이스 솔루션에서 어떻게 작동하는지는 알지 못함). 또한이 lo유형은 이러한 유형의 내부 관리의 일부는 참조를 추적하지 않을 수 있기 때문에 그에 BLOB를 관리하는 일에 도움.

Ms SQL Server 및 수많은 파일에 대한 내 경험을 공유하십시오. 파일을 파일 서버에 저장합니다. 데이터베이스에는 파일 폴더와 액세스 자격 증명, 파일 이름에 대한 테이블이 하나씩 있습니다. 데이터베이스와 파일을 쉽게 관리 할 수 ​​있습니다. 폴더 테이블을 수정하기 만하면 서버간에 파일을 쉽게 이동할 수 있습니다.