MySQL blob 필드 유형을 사용해야합니까?

Question

곧 출시 될 프로젝트에서 MySQL blob 필드 유형을 사용해야하는지 결정하는 데 어려움을 겪고 있습니다.

기본 요구 사항은 볼 수 있고 여러 파일을 업로드하여 해당 레코드에 "첨부"할 수있는 특정 데이터베이스 레코드가 있어야합니다. 상기 기록을 보는 것은 사례별로 특정 사람들에게만 제한 될 수 있습니다. 사실상 제한없이 모든 유형의 파일을 업로드 할 수 있습니다.

편도를 보면, 내가 MySQL 루트로 간다면, 바이러스가 들어 오거나 PHP 파일이 업로드되고 어떻게 든 실행되는 것에 대해 걱정할 필요가 없습니다. 나는 또한 기록에 가깝게 묶인 데이터를 허가하고 보관하는 훨씬 쉬운 길을 가졌다.

다른 명백한 경로는 웹 루트 외부의 특정 폴더 구조에 데이터를 저장하는 것입니다. 이 경우 폴더/파일에 대한 특수한 명명 규칙을 사용하여 데이터베이스에서 참조하는 내용을 추적해야합니다.

MySQL blob 필드 유형을 사용하면 성능이 저하됩니까? 나는 웹 사이트의 미래 성장을 저해 할 솔루션을 선택하는 것과 유지 보수가 쉽지 않은 솔루션을 선택하는 것에 관심이 있습니다.

Answer 1

웹 서버가 웹을 통해 업로드 된 파일을 제공하는 경우 파일 시스템에 저장하면 성능이 향상됩니다. 그러면 웹 서버는 Last-Modified 및 ETag과 같은 HTTP 캐싱 힌트를 적용하여 동일한 파일에 여러 번 액세스하는 사용자의 성능을 향상시킬 수 있습니다. 또한 웹 서버는 검색 할 때 자동으로 파일에 대해 Content-Type을 올바르게 설정합니다. blob을 데이터베이스에 저장하면 웹 서버에서 무료로 가져와야 할 때 위에서 언급 한 기능 등을 구현하게됩니다.

또한 데이터베이스에서 큰 blob 데이터를 가져 오면 데이터베이스의 성능 병목 현상이 발생할 수 있습니다. 또한 데이터베이스 백업은 더 많은 데이터를 백업하기 때문에 속도가 느려질 수 있습니다. 개발 중에 임시 쿼리를 수행하는 경우 select 문에 대한 결과 집합에서 큰 얼룩이 보이는 것은 불편할 것입니다. 업로드 된 파일을 검사하기 만하면 데이터베이스 열에 어색하게 저장되기 때문에 불편하고 우회합니다.

파일 시스템의 파일 및 데이터베이스의 파일 경로를 저장하는 일반적인 관행을 고수 할 것입니다.

Answer 2

많은 양의 데이터가 결국 성능에 영향을줍니다.

http://msdn.microsoft.com/en-us/library/cc949109.aspx

내가 너무 프로젝트에 너무 유사한 접근 방식을 사용합니다 : MS SQL 2008는 전문 파일 시스템에 이진 데이터를 저장하는 방법이있다.

예를 들어 원래 이름과 같은 파일에 대한 정보를 유지하는 FILES 테이블을 만들 수 있습니다. 디스크에 파일을 안전하게 저장하려면 예를 들어 GUID를 사용하여 파일 이름을 바꿉니다. FILES 테이블에 새로운 파일 이름을 저장하십시오. 사용자가 파일을 다운로드해야 할 때 디스크에서 쉽게 찾고 사용자에게 스트리밍 할 수 있습니다.

Answer 3

제 생각에는 데이터베이스에 파일을 저장하는 것은 좋지 않습니다. 당신이 저장할 수있는 것은 ID, 이름, 타입, 가능하면 파일의 md5 해쉬와 삽입 된 날짜입니다. 파일을 공용 위치 외부의 폴더에 업로드 할 수 있습니다. 또한 한 폴더에 1000 개가 넘는 파일을 보관하지 않는 것이 좋습니다. 따라서 파일 ID가 1000 씩 증가 할 때마다 새 폴더를 만들어야합니다.

Answer 4

MySQL blob 필드 유형을 사용하면 성능이 저하됩니까?

본질적으로는 아니지만 테이블 및 메모리 캐시를 막히게하는 큰 BLOB가 있으면 성능이 저하 될 수 있습니다.

또 다른 명백한 경로는 웹 루트 외부의 특정 폴더 구조에 데이터를 저장하는 것입니다. 이 경우 폴더/파일에 대한 특수한 명명 규칙을 사용하여 데이터베이스에서 참조하는 내용을 추적해야합니다.

네, 일반적인 접근 방식입니다. 일반적으로 기본 키에만 기반한 파일 이름 (이상적인 정수, 사용자가 제출하지 않은 파일)을 포함하는 각 테이블의 이름을 가진 폴더 이름을 가진 폴더를 만들 것입니다.

