그래서 DB에 이미지를 많이 저장하는 앱을 사용하고 있습니다. 이것에 대한 당신의 전망은 무엇입니까? 위치를 DB에 직접 저장하는 것보다 파일 시스템에 위치를 저장하는 유형에 가깝습니다.
장단점은 무엇이라고 생각하십니까?
답변:
많은 TB 이미지를 관리하는 일부 응용 프로그램을 담당하고 있습니다. 데이터베이스에 파일 경로 를 저장하는 것이 가장 좋습니다.
몇 가지 문제가 있습니다.
대부분의 문제와 마찬가지로 들리는 것처럼 간단하지 않습니다. 데이터베이스에 이미지를 저장하는 것이 적합한 경우가 있습니다.
반면에 관련된 문제가 있습니다
파일 저장소. 페이스 북 엔지니어들은 그것에 대해 큰 이야기를했습니다. 한 가지 해결해야 할 것은 디렉토리에있는 파일의 실제 한계를 아는 것이 었습니다.
약간 긴 시간이 걸릴 수 있지만 SQL Server 2008을 사용하거나 사용하려는 경우 새로운 FileStream 데이터 형식을 살펴 보는 것이 좋습니다 .
FileStream은 파일을 DB에 저장하는 것과 관련된 대부분의 문제를 해결합니다.
그러나 SQL의 "투명한 데이터 암호화"는 FileStream 객체를 암호화하지 않으므로 고려해야 할 경우이를 varbinary로 저장하는 것이 좋습니다.
MSDN 기사에서 :
Transact-SQL 문은 FILESTREAM 데이터를 삽입, 업데이트, 쿼리, 검색 및 백업 할 수 있습니다. Win32 파일 시스템 인터페이스는 데이터에 대한 스트리밍 액세스를 제공합니다.
FILESTREAM은 파일 데이터 캐싱에 NT 시스템 캐시를 사용합니다. 이는 FILESTREAM 데이터가 데이터베이스 엔진 성능에 미치는 영향을 줄이는 데 도움이됩니다. SQL Server 버퍼 풀이 사용되지 않습니다. 따라서이 메모리는 조회 처리에 사용 가능합니다.
DB의 파일 경로는 분명히 갈 길입니다-TB 이미지를 가진 고객으로부터 많은 이야기를 들었습니다 .DB에 상당한 양의 이미지를 저장하려고하는 악몽이되었습니다.
내 경험상 때로는 가장 간단한 해결책은 기본 키에 따라 이미지 이름 을 지정하는 것 입니다. 따라서 특정 레코드에 속하는 이미지를 쉽게 찾을 수 있으며 그 반대도 마찬가지입니다. 그러나 동시에 데이터베이스의 이미지에 대해서는 아무것도 저장하지 않습니다 .
여기서 속임수는 열성적이지 않는 것입니다.
여기서 주목해야 할 것은 프로 파일 시스템 캠프에 아무도 특정 파일 시스템을 나열하지 않았다는 것입니다. 이것은 FAT16에서 ZFS에 이르는 모든 것이 모든 데이터베이스를 능가한다는 것을 의미합니까?
아니.
진실은 우리가 원시 속도에 대해서만 이야기 할 때조차도 많은 데이터베이스가 많은 파일 시스템을 능가한다는 것입니다.
올바른 행동 과정은 정확한 시나리오에 대한 올바른 결정을 내리는 것이며,이를 위해서는 몇 가지 숫자와 사용 사례가 필요합니다.
참조 무결성 및 ACID 준수를 보장해야하는 장소에서는 데이터베이스에 이미지를 저장해야합니다.
데이터베이스에 저장된 해당 이미지의 이미지와 메타 데이터가 동일한 파일을 참조한다는 것을 트랜잭션 분석적으로 보증 할 수 없습니다. 다시 말해, 파일 시스템의 파일이 메타 데이터와 동일한 트랜잭션에서 동시에 변경되는 것을 보장 할 수는 없습니다.
다른 사람들이 말했듯이 SQL 2008에는 파일 스트림 유형이 제공되어 파일 이름 또는 식별자를 db에 포인터로 저장하고 파일 시스템에 이미지를 자동으로 저장할 수 있습니다. 이는 훌륭한 시나리오입니다.
오래된 데이터베이스를 사용하는 경우 BLOB 데이터로 저장하는 경우 기능 검색 방법으로 데이터베이스에서 아무것도 가져 가지 않을 것이므로 아마도 가장 좋습니다. 파일 시스템에 주소를 저장하고 이미지를 그런 식으로 저장합니다.
이렇게하면 파일 시스템의 공간 또는 압축 된 공간 만 절약하므로 파일 시스템의 공간도 절약 할 수 있습니다.
또한 db 적중없이 파일 시스템의 원시 이미지를 탐색하거나 파일을 다른 시스템, 하드 드라이브, S3 또는 다른 시나리오로 대량 전송하여 위치를 업데이트 할 수있는 구조 또는 요소를 저장하기로 결정할 수 있습니다 저장 공간을 늘리려 고 할 때 이미지를 DB에서 가져 오려고 시도하지 않고 다시 구조를 유지하십시오.
아마 그것은 일반적으로 히트 이미지 URL을 기반으로 웹 엔진 / 프로그램에 일부 캐싱 요소를 던져서 거기에 자신을 저장하게 할 수도 있습니다.
자주 편집되지 않는 작은 정적 이미지 (2 메가 이하)는 데이터베이스에 저장해야합니다. 이 방법에는 이식성 (이미지가 데이터베이스와 함께 전송 됨), 백업 / 복원 (이미지가 데이터베이스와 함께 백업 됨), 확장 성 (수천 개의 작은 썸네일 파일이있는 파일 시스템 폴더)이 확장 성 악몽처럼 들리는 등 여러 가지 이점이 있습니다. 나를).
데이터베이스에서 이미지를 제공하는 것은 쉽습니다. DB 서버에서 반환 된 바이트 배열을 이진 스트림으로 제공하는 http 핸들러를 구현하기 만하면됩니다.
주제에 대한 흥미로운 백서가 있습니다.
BLOB로 또는 BLOB으로 : 데이터베이스 또는 파일 시스템의 대형 객체 저장소
대답은 "그것은 달려있다"입니다. 확실히 그것은 데이터베이스 서버와 Blob Storage에 대한 접근 방식에 달려 있습니다. 또한 Blob에 저장되는 데이터 유형과 해당 데이터에 액세스하는 방법에 따라 다릅니다.
데이터베이스를 스토리지 메커니즘으로 사용하여 더 작은 크기의 파일을 효율적으로 저장하고 전달할 수 있습니다. 더 큰 파일은 파일 시스템을 사용하여 저장하는 것이 좋으며, 특히 자주 수정 / 업데이트되는 경우에 특히 좋습니다. (블로 브 조각화는 성능과 관련하여 문제가됩니다.)
명심해야 할 추가 사항이 있습니다. Blob을 저장하기 위해 데이터베이스 사용을 지원하는 이유 중 하나는 ACID 준수입니다. 그러나 SQL Server 처리량을 두 배로 늘리는 백서 (SQL Server의 대량 로깅 옵션)에서 테스터가 사용한 접근 방식은 BLOB 데이터가 기록되지 않았기 때문에 ACID의 'D'를 'd'로 효과적으로 변경했습니다. 트랜잭션의 초기 쓰기 따라서 전체 ACID 준수가 시스템에 중요한 요구 사항 인 경우 파일 I / O를 데이터베이스 Blob I / O와 비교할 때 데이터베이스 쓰기에 대한 SQL Server 처리량 수치를 절반으로 줄이십시오.
아직 아무도 언급하지 않았지만 주목할 가치가있는 한 가지는 대부분의 파일 시스템에 많은 양의 이미지를 저장하는 것과 관련된 문제가 있다는 것입니다. 예를 들어 위에서 언급 한 접근 방식을 취하고 기본 키 다음에 각 이미지 파일의 이름을 지정하는 경우 대부분의 파일 시스템에서 매우 많은 수의 이미지에 도달하면 모든 이미지를 하나의 큰 디렉토리에 넣으려고하면 문제가 발생합니다 ( 예를 들어 수십만 또는 수백만에서).
이것에 대한 일반적인 해결책은 균형 잡힌 하위 디렉토리로 해시하는 것입니다.
아무도 언급하지 않은 것은 DB가 원자 적 행동, 트랜잭션 무결성을 보장하고 동시성을 처리한다는 것입니다. 참조 적으로도 무결성은 파일 시스템과는 다릅니다. 파일 이름이 여전히 올바른지 어떻게 알 수 있습니까?
파일 시스템에 이미지가 있고 새 버전을 작성하거나 파일을 삭제할 때 누군가 파일을 읽고있는 경우 어떻게됩니까?
Blob도 관리 (백업, 복제, 전송)가 더 쉬우므로 사용합니다. 그들은 우리를 위해 잘 작동합니다.
데이터베이스의 이미지에 대한 파일 경로 만 저장하는 문제는 데이터베이스의 무결성을 더 이상 강요 할 수 없다는 것입니다.
파일 경로가 가리키는 실제 이미지를 사용할 수 없게되면 데이터베이스에 무심코 무결성 오류가 발생합니다.
이미지가 실제로 검색되는 데이터이고, 파일 시스템과 독립적으로 액세스하는 경우 (파일 시스템에 독립적으로 액세스하는 경우) 하나의 통합 데이터베이스에서 이미지를 쉽게 관리 할 수 있다는 점을 고려하면 (이미지가 갑자기 사라지지 않음), 이미지가 갑자기 "사라질 수 있습니다"), BLOB 등으로 직접 저장하려고합니다.
내가 일하던 회사에서 Oracle 8i (the 9i) 데이터베이스에 1 억 5,500 만 개의 이미지를 저장했습니다. 7.5TB 가치.
SQL Server 2008을 사용하지 않고 특정 이미지 파일을 데이터베이스에 배치해야하는 확실한 이유가있는 경우 "두 가지"방식을 모두 사용하여 파일 시스템을 임시 캐시로 사용하고 데이터베이스를 마스터 리포지토리로 사용할 수 있습니다 .
예를 들어, 비즈니스 로직은 이미지 파일을 제공하기 전에 디스크에 이미지 파일이 있는지 확인하고 필요할 때 데이터베이스에서 검색 할 수 있습니다. 이를 통해 여러 웹 서버의 기능을 사용하고 동기화 문제를 줄일 수 있습니다.
"실제 세계"예제가 얼마인지 잘 모르겠지만 현재 카드 이미지를 포함하여 트레이딩 카드 게임에 대한 세부 정보를 저장하는 응용 프로그램이 있습니다. 데이터베이스의 레코드 수는 현재까지 2851 개 레코드이지만, 특정 카드가 여러 번 릴리스되고 대체 아트 워크가 있다는 사실을 고려할 때 아트 워크의 "1 차 사각형"을 스캔 한 다음 동적으로보다 효율적으로 크기를 조정했습니다. 요청시 카드에 대한 테두리 및 기타 효과를 생성합니다.
이 이미지 라이브러리의 원래 작성자는 요청에 따라 이미지를 렌더링하는 데이터 액세스 클래스를 작성했으며,보기 및 개별 카드에 매우 빠르게 수행합니다.
이것은 또한 새로운 카드가 출시 될 때 배포 / 업데이트를 용이하게합니다. 이미지의 전체 폴더를 압축하여 파이프로 전송하고 적절한 폴더 구조가 생성되도록하는 대신 데이터베이스를 업데이트하고 사용자가 다시 다운로드하도록합니다. 현재 최대 56MB 크기는 좋지 않지만 향후 릴리스의 증분 업데이트 기능을 개발 중입니다. 또한 전화 접속 사용자가 다운로드 지연없이 응용 프로그램을 가져올 수 있도록하는 "이미지 없음"버전의 응용 프로그램이 있습니다.
이 솔루션은 응용 프로그램 자체가 데스크톱에서 단일 인스턴스를 대상으로하기 때문에 지금까지 효과적이었습니다. 이 모든 데이터가 온라인 액세스를 위해 보관되는 웹 사이트가 있지만이 방법으로 동일한 솔루션을 사용하지는 않습니다. 파일에 대한 액세스는 이미지에 대한 요청 빈도 및 볼륨에 따라 더 잘 확장되므로 파일 액세스가 바람직하다는 데 동의합니다.
바라건대이 주제가 너무 많지는 않지만 주제를보고 비교적 성공적인 소규모 / 중규모 응용 프로그램에서 내 통찰력을 제공하고자했습니다.
SQL Server 2008은 다음과 같은 두 가지 이점 을 모두 갖춘 솔루션을 제공합니다 . 파일 스트림 데이터 형식 .
일반 테이블처럼 관리하고 파일 시스템의 성능을 갖습니다.
저장하려는 이미지 수와 크기에 따라 다릅니다. 과거에 데이터베이스를 사용하여 이미지를 저장했으며 내 경험이 상당히 좋았습니다.
IMO, 데이터베이스를 사용하여 이미지를 저장하는 전문가는
A. 이미지를 보관하기 위해 FS 구조가 필요하지 않습니다
. B. 더 많은 수의 항목을 저장해야 할 때 데이터베이스 인덱스가 FS 트리보다 성능이 뛰어납니다
. C. 스마트하게 튜닝 된 데이터베이스는 쿼리 결과를 캐싱하는 데 훌륭한 작업을 수행
합니다. D. 백업은 간단합니다. 복제가 설정되어 있고 컨텐츠가 사용자 근처의 서버에서 제공되는 경우에도 잘 작동합니다. 이러한 경우 명시적인 동기화가 필요하지 않습니다.
이미지가 작을 경우 (예 : <64k) db의 스토리지 엔진이 인라인 (레코드) BLOB를 지원하는 경우 간접적 인 참조가 필요하지 않으므로 성능이 더 향상됩니다 (참조의 지역성이 달성 됨).
적은 수의 거대한 크기의 이미지를 처리 할 때는 이미지 저장이 좋지 않을 수 있습니다. 이미지를 db에 저장하는 데 따른 또 다른 문제는 생성, 수정 날짜와 같은 메타 데이터가 응용 프로그램에서 처리되어야한다는 것입니다.
최근에 PDF / Word 파일을 MySQL 테이블에 저장하는 PHP / MySQL 앱을 만들었습니다 (지금까지 파일 당 최대 40MB).
장점 :
단점 :
구현을 성공이라고 부르고 백업 요구 사항을 처리하고 프로젝트 레이아웃을 단순화합니다. 앱을 사용하는 20-30 명의 사용자에게는 성능이 좋습니다.
내 경험상 나는 데이터베이스에 저장된 이미지와 db에 저장된 경로가있는 파일 시스템의 이미지를 모두 관리해야했습니다.
데이터베이스의 이미지 인 첫 번째 솔루션은 데이터 액세스 계층이 데이터베이스 개체 만 처리해야하기 때문에 다소 "깨끗합니다". 그러나 이것은 낮은 숫자를 처리해야 할 때만 좋습니다.
이진 대형 개체를 처리 할 때 데이터베이스 액세스 성능이 저하되고 데이터베이스 크기가 커져서 성능 손실이 다시 발생합니다. 일반적으로 데이터베이스 공간은 파일 시스템 공간보다 훨씬 비쌉니다.
반면에 파일 시스템에 큰 이진 객체를 저장하면 데이터베이스와 파일 시스템을 모두 고려해야하는 백업 계획이 생길 수 있으며 이는 일부 시스템에서 문제가 될 수 있습니다.
파일 시스템을 사용해야하는 또 다른 이유는 이미지 데이터 (또는 사운드, 비디오 등)를 타사 액세스와 공유해야 할 때입니다. 요즘에는 "외부에서 액세스해야하는 이미지를 사용하는 웹 앱을 개발하고 있습니다. "이진 데이터를 검색하기위한 데이터베이스 액세스가 불가능한 방식의 웹 팜입니다. 따라서 때로는 선택을 유도하는 디자인 고려 사항도 있습니다.
또한 이진 객체에 액세스 할 때 권한 및 인증을 처리해야하는 경우이 선택을 고려하십시오. 일반적으로 이러한 요구 사항은 데이터가 db에 저장 될 때 더 쉬운 방법으로 해결할 수 있습니다.
이전 프로젝트에서 파일 시스템에 이미지를 저장했으며 백업, 복제 및 파일 시스템이 데이터베이스와 동기화되지 않아 많은 골칫거리가 발생했습니다.
내 최신 프로젝트에서 데이터베이스에 이미지를 저장하고 파일 시스템에 이미지를 캐싱하고 실제로 잘 작동합니다. 지금까지 아무런 문제가 없었습니다.
둘째, 파일 경로에 대한 권장 사항입니다. 대규모 자산 수집을 관리하는 데 필요한 몇 가지 프로젝트를 수행했으며 DB에 직접 저장하려고 시도하면 장기적으로 고통과 좌절이 발생했습니다.
DB에 저장하는 것과 관련하여 내가 생각할 수있는 유일한 "프로"는 개별 이미지 자산을 쉽게 만들 수있는 가능성입니다. 사용할 파일 경로가없고 모든 이미지가 DB에서 바로 스트리밍되는 경우 사용자가 액세스 할 수없는 파일을 찾을 위험이 없습니다.
그래도 웹 액세스 할 수없는 파일 저장소에서 데이터를 가져 오는 중개 스크립트를 사용하면 더 잘 해결되는 것처럼 보입니다. 따라서 DB 스토리지가 꼭 필요한 것은 아닙니다.
길거리의 말은 당신이 당신의 데이터베이스가 그것을 할 수 있다는 것을 증명하려고 노력하는 데이터베이스 벤더가 아니라면 (예를 들어, Microsoft가 SQL Server에 bajillion 이미지를 저장하는 Terraserver에 대해 자랑한다고 가정 해 보자) 그것은 좋은 생각이 아니라는 것입니다. 대안-데이터베이스의 파일 서버 및 경로에 이미지를 저장하는 것이 훨씬 쉬운 경우 왜 귀찮습니까? Blob 필드는 SUV의 오프로드 기능과 비슷합니다. 대부분의 사람들은 SUV를 사용하지 않으며, 보통 문제가있는 사람들은 사용하지만 재미는 있습니다.
데이터베이스에 이미지를 저장한다는 것은 이미지 데이터가 파일 시스템 어딘가에 있지만 가려져서 직접 액세스 할 수 없도록하는 것을 의미합니다.
+ ves :
-ves :
두 방법 모두 일반적이며 실용적입니다. 장단점을 살펴보십시오. 어느 쪽이든, 당신은 단점을 극복하는 방법에 대해 생각해야합니다. 데이터베이스에 저장하는 것은 일반적으로 데이터베이스 매개 변수를 조정하고 일종의 캐싱을 구현하는 것을 의미합니다. 파일 시스템을 사용하려면 파일 시스템 + 데이터베이스를 동기화 상태로 유지하는 방법을 찾아야합니다.