내 응용 프로그램이 매우 많은 양의 항목 (수천만)을 생성, 저장 및 검색한다고 가정 해 봅시다. 각 항목에는 다양한 데이터의 다양한 수가 있습니다 (예 : 일부 항목은 ID/제목과 같은 몇 바이트 만 있고 일부는 메가 바이트의 보충 자료가있을 수 있음). 각 항목의 기본 구조는 동일하며 XML 형식입니다.많은 양의 데이터 저장 : DB 또는 파일 시스템?
항목은 임의로 작성되고 편집됩니다 (대체로 추가, 다시 작성하지 않음).
데이터베이스에 필요한 모든 인덱스를 DB에 저장하는 것과 달리 DB에 인덱스를 유지하면서 파일 시스템에 별도의 파일로 항목을 저장하는 것이 합리적입니까?
정말 어떻게 사용할지에 따라 달라집니다. 데이터베이스는 대부분의 사람들이 생각하는 것보다 테이블에서 더 많은 항목을 처리 할 수 있습니다. 특히 적절한 인덱싱이 필요합니다. 반대로, 관계형 데이터베이스에서 제공하는 기능을 사용하지 않을 경우에는 사용할 필요가 없습니다.
좋아, 충분히 일반화. 어쨌든 데이터베이스가 결국 "디스크상의 파일"로 귀결된다는 것을 감안할 때, "해야 할 일"이 무엇인지에 대해 너무 걱정하지 않을 것입니다. 데이터베이스의 주된 목적이 이러한 파일을 효율적으로 검색하는 것이라면 DB 항목을 작게 유지하고 실제 데이터 대신 파일 경로를 조회하는 것이 좋을 것이라고 생각합니다. 특히 파일 시스템이 데이터를 검색 할 때 매우 효율적이어야하므로 특정 위치가 주어진다.
흥미로운 경우 실제로 이것은 검색 엔진의 일반적인 데이터 저장 패턴입니다. 인덱스는 인덱스의 모든 것을 저장하는 대신 색인 된 데이터와 저장된 데이터에 대한 포인터를 디스크에 저장합니다.
나는 파일 시스템과 의 데이터를 확실히 저장합니다. 해시 값은 DB에 저장됩니다.
비용에 따라 MS SQL Server는 구조화되지 않은 데이터에서도 "기본 XML 인덱스"라는 것을 만들 수 있습니다. 이를 통해 XQuery를 작성하여 열을 검색하면 데이터베이스가 도움이됩니다.
데이터에 일관성이 있거나 스키마에 배치 할 수있는 경우 이점이 있습니다.
이미지와 같은 많은 양의 이진 데이터가 있으면이를 제거하고 파일 시스템과 같이 다른 위치에 두는 것이 좋습니다. 또는 2008을 사용하는 경우 "Filestream"(건배 @Marc_s)이라는 유형이 있습니다.이 유형을 사용하면 작성한 모든 파일을 색인화, 저장 및 보호 할 수 있으며 NTFS API를 사용하여 검색 (즉, 빠른 블록 전송) 할 수 있습니다. 데이터베이스에 컬럼으로 유지됩니다.
데이터베이스를 사용하면 응용 프로그램에서 XML 데이터 검색을 많이 요구할 때 추상화 및 확장이 가능하므로 그리드 작업이 필요하지 않습니다.
그냥 2c입니다.
SQL Server 2008 데이터 특성은 실제로 ** FILESTREAM **이라고합니다. 실제로 그 자체로 타입이 아닙니다. 'VARBINARY (MAX)'컬럼에 추가 할 수있는 속성입니다. –
나는 종종 나중에 분석 할 수 있도록 많은 XML 문서 집합을 축적해야합니다. 일반적으로이 작업은 디렉토리에 저장하고 grep (또는 모든 XML factory/builder/wrapper/API 도구를 갖춘 맞춤형 Java 프로그램)을 통해 분석됩니다.
느린 하루에 PostgreSQL에 넣으려고했습니다.시도해보고 싶은 기능이 두 가지 있습니다.
첫 번째 기능에 대해서는 DB 크기가 원시 파일 크기의 절반보다 작습니다. WHERE data::TEXT LIKE '%pattern%'을 사용하여 전체 텍스트 검색을 수행하는 테이블 스캔은 실제로 파일에서 grep을 실행하는 것보다 빠릅니다. 당신이 몇 GB의 XML을 다루고있을 때, 이것만으로도 DB를 보람있게 만듭니다.
두 번째 기능인 색인 생성은 유지 관리가 더 필요합니다. 색인을 생성하는 것이 좋을 것이라고 생각되는 몇 가지 특정 요소가있었습니다. xpath('//tradeHeader/tradeId/text()', data)에 대한 색인이 작동하지만 각 조회에서 중복되는 것이 좋습니다. 일부 필드에 일반 열을 추가하는 것이 더 쉽고 삽입/업데이트 트리거를 사용하여 동기화를 유지하는 것이 더 쉽습니다.
FS에 저장된 XML/미디어 파일 외에도 검색 가능한 텍스트 컨텐츠 만있는 테이블은 있습니까? –
@Logistetica : 당신이 의미하는 것이 확실하지 않습니다. 주 파일을 FS에두고 메타 데이터를 DB에 넣는 것을 의미합니까? (파일 이름이 무엇인지 말하는 필드가 있습니다.) 사람들이 일반적으로하는 일이라고 생각합니다. 나는 그것으로 많은 경험을하지 못했다. – Edmund
고려 사항 몇 :
일반적으로 파일 시스템보다 데이터베이스에서 마샬링하기가 쉽습니다. 하지만 가장 어려운 일은 파일 시스템 백업을 데이터베이스의 롤 포워드 (다시 실행) 로깅과 동기화하는 것입니다. 응용 프로그램의 트랜잭션이 많을수록 이러한 요인이 더 중요합니다.
일반적인 데이터베이스 기능 (관계형 무결성, 가입)을 사용하지 않으려한다는 귀하의 질문에서 나타납니다. 어떤 경우에는 세 번째 옵션을 강하게 고려해야합니다. 데이터를 파일 시스템에 저장하고 데이터베이스 대신 Solr (또는 Lucene), Sphinx, Autonomy 등의 파일 기반 텍스트 검색 엔진을 사용하십시오.
이전 응답에서 말한 것처럼 데이터 사용 방법에 따라 다릅니다.
데이터베이스의 데이터를 사용하여 다양한 종류의 쿼리를 지원하고 결과를 보고서, 양식, OLAP 엔진 및 기타 여러 도구에 제공 할 수 있습니다. 적절한 인덱싱을 통해 검색 속도를 크게 높일 수 있습니다.
SQL을 잘 알고 있고 데이터베이스가 잘 디자인되어 있다면 쿼리를 사용하는 것이 파일과 동등한 작업을 수행하는 것보다 쉽고 빠르며 오류가 발생하기 쉽습니다. 그러나 다른 사람들이 지적했듯이 XML 데이터를 데이터베이스로 이동하지 않고 SQL에 연결할 수 있습니다.
좋은 다목적 스키마를 디자인하는 것은 대부분의 초보자가 생각하는 것보다 어렵습니다. 많은 것을 배울 것이고, 단지 하나의 도구 또는 다른 것을 조작하는 방법에 관한 것이 아닙니다. 그리고 나쁜 다목적 스키마는 파일보다 작업하기가 더 어려울 수 있습니다.
데이터베이스로 이동하려면 상당한 투자를 할 수 있도록 준비하십시오. 그리고 그 투자의 혜택을 누릴 수 있는지 확인하십시오.
HDFS (Hadoop distributed file system)를 사용하여 데이터를 저장합니다. 주요 아이디어는 고 가용성, 확장 성 및 복제를 얻을 수 있다는 것입니다. 애플리케이션에 대한 모든 쿼리는지도 축소 쿼리로 만들 수 있습니다. 또한 주요 필드는 Katta를 사용하여 Hadoop 위에 분산 인덱스로 저장할 수 있습니다.
이러한 기술에 대한 인터넷 검색을 시도해보십시오.
빠른 작업이 필요하지 않은 파일 : file sys; 필요한 항목 : 데이터베이스 –