더 좋은 생각인가요? 그것은 달려있다. 단일 데이터 저장소 만 있으면 웹 사용자에게 어떤 것에 대한 쓰기 액세스 권한을 부여하는 것에 대해 걱정할 필요가없는 배포 단순성 이점이 있습니다. 또한 실행중인 앱 (예 : 액티브 - 활성로드 균형 조정)이 여러 개있을 수있는 경우 스토리지를 동기화해야합니다. 데이터베이스와 파일 시스템보다 훨씬 쉽습니다.

blob 대신 파일 시스템을 사용하는 경우 질문은 폴더에 별칭을 지정하여 웹 서버를 제공합니까?

• + 슈퍼 빠른
• + 캐시 아니라
• - 추가 서버 설정 : 가상 디렉터리; Content-Disposition: attachment/X-Content-Type-Options 헤더를 추가 할 필요가 안티 XSS의 일환으로 HTML 스니핑 IE를 중지

를 측정하거나 수동으로 파일을 제공합니까 : 여분의 서버 설정이 - Content-Type는

원하는 반환 할 적절한 파일 확장자를 필요 서버 측 스크립트를 사용하면 MySQL blob에서 서비스해야하므로

• 은 -
• 잠재적으로 느린 - 수정 된 경우 --때문에 설명서의 공정한 조금을 필요로하고있는 ETag가 제대로
• + 응용 프로그램의 자신의 액세스 제어 방법을 사용할 수 있습니다
• + 쉽게 올바른 추가 캐시 처리 게재 스크립트의 내용 유형 및 내용 처리 헤더

이것은 하나의 전 세계적으로 허용되는 대답이 아닙니다.

Answer 5

많은 사람들이 데이터베이스의 얼룩에 첨부 파일 (일반적으로 이미지에 적용됨)을 저장하지 말 것을 권장합니다. 대신 그들은 경로명을 데이터베이스에 문자열로 저장하고 파일 시스템에 안전한 곳에 저장하는 것을 선호합니다. 장점은 다음과 같습니다.

• 데이터베이스 및 데이터베이스 백업이 더 작습니다.
• 임시 파일로 작업해야하는 경우 파일 시스템에서 파일을 편집하는 것이 더 쉽습니다.
• 파일 시스템은 파일을 저장하는 데 적합합니다. 데이터베이스는 튜플을 저장하는 데 적합합니다. 각자가 잘하는 일을하게하십시오. 자동으로 관련 첨부 파일을 삭제하는 데이터베이스의 행을 삭제
  • :

  은 BLOB에 넣어 첨부 파일을 지원 너무 반론이있다.

• 롤백 및 트랜잭션 격리는 데이터가 행에있을 때 예상대로 작동하지만 데이터의 일부가 파일 시스템에있는 경우에는 작동하지 않습니다.
• 모든 데이터가 데이터베이스에 있으면 백업이 간단합니다. 백업 절차 중 동시에 변경되는 데이터의 일관된 백업을 염려 할 필요가 없습니다.

따라서 최상의 솔루션은 응용 프로그램에서 데이터를 사용하는 방법에 따라 달라집니다. 아무도 맞는 답이 없습니다.

질문에 MySQL 태그가 붙어 있지만이 질문을 읽는 사람들은 다른 브랜드의 RDBMS를 사용하는 경우 Oracle을 사용할 때는 BFILE을, Microsoft SQL Server 2008을 사용하는 경우 FILESTREAM을 조사 할 수 있습니다. 파일을 데이터베이스 외부에 저장하지만 데이터베이스 테이블의 행의 일부인 것처럼 액세스 할 수 있습니다 (다소간).

Answer 6

데이터는 하나의 일관된 장소, 즉 데이터베이스에 저장해야합니다. 이 성능 및 Content-Type 문제는 전혀 문제가되지 않습니다. BLOB 필드를 로컬 웹 서버에 캐싱하지 못하게하고 처음 요청할 때 로컬 웹 서버에서 서비스하는 것을 방해 할 것이 없기 때문입니다. 모든 페이지보기에서 해당 테이블에 액세스 할 필요는 없습니다.

이 파일 시스템 캐시는 언제든지 비울 수 있으며 자동으로 리필 될 때 성능에 일시적으로 영향을 미칩니다. 또한 응용 프로그램이 커짐에 따라 하나의 데이터베이스와 여러 웹 서버를 사용할 수있게되며 파일 시스템에 모두 로컬 캐시가 생깁니다.

Answer 7

MySQL에서 BLOB를 저장 한 경험으로 다른 테이블 (조인) 테이블에 BLOB 만 저장하는 한 다른 테이블에 테이블을 저장하는 것이 좋습니다. 반대로 표준 필드가 몇 개인 테이블과 필드가 100MB 인 BLOB 필드를 검색하면 쿼리 속도가 크게 저하 될 수 있습니다.

전자 메일이 보낸 날짜와 같은 테이블에 내용이 저장되어있는이 문제에 대해 메일 응용 프로그램의 데이터 계층을 변경해야했습니다. 전자 메일 주소 등. 10000 개의 전자 메일을 검색하는 데 9 초가 걸렸습니다. 이제는 취해야 할 것이 걸립니다 ;-)